List of cryptgraphy - Baldanders.info
tag:Baldanders.info,2006-07-15:/tags
2006-07-15T16:13:23+09:00
バルトアンデルスは連続的な怪物,時間の怪物である。(ホルヘ・ルイス・ボルヘス 『幻獣辞典』より)
https://baldanders.info/images/avatar.jpg
https://baldanders.info/images/avatar.jpg
「安全な鍵長の下限」とは
tag:Baldanders.info,2006-07-15:/blog/000210/
2006-07-15T07:13:23+00:00
2006-07-15T07:13:23+00:00
「安全な鍵長の下限」とは
Spiegel
/profile/
<p>
先日書いた
<a href="https://baldanders.info/blog/000204/">「暗号の危殆化と新しいアルゴリズム」</a>
で署名・暗号に使う鍵の長さについて少しだけ言及しましたが,
(私が断定的に書いてしまったのが悪いのかもしれませんが)その部分だけ注目している方もいるようです。
そこで今回は暗号鍵のサイズについてもう少し細かく見ていくことにしましょう。
</p><p>
暗号アルゴリズムの危殆化(compromise)要因には色々あるのですが,
大まかに以下の3つに集約できると思います。
(<a href="http://www.ipa.go.jp/security/fy15/reports/crypt_requirement/index.html">「将来の暗号技術に関する安全性要件調査」</a>より引用)
</p><ol>
<li>暗号アルゴリズムの脆弱性(設計上の瑕疵など)</li>
<li>攻撃法の進歩(既存攻撃法の改良、新たな攻撃法の開発)</li>
<li>計算機性能の向上(解読計算能力の増大)</li>
</ol><p>
例えば<a href="https://baldanders.info/blog/000204/">前回</a>紹介した SHA-1 への攻略法は上記の1番目の要因に相当します。
もし1番目および2番目の要因がないとするなら,
3番目の要因を取り除くためには鍵のビット長を大きくすればいいことに気がつきます。
鍵のビット長を大きくすればそれだけ試行回数が増えるため解読に時間がかかることになるからです。
</p>
<div id="a000210more"><div id="more">
<p>
さて,
ここからは IPA/ISEC の
<a href="http://www.ipa.go.jp/security/fy15/reports/crypt_requirement/index.html">「将来の暗号技術に関する安全性要件調査」</a>
を見ながら説明していきましょう。
</p><p>
解読に時間がかかるといっても無限の時間をかければいつかは解読できるわけで,
そうなるとどれだけの時間をかければ安全といえるのかということになります。
<a href="http://www.ipa.go.jp/security/fy15/reports/crypt_requirement/index.html">「将来の暗号技術に関する安全性要件調査」</a>
では「1年間の解読計算によって解読される確率が0.1%未満である」ことを以って安全としているようです。
これは言い換えると「解読計算を1000年間行っても,鍵空間が探索し尽くせない」ことを意味します。
</p><p>
また解読計算を行うには膨大な計算リソースが必要になります。
今後ともムーアの法則(「計算機性能は同一コストで18ヶ月で2倍になる」という法則)が成り立つとしても予算は有限ですので,
調達コストやランニングコストを考えれば計算速度にも上限が存在することになります。
この場合,
予算をどのように見積もるかが鍵になりますが,
<a href="http://www.ipa.go.jp/security/fy15/reports/crypt_requirement/index.html">「将来の暗号技術に関する安全性要件調査」</a>
では以下の4つのケースを想定しています。
</p><div style="margin-left:1em;"><table>
<tbody><tr><td style="text-align:right;">中規模予算:</td><td style="text-align:left;">1000万ドル(約10億円)</td></tr>
<tr><td style="text-align:right;">大規模予算:</td><td style="text-align:left;">100億ドル(約1兆円)</td></tr>
<tr><td style="text-align:right;">超大規模予算:</td><td style="text-align:left;">経済規模最大国の GDP の4% (国防予算にほぼ匹敵)</td></tr>
<tr><td style="text-align:right;">限界規模予算:</td><td style="text-align:left;">世界の年間 GDP</td></tr>
</tbody></table></div><p>
なお,
計算機性能の向上には物理的な限界があると考えられていますが(つまりいつかはムーアの法則は破られる),
その限界点についての議論も行われているようです。
それによると,
クロック速度の相対論的限界はあと10の9乗(ビット換算で30ビット)程度,
集積度の量子論的限界もあと10の9乗(ビット換算で30ビット)程度,
エネルギー面からも1年間の太陽エネルギーを用いて187ビットの鍵空間を探索するのが限界だそうです。
もちろんこれは現在のコンピュータの延長として考えた場合の話で,
例えば量子コンピュータが実用化されるなど画期的な技術革新があれば崩れてしまいます。
まぁその場合にはそもそも鍵長による安全性云々という話も成り立たなくなる可能性もありますが。
</p><p>
このように様々な条件を考慮した上で安全な鍵長の下限はどのくらいになるのか調べていきます。
ここでは調べる対象となる暗号アルゴリズムが以下の条件を満たしていると仮定します。
</p><ul>
<li>共通鍵暗号</li>
<li>全数探索(総当り法)よりも効率的な解読法が存在しない</li>
<li>有意性検定のコストは無視できることとする</li>
</ul><p>
これら条件を満たした上で予測される安全な鍵長の下限を以下に挙げます。
(全部は多いので一部だけ)
</p><div style="margin-left:1em;"><table class="solid">
<tbody><tr><th> </th> <th>2003年</th> <th>2006年</th> <th>2010年</th> <th>2016年</th> <th>2018年</th> </tr>
<tr><td style="text-align:right;">対中規模予算攻撃</td> <td style="text-align:right;"> 93</td><td style="text-align:right;"> 95</td><td style="text-align:right;"> 97</td><td style="text-align:right;">100</td><td style="text-align:right;">101</td></tr>
<tr><td style="text-align:right;">対大規模予算攻撃</td> <td style="text-align:right;">103</td><td style="text-align:right;">105</td><td style="text-align:right;">107</td><td style="text-align:right;">110</td><td style="text-align:right;">111</td></tr>
<tr><td style="text-align:right;">対超大規模予算攻撃</td><td style="text-align:right;">108</td><td style="text-align:right;">110</td><td style="text-align:right;">113</td><td style="text-align:right;">116</td><td style="text-align:right;">117</td></tr>
<tr><td style="text-align:right;">対限界規模予算攻撃</td><td style="text-align:right;">114</td><td style="text-align:right;">116</td><td style="text-align:right;">119</td><td style="text-align:right;">122</td><td style="text-align:right;">123</td></tr>
</tbody></table></div><p>
この予測によれは,
今後10年に限れば128ビット程度の鍵長で十分ということになります。
</p><p>
ところで,
日本国外ではどのような評価をしているでしょうか。
軽く調べてみましたが,
これが結構あります。
代表的なものを以下にいくつか挙げてみます。
</p><ul>
<li><a href="http://www.comms.scitech.susx.ac.uk/fft/crypto/ECCFut.pdf">ECC, Future Resiliency and High Security Systems</a> (PDF)</li>
<li><a href="http://www.rsasecurity.com/rsalabs/node.asp?id=2088">A Cost-Based Security Analysis of Symmetric and Asymmetric Key Lengths</a></li>
<li><a href="http://rfc.net/rfc3766.html">RFC3766: Determining Strengths For Public Keys Used For Exchanging Symmetric Keys</a></li>
<li><a href="http://www.ecrypt.eu.org/documents/D.SPA.16-1.0.pdf">ECRYPT Yearly Report on Algorithms and Keysizes (2005)</a> (PDF)</li>
<li><a href="http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part1.pdf">NIST Special Publication 800-57: Recommendation for Key Management - Part 1: General (Revised)</a> (PDF)</li>
</ul><p>
特に欧州の <a href="http://www.ecrypt.eu.org/">ECRYPT (Network of Excellence in Cryptology)</a>による年次報告は各方面の調査結果が並べられていてとても参考になります。
ここではひとつだけ <a href="http://www.nist.gov/">NIST (National Institute of Standards and Technology)</a> SP800-57 における評価結果を紹介したいと思います。
</p><p>
まず鍵の強度について共通鍵暗号と公開鍵暗号とを比較した一覧があります。
</p><div style="margin-left:1em;"><table class="solid">
<tbody><tr> <th>Bits of security</th> <td style="text-align:right;">80</td> <td style="text-align:right;">112</td> <td style="text-align:right;">128</td> <td style="text-align:right;">192</td> <td style="text-align:right;">256</td></tr>
<tr><th>Symmetric key algorithm</th> <td style="text-align:right;">2TDEA</td> <td style="text-align:right;">3TDEA</td><td style="text-align:right;">AES-128</td><td style="text-align:right;">AES-192</td><td style="text-align:right;">AES-256</td></tr>
<tr> <th>FFC (e.g. DSA) L</th> <td style="text-align:right;">1024</td> <td style="text-align:right;">2048</td> <td style="text-align:right;">3072</td> <td style="text-align:right;">7680</td> <td style="text-align:right;">15360</td></tr>
<tr> <th>FFC (e.g. DSA) N</th> <td style="text-align:right;">160</td> <td style="text-align:right;">224</td> <td style="text-align:right;">256</td> <td style="text-align:right;">384</td> <td style="text-align:right;">512</td></tr>
<tr> <th>IFC (e.g. RSA) k</th> <td style="text-align:right;">1024</td> <td style="text-align:right;">2048</td> <td style="text-align:right;">3072</td> <td style="text-align:right;">7680</td> <td style="text-align:right;">15360</td></tr>
<tr> <th>ECC (e.g. ECDSA) f</th><td style="text-align:right;">160-233</td><td style="text-align:right;">224-225</td><td style="text-align:right;">256-383</td><td style="text-align:right;">384-511</td> <td style="text-align:right;">512+</td></tr>
</tbody></table></div><p>
TDEA というのは TripleDES のことです。
DES はかつて共通鍵暗号の標準(FIPS PUB 46-3)でしたが,
標準の座を AES に明け渡して2005年に完全に廃止になりました。
ただし TripleDES については新たに SP800-67 を発行しその中で TDEA (Triple Data Encryption Algorithm)として規格化されています。
</p><p>
同じようにハッシュ関数についても一覧があります。
</p><div style="margin-left:1em;"><table class="solid">
<tbody><tr> <th style="text-align:left;">Bits of security</th><td style="text-align:center;">80</td> <td style="text-align:center;">112</td> <td style="text-align:center;">128</td> <td style="text-align:center;">192</td> <td style="text-align:center;">256</td></tr>
<tr><th style="text-align:left;">Digital Signatures and hash-only applications</th><td>SHA-1, SHA-224, SHA-256, SHA-384, SHA-512</td><td>SHA-224, SHA-256, SHA-384, SHA-512</td> <td>SHA-256, SHA-384, SHA-512</td> <td>SHA-384, SHA-512</td> <td>SHA-512</td></tr>
<tr> <th style="text-align:left;">HMAC</th><td>SHA-1, SHA-224, SHA-256, SHA-384, SHA-512</td><td>SHA-1, SHA-224, SHA-256, SHA-384, SHA-512</td><td>SHA-1, SHA-224, SHA-256, SHA-384, SHA-512</td><td>SHA-224, SHA-256, SHA-384, SHA-512</td><td>SHA-256, SHA-384, SHA-512</td></tr>
<tr> <th style="text-align:left;">Key Derivation Functions</th><td>SHA-1, SHA-224, SHA-256, SHA-384, SHA-512</td><td>SHA-1, SHA-224, SHA-256, SHA-384, SHA-512</td><td>SHA-1, SHA-224, SHA-256, SHA-384, SHA-512</td><td>SHA-224, SHA-256, SHA-384, SHA-512</td><td>SHA-256, SHA-384, SHA-512</td></tr>
<tr> <th style="text-align:left;">Random Number Generation</th><td>SHA-1, SHA-224, SHA-256, SHA-384, SHA-512</td><td>SHA-1, SHA-224, SHA-256, SHA-384, SHA-512</td><td>SHA-1, SHA-224, SHA-256, SHA-384, SHA-512</td><td>SHA-224, SHA-256, SHA-384, SHA-512</td><td>SHA-256, SHA-384, SHA-512</td></tr>
</tbody></table></div><p>
ハッシュ関数の場合,
目的によって要求される強度(ここではハッシュ値のビットサイズ)が異なるためこのような表になっています。
また<a href="https://baldanders.info/blog/000204/">前回</a>述べたように,
SHA-1 は予定の性能を下回ることが指摘されていて,
2010年までに SHA-2 (SHA-224, SHA-256, SHA-384, SHA-512)に移行するようにとの<a href="http://csrc.nist.gov/CryptoToolkit/tkhash.html">声明</a>が出されました。
</p><p>
これらを踏まえて実際に安全な鍵長の下限がどの程度か挙げててみます。
</p><div style="margin-left:1em;"><table class="solid">
<tbody><tr> <th>Algorithm security lifetime</th><td>Through 2010<br/>(min. of 80 bits of strength)</td><td>Through 2030<br/>(min. of 112 bits of strength)</td><td>Beyond 2030<br/>(min. of 128 bits of strength)</td></tr>
<tr><th>Symmetric key algorithm<br/>(Encryption and MAC)</th><td>2TDEA, 3TDEA, AES-128, AES-192, AES-256</td> <td>3TDEA, AES-128, AES-192, AES-256</td> <td>AES-128, AES-192, AES-256</td> </tr>
<tr> <th>FFC (e.g. DSA) L</th><td>min.: 1024</td> <td>min.: 2048</td> <td>min.: 3072</td> </tr>
<tr> <th>FFC (e.g. DSA) N</th><td>min.: 160</td> <td>min.: 224</td> <td>min.: 256</td> </tr>
<tr> <th>IFC (e.g. RSA) k</th><td>min.: 1024</td> <td>min.: 2048</td> <td>min.: 3072</td> </tr>
<tr> <th>ECC (e.g. ECDSA) f</th><td>min.: 160</td> <td>min.: 224</td> <td>min.: 256</td> </tr>
</tbody></table></div><p>
先の IPA/ISEC の評価(こちらは2018年までしかないので簡単に比べられませんが)より若干緩い感じですね。
現状では AES-128 よりも強い暗号は必要なさそうです。
共通鍵暗号に関しては他も大体同じような結果になっていますが(ECRYPT の報告は少し厳しいですが),
公開鍵暗号に関しては報告書によってばらつきが大きいため参考程度に留めておくのがいいかもしれません。
パッと見の印象では今回紹介した NIST の報告がバランスが取れていて妥当なところではないでしょうか。
</p><p>
以上で署名・暗号に使う鍵の長さについて大体イメージできたのではないでしょうか。
最初に述べたように暗号の危殆化には様々な要因があり,
「鍵長を大きくしたから安心」というようなものでもありません。
暗号技術を含むシステムを開発・運用している方々は常に技術の最新動向に注意しておく必要があります。
この記事が何らかの手助けになれば幸いです。
</p><p>
参考:
</p><ul>
<li><a href="http://www.ipa.go.jp/security/fy16/reports/crypt_compromize/index.html">暗号の危殆化に関する調査</a></li>
<li><a href="http://www.cryptrec.jp/topics/cryptrec_20060525_c05report.html">CRYPTREC Report 2005の公開</a> (5月に改訂版がリリース)</li>
<li><a href="http://www.atmarkit.co.jp/fsecurity/rensai/crypt05/crypt01.html">デファクトスタンダード暗号技術の大移行 第5回 鍵長をどのように選択していくか~等価安全性と鍵長の関係</a></li>
</ul>
</div></div>
暗号の危殆化と新しいアルゴリズム
tag:Baldanders.info,2006-07-05:/blog/000204/
2006-07-04T15:04:17+00:00
2006-07-04T15:04:17+00:00
暗号の危殆化と新しいアルゴリズム
Spiegel
/profile/
<p>
先日 <a href="http://lists.gnupg.org/pipermail/gnupg-announce/2006q2/000226.html">GnuPG 1.4.4 がリリース</a>されました。
このバージョンではセキュリティ脆弱性の修正のほかに新しいアルゴリズムが2つ追加されています。
この記事ではこれらのアルゴリズムが追加された背景について簡単に説明したいと思います。
</p>
<div id="a000204more"><div id="more">
<p>
今回追加されたアルゴリズムは「電子署名」に関するものです。
2004年8月に発表された MD4/5 および RIPEMD 等の一方向ハッシュ関数(以降単に「ハッシュ関数」と略称します)の脆弱性に関する論文および2005年2月に発表された SHA-1 攻略の可能性に関する論文は暗号の世界に大きな波紋を呼びました。
ハッシュ関数というのは任意のデータを一定サイズのハッシュ値に「要約」するアルゴリズムで,
</p><ul>
<li>ハッシュ値から元のデータを推測できない</li>
<li>ひとつのハッシュ値に対し複数のデータが(実時間で)見つからない</li>
</ul><p>
という特徴があります。
「ひとつのハッシュ値に対し複数のデータが見つからない」といっても無限の時間をかければいつかは見つかるわけで,
その見つかりやすさは(よいアルゴリズムであれば)概ねハッシュ値のサイズに依存する(ハッシュ値のサイズを n として 2 の n/2 乗分の 1 の確率)といってよいでしょう。
例えば SHA-1 のハッシュ値のサイズは160ビットなので,
確率は 2 の 80 乗分の 1,
つまり 2 の 80 乗回試せばひとつは同じハッシュ値を持つデータの組を見つけることができる(これをハッシュ値の衝突(Collision)と呼びます)ということになります。
しかし件の論文によると,
それよりも大きな 2 の 69 乗分の 1 の確率で衝突を起こす攻略方法があるらしいのです。
この論文の内容については現在も検証が行われていますが,
専門家の間では概ね正しいだろうと言われています。
</p><p>
SHA-1 は電子署名や認証アルゴリズム等に広く使われている標準アルゴリズムです。
その SHA-1 が所定の性能を発揮できないかもしれないということで,
これらを使うシステムはできるだけ早く手を打たなければならなくなりました。
幸いアメリカでは2004年の時点で NIST による声明が出され,
2010年までに SHA-1 の運用を終了し SHA-2 (SHA-224, SHA-256, SHA-384, SHA-512 の総称)に移行することが決まっています。
日本でも評価機関である <a href="http://www.cryptrec.jp/">CRYPTREC</a> が政府に対し SHA-256, SHA-384, SHA-512 を新たに加えるよう提言しています。
(現在の電子署名法では SHA-1 のみ規定されています。
なお SHA-1 の問題に関する詳しい経緯は<a href="http://www.cryptrec.jp/topics/cryptrec_20060525_c05report.html">「CRYPTREC Report 2005」</a>が参考になります)
</p><p>
電子署名についてはもうひとつ問題があります。
署名アルゴリズムの標準のひとつである DSA の仕様により事実上 SHA-2 が使えないことです。
(NIST では DSS (電子署名標準)として RSA 署名も許容しているため,全く使えないわけではないですが)
</p><p>
DSA は ElGamal 署名の改良版で,
物凄く簡単に言うと以下の特徴があります。
</p><ul>
<li>512ビットから1,024ビットの鍵長</li>
<li>被署名データは160ビット固定</li>
<li>署名データ長は320ビット</li>
</ul><p>
しかしこれから10年後を考えると1,024ビットまでの鍵長しか扱えないのは頼りないです。
なにより被署名データが160ビット固定というのは運用上あまり便利ではありません。
DSA が SHA-2 と組み合わせて使えない理由はここにあります。
(SHA-2 のハッシュ値のサイズは224ビットから512ビット)
</p><p>
そこでアメリカの NIST では2006年3月の FIPS186-3 ドラフト案で DSA のアルゴリズムを変更しました。
</p><ul>
<li><a href="http://csrc.nist.gov/publications/drafts/fips_186-3/Draft-FIPS-186-3%20_March2006.pdf">Draft Federal Information Processing Standard (FIPS) 186-3 - Digital Signature Standard (DSS) </a> -- PDF</li>
</ul><p>
このドラフト案では DSA の鍵長を3,072ビットまで拡張しました。
各鍵長と被署名データの組み合わせは以下のとおりです。
</p><div style="margin-left:4em;"><table class="solid">
<tbody><tr><th>L</th><th>N</th></tr>
<tr><td>1,024</td><td>160</td></tr>
<tr><td>2,048</td><td>224</td></tr>
<tr><td>2,048</td><td>256</td></tr>
<tr><td>3,072</td><td>256</td></tr>
</tbody></table></div><p>
L が鍵長で N が被署名データのサイズです。
FIPS186-3 ドラフト案ではこの組み合わせの中から選択して使うべきとしています。
</p><p>
ところで署名・暗号に使う鍵の長さはどの程度が適当でしょうか。
確かに長ければ長いほど安全といえますが,
長すぎる鍵はとりまわしが不便です。
この件については IPA/ISEC による
<a href="http://www.ipa.go.jp/security/fy15/reports/crypt_requirement/index.html">「将来の暗号技術に関する安全性要件調査」</a>
が参考になります。
詳しい内容はそちらを読んでいただくとして,
結論としては,
今後10年のスパンで考えるなら共通鍵暗号の鍵で128ビット程度で十分なようです。
128ビットの共通鍵暗号鍵を公開鍵暗号鍵に換算するとどの程度になるかは難しいですが(先ほど紹介した調査報告書では参考値としながらもかなり大きい鍵を要求しているように読めましたが),
これについては RSA Security による
<a href="http://www.rsasecurity.com/rsalabs/node.asp?id=2088">「A Cost-Based Security Analysis of Symmetric and Asymmetric Key Lengths」</a>
が参考になります。
これによると128ビットの共通鍵暗号鍵は RSA 鍵では1,620ビット(EC 鍵では256ビット)に相当するようです。
DSA も似たようなものだとすると,
まぁ多めに見積もっても2,048ビットもあれば十分ということになります。
総合すると,
共通鍵暗号は AES128 以上,
公開鍵暗号は RSA/DSA なら2,048ビット以上,
ハッシュ関数は SHA-2 (SHA-224, SHA-256, SHA-384, SHA-512)
という標準の組み合わせでも「あと10年はもつ」ということになると思います。
もっとも暗号の危殆化は様々な条件で発生する可能性がありますので,
これで安心してはダメですが。
(追記: 鍵長による安全性については<a href="https://baldanders.info/blog/000210/">「「安全な鍵長の下限」とは」</a>も参照してください)
</p><p>
GnuPG 1.4.4 では FIPS186-3 ドラフト案に従って SHA-224 と新しい DSA (ここではリリースノートに従って「DSA2」と表記します)が追加されました。
また DSA 署名で SHA-2 が使えるようになりました。
早速試してみたいと思います。
まず従来の DSA 鍵を作成します(作成方法は割愛します)。
作成した公開鍵を <a href="http://pgp.iijlab.net/pgpdump.html">pgpdump</a> でダンプすると以下のような感じになります。
</p><blockquote>
<pre><code>Old: Public Key Packet(tag 6)(418 bytes)
Ver 4 - new
Public key creation time - Tue Jul 04 23:10:28 東京 (標準時) 2006
Pub alg - DSA Digital Signature Algorithm(pub 17)
DSA p(1024 bits) - ...
DSA q(160 bits) - ...
DSA g(1024 bits) - ...
DSA y(1022 bits) - ...
Old: User ID Packet(tag 13)(35 bytes)
User ID - user1 (by DSA) <user1@exsample.com>
Old: Signature Packet(tag 2)(96 bytes)
Ver 4 - new
Sig type - Positive certification of a User ID and Public Key packet(0x13).
Pub alg - DSA Digital Signature Algorithm(pub 17)
Hash alg - SHA1(hash 2)
Hashed Sub: signature creation time(sub 2)(4 bytes)
Time - Tue Jul 04 23:10:28 東京 (標準時) 2006
Hashed Sub: key flags(sub 27)(1 bytes)
Flag - This key may be used to certify other keys
Flag - This key may be used to sign data
Hashed Sub: preferred symmetric algorithms(sub 11)(5 bytes)
Sym alg - AES with 256-bit key(sym 9)
Sym alg - AES with 192-bit key(sym 8)
Sym alg - AES with 128-bit key(sym 7)
Sym alg - CAST5(sym 3)
Sym alg - Triple-DES(sym 2)
Hashed Sub: preferred hash algorithms(sub 21)(3 bytes)
Hash alg - SHA1(hash 2)
Hash alg - SHA256(hash 8)
Hash alg - RIPEMD160(hash 3)
Hashed Sub: preferred compression algorithms(sub 22)(3 bytes)
Comp alg - ZLIB <RFC1950>(comp 2)
Comp alg - BZip2(comp 3)
Comp alg - ZIP <RFC1951>(comp 1)
Hashed Sub: features(sub 30)(1 bytes)
Flag - Modification detection (packets 18 and 19)
Hashed Sub: key server preferences(sub 23)(1 bytes)
Flag - No-modify
Sub: issuer key ID(sub 16)(8 bytes)
Key ID - 0x9711CD433316266D
Hash left 2 bytes - 40 d0
DSA r(158 bits) - ...
DSA s(159 bits) - ...
-> hash(160 bits)</code></pre>
</blockquote><p>
「<code>preferred hash algorithms</code>」に <code>SHA256</code> が加わっているのが分かるでしょうか。
実際に
</p><blockquote>
<pre><code>gpg --digest-algo sha256 -sa -u user1 text.txt</code></pre>
</blockquote><p>
などとやっても動作します。
どうやら SHA-256 で作成したハッシュ値を更に折りたたんで(?)160ビットにしているようです。
</p><blockquote>
<pre><code>Old: Compressed Data Packet(tag 8)
Comp alg - ZIP <RFC1951>(comp 1)
Old: One-Pass Signature Packet(tag 4)(13 bytes)
New version(3)
Sig type - Signature of a binary document(0x00).
Hash alg - SHA256(hash 8)
Pub alg - DSA Digital Signature Algorithm(pub 17)
Key ID - 0x9711CD433316266D
Next packet - other than one pass signature
Old: Literal Data Packet(tag 11)(2004 bytes)
Format - binary
Filename - text.txt
File modified time - Tue Jul 04 23:12:43 東京 (標準時) 2006
Literal - ...
Old: Signature Packet(tag 2)(63 bytes)
Ver 3 - old
Hash material(5 bytes):
Sig type - Signature of a binary document(0x00).
Creation time - Tue Jul 04 23:12:43 東京 (標準時) 2006
Key ID - 0x9711CD433316266D
Pub alg - DSA Digital Signature Algorithm(pub 17)
Hash alg - SHA256(hash 8)
Hash left 2 bytes - 8d 46
DSA r(159 bits) - ...
DSA s(158 bits) - ...
-> hash(160 bits)</code></pre>
</blockquote><p>
今度は DSA2 鍵を作ってみます。
DSA2 鍵を作るには <code>--enable-dsa2</code> オプションをつけて起動します。
鍵長は2,048ビットにしておきましょう。
同じように <a href="http://pgp.iijlab.net/pgpdump.html">pgpdump</a> で内容をダンプしてみます。
</p><blockquote>
<pre><code>Old: Public Key Packet(tag 6)(810 bytes)
Ver 4 - new
Public key creation time - Tue Jul 04 23:15:09 東京 (標準時) 2006
Pub alg - DSA Digital Signature Algorithm(pub 17)
DSA p(2048 bits) - ...
DSA q(224 bits) - ...
DSA g(2048 bits) - ...
DSA y(2047 bits) - ...
Old: User ID Packet(tag 13)(36 bytes)
User ID - user2 (by DSA2) <user2@exsample.com>
Old: Signature Packet(tag 2)(112 bytes)
Ver 4 - new
Sig type - Positive certification of a User ID and Public Key packet(0x13).
Pub alg - DSA Digital Signature Algorithm(pub 17)
Hash alg - unknown(hash 11)
Hashed Sub: signature creation time(sub 2)(4 bytes)
Time - Tue Jul 04 23:15:09 東京 (標準時) 2006
Hashed Sub: key flags(sub 27)(1 bytes)
Flag - This key may be used to certify other keys
Flag - This key may be used to sign data
Hashed Sub: preferred symmetric algorithms(sub 11)(5 bytes)
Sym alg - AES with 256-bit key(sym 9)
Sym alg - AES with 192-bit key(sym 8)
Sym alg - AES with 128-bit key(sym 7)
Sym alg - CAST5(sym 3)
Sym alg - Triple-DES(sym 2)
Hashed Sub: preferred hash algorithms(sub 21)(3 bytes)
Hash alg - SHA1(hash 2)
Hash alg - SHA256(hash 8)
Hash alg - RIPEMD160(hash 3)
Hashed Sub: preferred compression algorithms(sub 22)(3 bytes)
Comp alg - ZLIB <RFC1950>(comp 2)
Comp alg - BZip2(comp 3)
Comp alg - ZIP <RFC1951>(comp 1)
Hashed Sub: features(sub 30)(1 bytes)
Flag - Modification detection (packets 18 and 19)
Hashed Sub: key server preferences(sub 23)(1 bytes)
Flag - No-modify
Sub: issuer key ID(sub 16)(8 bytes)
Key ID - 0x31B8A040D442790A
Hash left 2 bytes - 3d 84
DSA r(222 bits) - ...
DSA s(219 bits) - ...
-> hash(160 bits)</code></pre>
</blockquote><p>
鍵への自己署名のハッシュ関数が「<code>unknown(hash 11)</code>」となっているのは <a href="http://pgp.iijlab.net/pgpdump.html">pgpdump</a> が SHA-224 に対応していないためです。
最新の <a href="http://www.ietf.org/html.charters/openpgp-charter.html">OpenPGP ドラフト案</a>では「hash 11」は SHA-224 が割り当てられているので,
この鍵の自己署名には SHA-224 が使われていると言えます。
</p><p>
注意していただきたいのは DSA でも DSA2 でも情報としては同じ「pub 17」として格納されているということです。
DSA と DSA2 は内部的には別のアルゴリズムですが,
データ上は区別できません(パラメータから判断することもできなくはないですが)。
おそらく FIPS186-3 ドラフト案がこれまでの DSA と新しい DSA を区別する記述になっていないからでしょうが,
このまま行くと深刻な互換性の問題を抱えてしまうように思います。
新しい DSA アルゴリズムはまだドラフト段階であり,
また対応するアプリケーションも他になさそうなので実装が固まるまでは業務用としては手を出さないほうがいいように思います。
</p><p>
参考:
</p><ul>
<li><a href="http://mailsrv.nara-edu.ac.jp/~asait/crypt.htm">暗号の話</a></li>
<li><a href="https://baldanders.info/blog/000048/">ハッシュ値の衝突問題</a>
</li><li><a href="http://www.rsasecurity.com/rsalabs/node.asp?id=2088">A Cost-Based Security Analysis of Symmetric and Asymmetric Key Lengths</a></li>
<li><a href="http://www.ipa.go.jp/security/fy15/reports/crypt_requirement/index.html">将来の暗号技術に関する安全性要件調査</a></li>
<li><a href="http://www.ipa.go.jp/security/fy16/reports/crypt_compromize/index.html">暗号の危殆化に関する調査</a></li>
<li><a href="http://www.cryptrec.jp/topics/cryptrec_20060525_c05report.html">CRYPTREC Report 2005の公開</a> (5月に改訂版がリリース)</li>
<li><a href="http://www.atmarkit.co.jp/fsecurity/rensai/crypt01/crypt01.html">デファクトスタンダード暗号技術の大移行 第1回 すべてはここから始まった~SHA-1の脆弱化</a></li>
<li><a href="http://homepage.mac.com/mio_rhapsody/gnupg/HowToSetUpGPGtoUseDSA2.html">GnuPG のデジタル署名で DSA2 と SHA-256, SHA-384, SHA-512 を使う方法</a></li>
</ul>
</div></div>
ハッシュ値の衝突問題
tag:Baldanders.info,2004-08-19:/blog/000048/
2004-08-19T05:14:30+00:00
2004-08-19T05:14:30+00:00
ハッシュ値の衝突問題
Spiegel
/profile/
<p>
(この記事は<a href="http://spiegel.cocolog-nifty.com/">「もっと辺境から戯れ言」</a>に投稿した記事からの転載です)
</p><p>
<a href="http://tb.japan.cnet.com/tb.php/20070525">「やばいかも」</a>の続き。
追加の情報と併せてもう一度関連記事を挙げておきます。
</p><ul>
<li><a href="http://eprint.iacr.org/2004/199/">Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD</a> (差し替え版が出ているようです)</li>
<li><a href="http://japan.cnet.com/news/sec/story/0,2000050480,20070525,00.htm">暗号アルゴリズムに重大な欠陥発見の報告相次ぐ</a></li>
<li><a href="http://slashdot.jp/article.pl?sid=04/08/18/0257220">SHA-0、MD5、 MD4にコリジョン発見、reduced SHA-1も</a></li>
<li><a href="http://www.rtfm.com/movabletype/">「Educated Guesswork」</a>にも情報あり</li>
<li><a href="http://www.hyuki.com/diary/dia0408.html#i19_03">「結城浩の日記」にも検証記事</a>があります</li>
</ul><p>
(以降、<a href="https://baldanders.info/spiegel/archive/CollisionsForHashFunctions.html">最新情報はこちらのページでフォロー</a>してます)
</p><p>
e-Print 版は速報性が優先されているせいか間違いが結構あるようですね。
詳細な検証はこれからのようです。
</p><p>
MD4/5 とか SHA-0/1/2 などは「一方向ハッシュ関数」とか「メッセージ要約関数」などと呼ばれていて暗号技術、特に電子署名において重要な役割を果たします。
一方向ハッシュ関数では任意のデータを小さなデータ列(MD5 では 128bit、 SHA-1 や RIPEMD160 では 160bit など)に「要約」します。
</p><p>
「要約」されたデータ(「ハッシュ値」と呼ばれます)から元のデータを復元することはできません。
またデータを「要約」する際、
異なる元データから同じハッシュ値が生成されないことが要求されます。(異なる元データから同じハッシュ値が生成されてしまうことを「衝突(Collision)」と呼びます)
</p><p>
しかし数学的には「衝突」が起きる確率をゼロにすることはできません。
したがって「衝突」が起きる確率が「実用上ほぼ」ゼロとなるロジックを検討することになります。
こうしてできたのが MD4/5 や SHA-0/1/2 などのアルゴリズムです。
</p><p>
今回の論文で指摘されているのは、
同じハッシュ値を持つデータ群を簡単に生成できてしまう方法です。
頻繁に「衝突」を起こせるということは暗号技術の要件(「機密性」「完全性」「認証」「否認防止」)のうちのひとつ「完全性」を損なうことになります。
また「完全性」は「認証」「否認防止」の要件のひとつになっているため、
「認証」「否認防止」も損なわれることになります。
</p><p>
ハッシュ値の衝突問題がどの程度のインパクトを与えるのか、
また既存のアルゴリズムに対して回避策があるのかないのかといった点は今後の専門家による検証に委ねられることになります。
今後も注目して情報を追いかけていく必要がありそうです。
</p>
<div id="a000048more"><div id="more">
<p>
(8/24 追記)
</p><p>
その後の記事をいくつか見る限り(<a href="https://baldanders.info/spiegel/archive/CollisionsForHashFunctions.html">CollisionsForHashFunctions</a> 参照)、
現行で使われている一方向ハッシュ関数のアルゴリズムに今すぐインパクトを与えるものではないようです。
しかし引き続いて情報を追いかけていく必要がありそうです。
</p><p>
日本では <a href="http://www.ipa.go.jp/security/enc/CRYPTREC/index.html">CRYPTREC</a> による暗号技術の評価レポートがあります。
このレポートによると MD5 はすでに推奨されていません(MD5 には今回の事例以外にもいくつかの脆弱性が発見されています)。
またハッシュ値の bit 長についても
「新たな電子政府用システムを構築する場合、より長いハッシュ値のものが使用できるのであれば、256ビット以上のハッシュ関数を選択することが望ましい」
とあります。(実際にそういう設計になっているかどうかは怪しいですが)
</p><p>
ちなみに <a href="http://www.cosic.esat.kuleuven.ac.be/nessie/">NESSIE (New European Schemes for Signatures, Integrity, and Encryption)</a> では SHA-1 は既にリストから外れています。
</p><p>
なお暗号および暗号技術については、
まず結城浩さんの<a href="http://www.hyuki.com/cr/index.html">『暗号技術入門 ―― 秘密の国のアリス』</a>を読まれることをお薦めします。
</p><blockquote>
<div class="bk1-box" style="margin-bottom:0px;"><div class="bk1-image" style="float:left;"><a href="http://www.bk1.co.jp/product/2347782/p-spiegel43226" name="bk1link" title="オンライン書店ビーケーワン:暗号技術入門" target="_blank"><img src="http://img.bk1.co.jp/bookimages/0234/023477820000.jpg" alt="暗号技術入門" style="border: thin outset #EEEEEE"/></a></div><div class="bk1-info" style="float:left;margin-left:15px;line-height:120%"><div class="bk1-name" style="margin-bottom:10px;line-height:120%"><a href="http://www.bk1.co.jp/product/2347782/p-spiegel43226" name="bk1link" title="オンライン書店ビーケーワン:暗号技術入門" target="_blank">暗号技術入門</a><div class="bk1-powered-date" style="font-size:7pt;margin-top:5px;font-family:verdana;line-height:120%">posted with <a href="http://breeder.bk1.jp/cgi-bin/link/create.cgi?bibid=2347782&partnerid=p-spiegel43226" title="簡単リンクくん" target="_blank">簡単リンクくん</a> at 2006. 7. 4</div></div><div class="bk1-detail">結城 浩著<br/>ソフトバンクパブリッシング (2003.9)<br/>通常2-3日以内に発送します。<br/></div><div class="bk1-link" style="margin-top: 5px"><a href="http://www.bk1.co.jp/product/2347782/p-spiegel43226" name="bk1link" title="オンライン書店ビーケーワン" target="_blank">オンライン書店ビーケーワンで詳細を見る</a></div></div><div class="bk1-footer" style="clear: left"></div></div>
</blockquote>
</div></div>