SHA-0、MD5、 MD4にコリジョン発見、reduced SHA-1も 72
ストーリー by Oliver
電子署名のピンチ 部門より
電子署名のピンチ 部門より
電子署名などにつかわれる主要なハッシュ関数のコリジョン発見がカルフォルニアで開催中のCRYPTO 2004カンファレンスで次々と発表されている。
まずは80 ラウンドの完全版SHA-0のコリジョンをフランスの暗号学者Antoine Jouxが発見した。brute-forceの2^80に比べ、アタックの複雑性は約2^51で、256ノードのItanium2マシンで約8万CPU hours (約2週間?)必要だったという。次に中国の研究チームがMD5とMD4での複数のコリジョン発見[PDF]を報告した。驚くことに、コリジョン発見に要する時間はMD5でわずか数分で、MD4にいたっては手で計算する事が可能なぐらい簡単だという。また、MD5と共にもっとも使われているハッシュ関数であるSHA-1に関しても攻撃が発表され、36ラウンドの縮小版SHA-1のコリジョンがデモンストレーションされ、54ラウンドあたりまでは現時点でも現実的な攻撃が可能なことが示唆された。普段つかわれる80ラウンドの完全版SHA-1がすぐ脅かされる、ということではないが、他のハッシュ関数もラウンド数を減らした版の数年後には完全版への攻撃がみつかっている。
ほんの数分前に発表のウェブキャストが終ったばかりで、実際のアプリケーションへの影響はこれから専門家によるさらなる検証で明らかになっていくだろうが、これらのハッシュ関数の価値が激減したことは確実と見てよさそうだ。
さっき、その会場から戻ってきました (スコア:5, 参考になる)
ランプセッションで行われたHash Function Collisionセッションの3つのTalkはCRYPTOの歴史に残るんじゃないかな。 ランプセッションは、まだ論文にならないようなオンゴーイングな研究の状況や、他のカンファレンスなどの告知、あるいはエンターテイメント、ツッコミが3~5分で行われる場所なのですが、今回、ハッシュファンクションに関しては特別に15分つづ時間が割り当てられ特別発表みたいな形になっていました。ハッシュの3つ以外は、いつもと同じです。
こちらでは日曜の夜から発表したXiaoyun Wangと、共同研究者のXuejia Lai (IDEAの開発者)は、この論文に関してみんなからコメントを貰ったり、あるいはディスカッションが繰り返されていて、この発表の時点では論文にあったマイナーな違い部分はクリアーになっていていました。
まず露払いのEli BihamがSHA-0に関して、Antoine Jouxがさらに計算してコリジョンを実際にみつけた、と発表。
さてXiaoyun Wangの登場。年齢は40歳を越えたぐらいに見える女性で、まったくの無名。論文にXuejia Laiが名前を連ねていなかったら誰も信じなかったかも。発表の終わってからの拍手がすごかったです。拍手が鳴り止まない。スタンディングしている人もちらほら。彼女が終わったあとに、Laiが補足で論文の間違い部分についての説明をしたけど、所でどこがでシュナイヤーがなんか突っ込みを入れていたんでしょうか?
今回が初めて来てから10年、一回さぼって9回目のCRYPTOなんだけど、本番の発表でもこれだけ拍手が鳴り止まなかったのを見たのは僕は初めて。衝撃度でも何年か前に同じくランプセッションで発表されたShamirのSkipJackの解読法の講演よりも完全に上。 いやー、いい所に立ち会えたなぁ、という感じです。
たぶん既にこの3人同士が次のステップを議論しているだろうから、 SHA-1に関してのコリジョンを見つけるのは時間の問題だと思います。
11:10になって、やっと10:16分に予定していたEli Bihamの Ipossible fault analysis of RC4が始まりました。 でも眠たいのでもう寝ます。それではまた 。
パスワードなんか既に忘れている
すずきひろのぶ
Re:さっき、その会場から戻ってきました (スコア:5, 興味深い)
MD5に関してはゴミをつければいいということを投稿されていた方がいましたが、その通りです。つけくわえれば実行ファイルのデータ領域に参照しないデータを余計につけても、感の鋭い人以外はわからないでしょう、ということを付け加えるぐらいでしょうか。
メーカーの研究者の所には次から次へと会社から「ハッシュのことはどうだったんだ!」という問い合わせが殺到しているそうです。ちょっと誤解している人もいるので、はっきりさせておきましょう。
現在暗号システムに使われて主流となっているSHA-1はまだ安全です。
しばらくするとSHA-1のコリジョンは発見されるかも知れませんが、現実的に悪意を持って操作させれるほど簡単にSHA-1に関しては操作できません。まだまだ先の話です。またeJapanのために策定されたガイドラインCRYPTORECでは、既にSHA-1の寿命は折込でいてSHA-256にスライドできるようになっているので、これから先にSHA-1が寿命が尽きたとしても大丈夫なロードマップは仕様上きちんとできているはずです。あまり驚かないように。
ただしMD5はもうダメです。その点はあきらめてください。
今回このハッシュコリジョンを話したXiaoyun Wangを次の12月5日から韓国の済州島で行われるAsiaCryptoにはInvited Talkとして呼ぼう、ここで全容を詳細に語ってもらおう、という流れになっているというのが、今から6時間ほど前の状況です。
このハッシュコリジョンの研究成果がなんでIACRのeprint、そしてランプセッションに来たかという背景を色々な人から聴くと、非常に興味深いものがあります。それは、まるでNHKのプロジェクトX風のストーリーのようでもあります。それで...
この辺から、「風の~なかの~す~ばる~」のBGMがかかりつつ、なぜビザが必要なアメリカへすぐに出発することできたのか、最後の拍手の鳴り止まない感動のフィナーレまで、色々な謎と物語が展開しつつ話は続くわけですが、それはまたどこかで。
夜中の1時45分。もう寝ます。
すずきひろのぶ
Re:さっき、その会場から戻ってきました (スコア:3, 興味深い)
朝一番のセッションでEli BihamとAntoine Jouxが各々本来の発表するのですが、既に昨夜話しているので、何をやるのか別の意味で楽しみです。
さて安全性に関してですが、MD5に関してはかなり厳しいです。たとえばNSAあたりがダウンロード配布ファイルの中身に彼らが作ったトロイの木馬を潜ませるなんてことが可能になります。普通、ダウンロードにSSLなんか使わないのでMAN-IN-THE-MIDDLE攻撃です。ですから配布オリジナルを改ざんすることなく、狙った相手がダウンロードするときにすりかえればって感じです。
これを2、3週間程度でこなすためには計算量的には、そこそこのシステムが必要です。しかしながら最近はむかしと違って億単位のスーパーコンピュータじゃなくても可能で、ざっくりコストパフォーマンスを勘案するとOpteron 2xxシリーズ 2wayサーバを100台ぐらい用意するといけそうな気がします。総額5000万円ぐらい。ディスカウントしてもらって4000万円ぐらいかなぁ。
あんまり妄想を書いていても仕方がないですし、それよりも、おなかがすいてきたので朝ごはんにいってきます。ちなみに昨日のランプセッションで、ハッシュの話以外ではマイクロソフトのDavid JaoのAlmost-Ramanujan graphs and random reducibilty of DLOG amang isogenous elliptic curvesが個人的には興味を引きました。
あ、もうこんな時間だ
すずきひろのぶ
Re:さっき、その会場から戻ってきました (スコア:1)
> 彼らが作ったトロイの木馬を潜ませるなんてことが可能になります。
> 普通、ダウンロードにSSLなんか使わないのでMAN-IN-THE-MIDDLE攻撃です。
> ですから配布オリジナルを改ざんすることなく、
> 狙った相手がダウンロードするときにすりかえればって感じです。
それ以前の問題として、
検証に使うMD5サムが公開されている場合でも非SSLで公開されていたりして、
せいぜいダウンロード時の破損チェックくらいにしか使えてなかった
という現状もあったり(; ;)
そこまでストイックに配布物のセキュリティを管理している例は
数少ないような気もするんですが、
素朴な疑問として、実際にそういう事例があったとして、
それがMD5サムのみに頼ってるという事はあるもんなのでしょうか?
バックドアに関しては、NSAを出すまでもなく
クローズドソースなOSメーカーにしてみれば
それ以上の仕掛も容易いように思いますし。
もちろんMD5のクラック事態は由々しき問題だと思いますが、
セキュリティ上の大穴がもっと別な所に散在しているように感じられるのですが?
uxi
Re:さっき、その会場から戻ってきました (スコア:1)
踏み台を設置する事はできるような気がします。
source code 中の条件式(+-=!<>)を違う条件式に変更できれば、
文字列の長さを check するコードを改竄できる可能性があります。
そしてバッファオーバーフローを容易に発生させる事が可能になれば
その後、トロイの木馬を仕込む事も可能でしょう。
Re:さっき、その会場から戻ってきました (スコア:1)
/*
* buffer overflow check!!
*/
if( length > BUFSIZE ){
...
}
こんな風に。
/*
* auffer overflow check!!
*/
if( length >=BUFSIZE ){
...
}
Re:さっき、その会場から戻ってきました (スコア:1)
で、どう使われてしまうかというと、どうでも良い部分にごみを付ければよいのです。
tar みたいなものでまとめてあるだけなら、本体の他にゴミファイルをつけてその部分で調整するのです。
gzip で圧縮するなら、XLEN bytes of "extra field" の中で調整するのです。適切な圧縮結果になる余分なファイルをつけてもいいのですが、それだと作業が大変そうです。
もちろん木馬本体に変なメッセージをつけてその部分で表現してもいいし、方法は山ほどあります。
NSA のダウンロードファイルがどんな形式なのか知らないのですが、'将来の拡張のため'と称して勝手なコンテンツをつけることができるformat は多いです。check sum のほかに長さも見ていると偽装は難しくなるので、メールの電子署名でメールのメッセージを偽造/偽装するのは大変でしょう。SPRM みたいなもんなら偽装を防ぐのは無理でしょう。
確認させてください (スコア:2, 参考になる)
この計算式を満たすメッセージMの発見が数秒から数分で行われた、と読める。
任意のメッセージに対するコリジョン発生式というわけではないのかしら?
まあ、それはそれで重要な報告ではあるんだけど。
Re:確認させてください (スコア:3, 参考になる)
ハッシュ値のコリジョンには弱衝突と強衝突という概念がありまして。
ハッシュ関数を f()として元の文章をAとします。
Aのハッシュ値は f(A)= X とします。
このときに、f(B) = X となるようなBを発見するのが難しい性質がある事を
弱衝突耐性がある と言います。
「既にある何かにぶつける事が難しい」事ですね。
一方で強衝突耐性とは
f(C)=f(D) となる、任意のC,Dのペアを見つける事が難しい性質がある事です。これは
「ぶつかってしまう2つの物を発見することが難しい」事になります。
今回は、強衝突に対する脆弱性発見のお話ですね。
Re:確認させてください (スコア:0)
# 出先なのでAC
>今回は、強衝突に対する脆弱性発見のお話ですね。
この報告が限られたC,Dの組み合わせなのか、(少なくとも片方は)任意のC,Dなのか、
そこがインパクトの分かれ
Re:確認させてください (スコア:0)
強と弱というのは、耐性が強なのか弱なのかですよね。
だから、「強衝突耐性に対する脆弱性」ならわかるのですが、
「強衝突」と略してしまうと強弱が逆になってしまうような。
Re:確認させてください (スコア:0)
強衝突-耐性 ではなくて 強-衝突耐性 です。
Re:確認させてください (スコア:2, 参考になる)
MD5(M, N) = MD5(M', N')
M: 前半512ビット,N: 後半512ビット
M', N' はそれぞれ決まった位置の3ビットだけを変更したもの
となるような M と複数の N の組み合わせを見つけることができる.
ということなので,任意のメッセージではないと思います.p690(Regatta) [ibm.com]を使ってM を 1時間,N は 15秒から 5分で発見したみたいですね.
Re:確認させてください (スコア:1)
コリジョン発生数が多いのが問題?
コリジョン数が多ければ任意文章+パディングで
ハッシュ同値になるようパディングをつめるとき、
そのパディングを探し出すのが早くなってしまう。
いなんず[いつでも前向きでイタい]
Re:確認させてください (スコア:0)
Re:確認させてください (スコア:1)
あらゆるハッシュ値に対して
コリジョンを見つけるものだから
それはちょっときついかな。
解決策は二つ関数を使う、かなあ。
たとえばMD5とMD4でコリジョンの出方が違うから
2つ併用すればコリジョン確率はそうとう減るね・・・
いなんず[いつでも前向きでイタい]
Re:確認させてください (スコア:1)
?
併用って
/usr/bin/openssl dgst -md4 .bashrc | md5 ってこと?
結局 md5 に依存してません?
# 意味が違う?
## $ md4 .bashrc
## -bash: md4: command not found
## と怒られて man md4 を叩いたのは秘密だ。
Re:確認させてください (スコア:1)
> /usr/bin/openssl dgst -md4 .bashrc | md5 ってこと?
> 結局 md5 に依存してません?
> # 意味が違う?
そうじゃなくて、二つのハッシュ値を併記するってことじゃないですか。
その書き方に合わせるなら
/usr/bin/openssl dgst -md4 .bashrc ; md5 .bashrc
ってことで。
Re:確認させてください (スコア:0)
# 一々突っ込む気がしないけど、#607064 以下のツリーは読む価値無いと思うよ。
Re:確認させてください (スコア:0)
同意な気がしなくもないですが、ハッシュ値の話で「ヒント2倍で正解が
わかりやすくなる」てのも突っ込みたいポイントですよ。
Re:確認させてください (スコア:1)
この議論は署名の安全性について。
鍵を破る分にはコリジョンはさほどの脆弱性になんないけど
たとえばzipにくっついてるMD5ハッシュについては
攻撃しやすくなる、かなあと思う。
いなんず[いつでも前向きでイタい]
Re:確認させてください (スコア:1)
使いかたにもよるだろうけど、ファイルが本物であることを証明するためにハッシュを使うなら、
偽装のときに2つともコリジョンを発生させないといけないから有効な手段だと思います。
# あれ?まちがってるかなぁ
1を聞いて0を知れ!
Re:確認させてください (スコア:0)
MD5は1時間と数分でしょう (スコア:2, 興味深い)
論文には、 とありますので、最初に1時間くらいかかるけど、それが終われば15秒から数分で計算できる、と読めます。
それ以前に、この論文は不明瞭な点(our attack works for any given initial valueといっているのに、initial valueと計算式との関連がよく分からん、など)と明らかな誤植(Table-1の値で4バイトじゃないものがちらほら)があっていまいち理解できないのですが。
Re:MD5は1時間と数分でしょう (スコア:2, 参考になる)
4バイトになってないものは先頭の 0 が抜けているような感じです.
肝心の M, N を発見する方法がどこにも書いてない気がしますが...
-- 暑いからスーツはやめよう
Re:MD5は1時間と数分でしょう (スコア:2, 興味深い)
その1
@M = (0x02dd31d1, 0xc4eee6c5, 0x069a3d69, 0x5cf9af98,
0x87b5ca2f, 0xab7e4612, 0x3e580440, 0x897ffbb8,
0x0634ad55, 0x02b3f409, 0x8388e483, 0x5a417125,
0xe8255108, 0x9fc9cdf7, 0xf2bd1dd9, 0x5b3c3780);
@N1 = (0xd8823e31, 0x56348f5b, 0xae6dacd4, 0x36c919c6,
0xdd53e2b4, 0x87da03fd, 0x02396306, 0xd248cda0,
0xe99f3342, 0x0f577ee8, 0xce54b670, 0x80a80d1e,
0xc69821bc, 0xb6a88393, 0x96f9652b, 0x6ff72a70);
print pack ("I*", @M) . pack("N*", @N1);
その2
@M_ = (0x02dd31d1, 0xc4eee6c5, 0x069a3d69, 0x5cf9af98,
0x07b5ca2f, 0xab7e4612, 0x3e580440, 0x897ffbb8,
0x0634ad55, 0x02b3f409, 0x8388e483, 0x5a41f125,
0xe8255108, 0x9fc9cdf7, 0x72bd1dd9, 0x5b3c3780);
@N2 = (0xd8823e31, 0x56348f5b, 0xae6dacd4, 0x36c919c6,
0xdd53e234, 0x87da03fd, 0x02396306, 0xd248cda0,
0xe99f3342, 0x0f577ee8, 0xce54b670, 0x80280d1e,
0xc69821bc, 0xb6a88393, 0x96f965ab, 0x6ff72a70);
print pack ("I*", @M_) . pack("N*", @N2);
-- 暑いからスーツはやめよう
Re:MD5は1時間と数分でしょう (スコア:1)
論文などに当たってませんが (スコア:1)
とこれだけではなんなんで、CNET [cnet.com]の記事を紹介しておきます。
Re:論文などに当たってませんが (スコア:4, おもしろおかしい)
きっと研究者同士の連絡を平文のメールで行っていたのでしょう。
Re:論文などに当たってませんが (スコア:0)
Re:論文などに当たってませんが (スコア:0)
この記事のタイトルだけど、どう訳したら「暗号アルゴリズムに……」になるんだろうか(原文 [com.com])。
MD5とMD4に以前から知られていた脆弱性を実証しただけ (スコア:0)
Re:MD5とMD4に以前から知られていた脆弱性を実証した (スコア:2, おもしろおかしい)
# ないない
Re:MD5とMD4に以前から知られていた脆弱性を実証した (スコア:2, 興味深い)
Re:MD5とMD4に以前から知られていた脆弱性を実証した (スコア:0)
単語辞書とか文法辞書と組み合わせて出来たりして。
SHA-1についてそんな簡単に言われても… (スコア:2, 参考になる)
SHA-1 のハッシュ値は 160-bit 長ですから、ブルートフォース アタックのためには最大 2^160 回のハッシュ値計算が必要に なります。
比較となる大数を出せないのですが、現状では現実的では数字では ありません。
こうした一方向ハッシュ関数は固定長のハッシュ値を生成します ので、「衝突 (collision)」は絶対に存在し、「ブルートフォース アタックでいつかは衝突を突き止められる」というのは当然のこと です。
ですから、一方向ハッシュ関数の「強さ」は「ブルートフォース アタック以外の方法で衝突を見付けることの困難さ = 衝突耐性 (collision resistance)」で判断されます。
今回発見されたとされる欠陥は SHA-1 (ラウンド数が少ないもので はありますが) の衝突耐性を突破するものですから、素人目にも 「ちょっとヤバいのではないか?」と思われます。
本当に慌てる必要が無いのであれば、その理由をご教示いただけ れば幸いです。
(御指導御鞭撻いただきたいので、ID晒し)
Re:SHA-1についてそんな簡単に言われても… (スコア:1)
衝突耐性についての認識が間違っていました…。
攻撃方法云々は関係無く、衝突発見の困難さそのものを意味しているのですね。
やっぱり理解不足でした。失礼しました。
Re:MD5とMD4に以前から知られていた脆弱性を実証した (スコア:0)
ソースキボン。
衝突は見つかっていたもののあらゆるメッセージに適用できる
わけではなく、実際に悪用できるほどではない、と思っていた
んだけど。
Re:MD5とMD4に以前から知られていた脆弱性を実証した (スコア:2, 参考になる)
> わけではなく、実際に悪用できるほどではない、と思っていた
> んだけど。
man md5 [freebsd.org]
にもありますが、その認識で正しかったと思います。
心配なのは、この部分。
>> 他のハッシュ関数もラウンド数を減らした版の数年後には完全版
>> への攻撃がみつかっている。
実例も出ましたので、攻撃方法や攻撃対象が色々、発見されるかも。
# 悪用する人は、我々の想像できないような所から侵入してくる
Re:MD5とMD4に以前から知られていた脆弱性を実証した (スコア:0)
悪用法 (スコア:0)
Re:悪用法 (スコア:1)
Re:悪用法 (スコア:0)
偽の cookie を作って乗っ取る。
--
嘘ですよもちろん。念のため。
Re:悪用法 (スコア:1, 興味深い)
たしか噂で聞いたところでは、以前のバージョンでは、ファイルを何キロバイトかに分割してそれぞれの MD5 をとって、それらの XOR をハッシュと称していた? ために、ブロックの順番を入れ替えるだけで捏造ファイルが作れるだった、という話だったと思います。
電子署名はピンチなのか (スコア:0)
何に署名するかによるでしょうが、
少なくとも、自然言語文書に対する署名として用いる場合には、全く問題にならない
・・・・という理解で正しいですよね?
Re:電子署名はピンチなのか (スコア:2, おもしろおかしい)
フロッピーディスクにマジックで署名する場合には問題になりません.
Re:電子署名はピンチなのか (スコア:1, おもしろおかしい)
コカコーラのペットボトルに「飲むな!」と
マジックで書いても防止効果はありませんです。
#結局飲まれた上に完全オフトピなのでAC
Re:電子署名はピンチなのか (スコア:1, おもしろおかしい)
# シェイクしてあると効果抜群
Re:電子署名はピンチなのか (スコア:1)
当時、実際に薬品を扱っている家人が居たので
自分で書いたものしか飲めませんでした。
やり過ぎくらいがちょうどイイ
Re:電子署名はピンチなのか (スコア:0)
>・・・・という理解で正しいですよね?
素人ですが、その自然言語文書に電子署名したとしても
その正当性が弱くなってしまうのでは?
今回の発見で、本当の自分のキーを使った署名と同じ
署名が自分のキー以外で簡単に生成できてしまうということで