2009年05月02日

Automatic Differential Path Searching for SHA-1

Eurocrypt 2009 rump session の発表資料の中で
Cameron McDonald, Josef Pieprzyk, Phil Hawkes さん達の SHA-1 collisions now 252 って
プレゼンが公開されています。

SHA-1 は 160bit なので誕生日攻撃しようとすると 80bit の計算が必要です
2005 年に Xiaoyun Wang さんによって 69bit、更に 63bit まで短縮されてました
プレゼン資料によるとそれが去年の 11 月に 57bit に落ちていたのが
今回 52bit まで短縮されたということなのだそうです、が

流石にプレゼン資料だけだと何が言えてるのか判断しかねるのですが、特に
Until now, the best complete differential path (to our knowledge)
has complexity 263
ってどういう意味なんですかねぇ
Stéphane Manuel さんのページには 57bit まで落とした論文が載ってるのですが
ちょっとだけ読んだら Xiaoyun Wang さんの方法の disturbance vector ってのを
より簡単に作る方法を皆で考えているようなので
条件によっては上手く disturbance vector が作れるってことなのかな?

ともかく、MD5 も SHA-1 もガンガン研究が進んでるようなので
どうやって SHA-2 に移行するべきかってのを分かっていかないといけませんねぇ
ラベル:衝突 SHA-1
posted by OJH at 02:34| Comment(0) | TrackBack(0) | ニュース | このブログの読者になる | 更新情報をチェックする

2009年04月29日

杜撰な研究者の日記: MD5: 高速の解読法発見

ほんとに! って思ったんですが具体的に何が成されたのか良く分かりません
論文? は
これみたいですけど、イントロだけ読んでもなぁ
preimage が分かっちゃうの?
前提条件は??
ラベル:MD5 preimage
posted by OJH at 19:13| Comment(0) | TrackBack(0) | ニュース | このブログの読者になる | 更新情報をチェックする

2009年04月20日

「IT ホワイトボックス」でインターネットの暗号化に関して学んだ

この 4 月から IT ホワイトボックスって番組が NHK 教育でやってまして
初回は村井純さんが RFC って何かとか説明するっていうマニアな番組なんですが
3 回目のタイトルが「メールは盗み見られないのか?」でした
杜撰な研究者の日記: ITホワイトボックス第3回「メールは盗み見られないのか?」を見ました
で内容は見てたんですけど昼間に再放送がチェックできたんで見ました
夜には初回の再放送もやってたんで 3 回目もまた再放送あるのかも

例えば暗号の説明としてシーザー暗号から入るんですけど
つながり‐コンピュータとネットワークのしくみ‐ | 日本科学未来館』の映像とか出て
0 と 1 を白黒の玉で表現して実際に手を動かしてもらっていました
こういう説明がどのくらい効果的なんのかは良く分からないんですが
身体感覚から入るってのは良いんだろうなぁ、きっと
日本科学未来館は楽しそうだなと思いました
台場の RiSuPia には行ったことがあったんですが、こっちも見てみたいな、楽しそう
XOR とか出てきたらどうしようかとドキドキしてたんですが出てきませんでした

公開鍵暗号の話は「錠と鍵」で説明で
デジタルだから錠がいくらでもコピーできるんだ、ってことは言ってなかった
「公開鍵はいま世界で最も良く使われてる暗号」みたいなこと言ってた気がしたんだけど
「RSA は公開鍵で最も良く使われているアルゴリズム」ってこと言いたかったのかなぁ
公開鍵暗号っていうと RSA なんですかね、まぁ、言葉としては流通してると思うんですが
Diffie-Hellman ってそんな大切じゃないのかな? こっちの名前をどっちかっていうと出して欲しい

で、「暗号化なんて普段してないし、メールの内容も見られても困らないし」って発言に対し
「クレジットカードの番号とかネットバンキングとかしてませんか?」って返すわけですが
それもぉメールじゃなくって HTTP の話じゃん!! って思うんですが
まぁ、メールを軸に色々紹介するっていう番組みたいなんで仕方ないのかな...
何でウェブじゃなくてメール中心で話組んだんだろうなぁ

面白いなと思ってるんで機会があれば続きも見たいです
posted by OJH at 00:38| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2009年04月19日

RFC 5280 の 4.2.1.14. Inhibit anyPolicy

「全ポリシー禁止」って訳されてます。
この拡張は認証局に対して発行される証明証に使われます。
id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::=  { id-ce 54 }

InhibitAnyPolicy ::= SkipCerts

SkipCerts ::= INTEGER (0..MAX)
4.2.1.4. Certificate Policies で anyPolicy ってありました。
OID は 2.5.29.32.0 で、全てのポリシーにマッチする、という意味でした。
ポリシーを制限しないときに使いました。
anyPolicy って何でもありってのは sub CA に何されるか制御できないので、
「全ポリシー禁止」は anyPolicy が他のポリシーにマッチすることを禁止します。
但し証明証が自己署名な中間証明証である場合を除きます。

具体的には整数が指定されます。
その証明証以降何枚目から anyPolicy が使えなくなるか指定します。
例えば 1 であれば、
「全ポリシー禁止」が記載されている証明証のサブジェクトが発行した
証明証に記載されている anyPolicy は有効としても良いけれども、
それ以降の証明証に記載される anyPolicy は無効となります。

「全ポリシー禁止」はクリティカルにしましょう。
posted by OJH at 23:58| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする

2009年04月12日

RFC 5280 の 4.2.1.13. CRL Distribution Points

「CRL 配布点」は CRL を配っている方法・場所を指定します。
この拡張はクリティカルではないべきです (SHOULD)。
しかし RFC 5280 は、認証局もアプリケーションのどちらも
「CRL 配布点」に対応していることを推奨します (RECOMMENDS)。
CRL に関しては 5 節にてより詳しく説明されるのでそちらを。
id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::=  { id-ce 31 }

CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint

DistributionPoint ::= SEQUENCE {
     distributionPoint       [0]     DistributionPointName OPTIONAL,
     reasons                 [1]     ReasonFlags OPTIONAL,
     cRLIssuer               [2]     GeneralNames OPTIONAL }

DistributionPointName ::= CHOICE {
     fullName                [0]     GeneralNames,
     nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }

ReasonFlags ::= BIT STRING {
     unused                  (0),
     keyCompromise           (1),
     cACompromise            (2),
     affiliationChanged      (3),
     superseded              (4),
     cessationOfOperation    (5),
     certificateHold         (6),
     privilegeWithdrawn      (7),
     aACompromise            (8) }
cRLDistributionPoints は DistributionPoint の列で
DistributionPoint は
  • 配布点 (distributionPoint)
  • 理由 (reasons)
  • 発行者 (cRLIssuer)
の 3 つで構成されています、が、どれもオプションで省略可能です。
でも reason だけでは変なのでそれだけってのは無し (MUST NOT)、
distributionPoint か cRLIssuer はなくちゃいけません (MUST)。
証明書の発行者が CRL の発行者ではない場合には
cRLIssuer は必須で (MUST) 発行者の名前を記載します。
証明書の発行者が CRL の発行者の場合には
cRLIssuer は載せてはいけません (MUST)。
なので distributionPoint を載せなくてはいけません (MUST)。
GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

GeneralName ::= CHOICE {
     otherName                 [0]  AnotherName,
     rfc822Name                [1]  IA5String,
     dNSName                   [2]  IA5String,
     x400Address               [3]  ORAddress,
     directoryName             [4]  Name,
     ediPartyName              [5]  EDIPartyName,
     uniformResourceIdentifier [6]  IA5String,
     iPAddress                 [7]  OCTET STRING,
     registeredID              [8]  OBJECT IDENTIFIER }

RelativeDistinguishedName ::= SET SIZE (1..MAX) OF AttributeTypeAndValue

AttributeTypeAndValue ::= SEQUENCE {
        type     AttributeType,
        value    AttributeValue }
distributionPoint を載せる場合には、
GeneralName の列から成る GeneralNames か
1 つの値の nameRelativeToCRLIssuer を記載します。
DistributionPointName を複数載せる場合には
方法は色々でも同じ CRL を指し示すようにします。
例えば LDAP と HTTP で同じ CRL を配布してあってそれを指定するとか。

distributionPoint が directoryName を含む場合には、
  • そのエントリには reason に関連した CRL を含む
  • その CRL の発行者は cRLIssuer
CRL は certificateRevocationList または authorityRevocationList という
属性に格納されます。
ディレクトリサーバがローカルで動作しているとしても
CRL を入手することができるようにしないといけません。
プロトコルに何を使うかは local matter、好きにしろってこと?

DistributionPointName が URL で指定されてる場合、
次の意味であることが仮定されます:
  • URL は reason に関連した CRL を指す
  • その CRL の発行者は cRLIssuer
URI のスキームが HTTP/FTP の場合、RFC 2585 に従って
URI の先は 1 つの DER でエンコードされた CRL でなくてはいけない (MUST)。
HTTP サーバは Content-type に application/pkix-crl を返すべき (SHOULD)。
RFC 4516 の LDAP URI スキームを使う場合
  • URI は CRL を含む dn のフィールドを含まなくてはいけない (MUST)
  • 1 つの CRL を含む属性の適当な attrdesc を含まなくてはいけない (MUST) (RFC 4523)
  • ホスト部分を含むべき (SHOULD)
ホスト部分を省略しちゃうと
アプリケーションがどこ接続するか分かったもんじゃないですからね。
DistributionPointName を若し記載するなら、
LDAP か HTTP な URI を含むべき (SHOULD)。

DistributionPointName が 1 つの nameRelativeToCRLIssuer を含む場合、
その値は DN fragment を意味する。
fragment は配布点を記載する為に
X.500 番台の CRL 発行者の DN に追加されたものです。
DistributionPoint に cRLIssuer が記載されている場合、
fragment が DN に追加されます。
そうでなかったら、fragment は証明証の発行者の DN に追加されます。
RFC 5280 に従う認証局は、CRL 配布点を指定するのに
nameRelativeToCRLIssuer を使うべきではありません (SHOULD NOT)。
cRLIssuer が複数の DN を含む場合には、
DistributionPointName の nameRelativeToCRLIssuer を使ってはいけません (MUST NOT)。

DistributionPoint の reasons を省略する場合、
指されてる CRL は全ての理由に関する CRL を含んでなくてはいけません (MUST)。
RFC 5280 は reason によって CRL を分けることを推奨しません (RECOMMENDS)。
cRLDistributionPoints を証明証に記載する場合、
最低 1 つは全ての理由に関する CRL を記載しなくてはいけない (MUST)。

cRLIssuer は CRL に署名して発行したのが誰かを同定するのに使います。
cRLIssuer を記載するなら、中身は CRL の発行者の DN と合わせないといけません (MUST)。
DN エンコーディングも合わせなくてはいけません (MUST)。
cRLIssuer が記載されていて、その DN が CRL の配置されてる場所と対応しない場合、
認証局は distributionPoint も記載しなくてはいけません。
ラベル:RFC5280 CRL
posted by OJH at 15:12| Comment(0) | TrackBack(0) | 注疏 | このブログの読者になる | 更新情報をチェックする
×

この広告は180日以上新しい記事の投稿がないブログに表示されております。