List of dsa - Baldanders.info
tag:Baldanders.info,2014-09-18:/tags
2014-09-18T09:00:00+00:00
バルトアンデルスは連続的な怪物,時間の怪物である。(ホルヘ・ルイス・ボルヘス 『幻獣辞典』より)
https://baldanders.info/images/avatar.jpg
https://baldanders.info/images/avatar.jpg
CRYPTREC Report 2013
tag:Baldanders.info,2014-09-18:/blog/000740/
2014-09-18T09:00:00+00:00
2014-09-18T09:00:00+00:00
8月に CRYPTREC Report 2013 が出てたのに気付かず。ここでは「暗号技術評価委員会報告書」で挙がっている主なトピックを紹介する。
Spiegel
/profile/
<p> 8月に CRYPTREC Report 2013 が出てたのに気付かず。 </p><ul> <li><a href="http://www.cryptrec.go.jp/topics/cryptrec_20140811_c13report.html">CRYPTREC Report 2013の公開</a> <ul> <li><a href="http://www.cryptrec.go.jp/report/c13_eval_web_final.pdf">CRYPTREC Report 2013 暗号技術評価委員会報告書<sup><i class="far fa-file-pdf"></i></sup></a></li> <li><a href="http://www.cryptrec.go.jp/report/c13_prom_web_final.pdf">CRYPTREC Report 2013 暗号技術活用委員会報告書<sup><i class="far fa-file-pdf"></i></sup></a></li> <li><a href="http://www.cryptrec.go.jp/report/c13_tech_guideline_TLSSSL_web.pdf">CRYPTREC 暗号技術ガイドライン (SSL/TLS における近年の攻撃への対応)<sup><i class="far fa-file-pdf"></i></sup></a></li> <li><a href="http://www.cryptrec.go.jp/report/c13_tech_guideline_SHA-1_web.pdf">CRYPTREC 暗号技術ガイドライン (SHA-1)<sup><i class="far fa-file-pdf"></i></sup></a></li> </ul></li> </ul><p> あと CRYPTREC Report じゃないけど,昨年大騒ぎになった </p><ul> <li><a href="http://www.cryptrec.go.jp/topics/cryptrec_20131106_dual_ec_drbg.html">擬似乱数生成アルゴリズム Dual_EC_DRBG について</a></li> </ul><p> も併せてどうぞ。 </p><p> セキュリティ管理に関わっている人は最低でも「暗号技術評価委員会報告書」は読んでおくとよい。 ちなみに SSL/TLS と SHA-1 の暗号技術ガイドラインは「暗号技術評価委員会報告書」にも含まれている。 </p><p> ここでは「暗号技術評価委員会報告書」で挙がっている主なトピックを紹介する。 </p> <ol> <li><a href="#pubkey">公開鍵暗号に関する安全性評価</a></li> <li><a href="#sha3">ハッシュ関数について</a></li> <li><a href="#dsa">FIPS PUB 186-4</a></li> <li><a href="#tls12">SP800-52 revision 1 と TLS 1.2</a></li> <li><a href="#pfs">perfect forward secrecy と forward secrecy</a></li> <li><a href="#key-exch">SSL/TLS における DHE, DH, RSA の安全性評価</a></li> <li><a href="#rnd">擬似乱数生成アルゴリズム Dual_EC_DRBG</a></li> <li><a href="#light-cipher">軽量暗号</a></li> </ol> <section id="pubkey"> <h3>公開鍵暗号に関する安全性評価</h3> <figure> <blockquote> <q>昨年の Crypto 2012 で A.K. Lenstra らは、実社会に公開されている RSA 公開鍵証明書(X.509)に、異なる署名に同じ modulus が使われていたり、modulus が素因数分解できたりといった問題を指摘した。これに続き、 Asiacrypt 2013 において N. Heninger らは、台湾市民向けのスマートカードで利用される公開鍵証明書約300万件について、同じ問題点があることと、Coppersmith 攻撃によって新たな素因数分解が可能となったことを示した。 <br/>楕円曲線暗号に関しては、Asiacrypt 013 のランプセッションにおいて J.W. Bos らが、実際に暗号通信(TLS/SSH)で利用されている証明書を調べ、TLS 公開鍵の 4%(20 万個)、SSH公開鍵の 30%(40 万個)に同じものが使用されている問題点を確認した。また、Bitcoin において、同じ nonce の存在が利用されており、59 BTC が盗難されたとしている。</q> </blockquote> <figcaption><q><a href="http://www.cryptrec.go.jp/report/c13_eval_web_final.pdf">CRYPTREC Report 2013 暗号技術評価委員会報告書<sup><i class="far fa-file-pdf"></i></sup></a></q>より</figcaption> </figure> <p> ということで,実装上の脆弱性が浮き彫りになった。 スマートカードのようにハードウェアに組み込むタイプのものは,いったん脆弱性や危殆化が発覚すると対処が難しい。 なので,やはり「事後」の対処がとても重要になってくる。(下手に隠蔽したり判断をミスったりすれば被害を拡大させてしまう) </p><p> ちなみに<a href="http://www.converterhub.com/index.php?sum=59&from=BTC&to=JPY">59BTCは290万円くらい</a>らしい。 </p> </section> <section id="sha3"> <h3>ハッシュ関数について</h3> <p> <a href="https://baldanders.info/blog/000702/">以前も述べた</a>が FIPS PUB 202 (SHA-3 Standard) のドラフトが登場している(パブリックコメントは既に終了している)。 </p><ul> <li><a href="http://csrc.nist.gov/publications/drafts/fips-202/fips_202_draft.pdf">DRAFT FIPS PUB 202: SHA-3 Standard<sup><i class="far fa-file-pdf"></i></sup></a></li> </ul><p> 正式リリースは来年以降かな? </p> </section> <section id="dsa"> <h3>FIPS PUB 186-4</h3> <p> FIPS PUB 186-4 が登場している。 </p><ul> <li><a href="http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf">FIPS PUB 186-4: Digital Signature Standard (DSS)<sup><i class="far fa-file-pdf"></i></sup></a></li> </ul> <figure> <blockquote> <q>補助関数(ハッシュ関数、KDF、及び、擬似乱数生先の変更を認 成系、素数生成や楕円曲線生成等の基本的なアルゴリズム)を除いた、当該アルゴリズムを実装するための必要最小限の範囲において、パラメータ修正等の簡易な修正である。</q> </blockquote> <figcaption><q><a href="http://www.cryptrec.go.jp/report/c13_eval_web_final.pdf">CRYPTREC Report 2013 暗号技術評価委員会報告書<sup><i class="far fa-file-pdf"></i></sup></a></q>より</figcaption> </figure> <p> とのこと。 </p> </section> <section id="tls12"> <h3>SP800-52 revision 1 と TLS 1.2</h3> <p> 近年の SSL/TLS への攻撃(BEAST, CRIME, TIME. BREACH, Lucky Thirteen, Renegotiation)や <a href="https://baldanders.info/blog/000626/">RC4 の危殆化</a>を鑑み, TLS 1.2 へのアップデートが推奨されている。 </p> <figure> <blockquote> <q>推奨される設定として、TLS 1.0 より古いバージョンについては、新しいバージョンへアップデートすることが推奨される。TLS 1.0 については、CBC モードを用いた場合の脆弱性に対してパッチが提供されているため、Java 等のソフトウェアを最新版に更新した上で、CBC モードを選択することが推奨される。TLS 1.1 については、CBC モードを用いた場合の脆弱性が解消されていることから、CBC モードを選択することが推奨される。 TLS1.2 については、CBC モード、CCM モード、GCM モードが選択できるため、それらを使うことが推奨される。</q> </blockquote> <figcaption><q><a href="http://www.cryptrec.go.jp/report/c13_eval_web_final.pdf">CRYPTREC Report 2013 暗号技術評価委員会報告書<sup><i class="far fa-file-pdf"></i></sup></a></q>より</figcaption> </figure> <p> NIST では SP800-52 revision 1 を発行し TLS 1.2 への対応を行うことを進めている。 </p><ul> <li><a href="http://www.nist.gov/itl/csd/tls-043014.cfm">NIST Revises Guide to Use of Transport Layer Security (TLS) in Networks</a></li> <li><a href="http://www.nist.gov/manuscript-publication-search.cfm?pub_id=915295">Publication Citation: Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations</a></li> <li><a href="http://threatpost.com/federal-agencies-told-to-support-tls-1-2-by-2015/105906">NIST SP 800-52 Revision 1 Recommends TLS 1.2 by Jan. 1, 2015 | Threatpost | The first stop for security news</a></li> </ul> <figure> <blockquote> <q lang="en">“Servers that support government-only applications shall be configured to support TLS 1.1, and should be configured to support TLS 1.2,” the document says. “These servers shall not support TLS 1.0, SSL 2.0, or SSL 3.0.”</q> </blockquote> <figcaption>via <q lang="en"><a href="http://threatpost.com/federal-agencies-told-to-support-tls-1-2-by-2015/105906">NIST SP 800-52 Revision 1 Recommends TLS 1.2 by Jan. 1, 2015</a></q></figcaption> </figure> <section> <h4>ところでクライアント側はどうなっているだろう</h4> <p> 主要ブラウザは TLS 1.2 のサポートを完了しているようだ。 </p><ul> <li>Google Chrome は 30 から全プラットフォームで正式対応</li> <li>Mozilla Firefox は 27 から全プラットフォームで正式対応</li> <li>Internet Explorer は 11 から既定で有効になっている(Windows Vista および 2008(無印)は非対応)</li> <li>Safari は 7 以降は全プラットフォームで対応</li> <li>その他 <ul> <li><a href="http://www.atmarkit.co.jp/ait/articles/1401/31/news141.html">JDK 8、TLS 1.2がデフォルトに - @IT</a></li> </ul></li> </ul><p> いやぁ, WinXP(および IE6)がなくなってホンマによかったよ。 (<span class="offrec">でもうちのサイトに来るブラウザの UA 見てると IE6 っぽいのがいまだにワンサカ来るんだけど。 IE6 & WinXP ってどのくらい残ってるのかねぇ。ちなみにうちのサイトはもう IE8 以前は見捨ててますので。 IE9 もダメかな,多分。 Safari は確認する手段を持ってないので知らない振りをする</span>) </p><p> ちなみに Firefox で Google のサイトを見ると </p> <pre class="brush:text" title="google.com 接続情報">TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256</pre>
<p>
と表示される。
つまり TLS 1.2 下で Perfect Forward Secrecy を満たす ECDHE 鍵交換方式を使い AES 128bit アルゴリズムで GCM モードにより暗号化している(HMAC には SHA256 を使用),ということになる。
</p><p>
あとは古い AOSP(Android Open Source Project)版ブラウザだよね。
AOSP 版ブラウザはもともと WebKit から fork したものだが, Google 自身は2012年以降サポートを打ち切っている(Chromium があるからね)。
ユーザ側としては Chrome 等を導入して AOSP 版ブラウザを使わないようにするしかない。
他にも AOSP 版ブラウザには「同一生成元ポリシー回避の脆弱性」が指摘されている。
</p><ul>
<li><a href="https://community.rapid7.com/community/metasploit/blog/2014/09/15/major-android-bug-is-a-privacy-disaster-cve-2014-6041">Metasploit: Major Android Bug is a Privacy Disa... | SecurityStreet</a></li>
<li><a href="http://www.itmedia.co.jp/enterprise/articles/1409/16/news044.html">AndroidのAOSPブラウザに脆弱性、情報盗聴の恐れ - ITmedia エンタープライズ</a></li>
</ul>
</section>
</section>
<section id="pfs">
<h3>perfect forward secrecy と forward secrecy</h3>
<p>
どうもドキュメントによって表記に揺れがあるらしい。
</p><p>
<a href="http://www.nist.gov/manuscript-publication-search.cfm?pub_id=915295">SP800-52 revision 1</a> では
</p>
<figure>
<blockquote>
<q lang="en">Cipher suites using ephemeral DH and ephemeral ECDH (i.e., those with DHE or ECDHE in the second mnemonic) provide perfect forward secrecy, ensuring long-term confidentiality of the session. While support of these cipher suites is not required by these guidelines, it is strongly recommended.</q>
</blockquote>
<figcaption>via <q lang="en"><a href="http://dx.doi.org/10.6028/NIST.SP.800-52r1">Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations<sup><i class="far fa-file-pdf"></i></sup></a></q></figcaption>
</figure>
<p>
とあり, <q lang="en">perfect forward secrecy</q> の表記になっている。
一方 RFC3268 では
</p>
<figure>
<blockquote>
<q lang="en">At the same time the DHE ciphersuites are the only ones to offer forward secrecy.</q>
</blockquote>
<figcaption>via <q lang="en"><a href="http://tools.ietf.org/html/rfc3268">RFC3268: Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)</a></q></figcaption>
</figure>
<p>
とあり,こちらは <q lang="en">forward secrecy</q> の表記になっている。
</p><p>
さらに RFC4949 では
</p>
<figure>
<blockquote>
<q lang="en">Ordinary forward secrecy vs. "perfect" forward secret: Experts disagree about the difference between these two. Some say there is no difference, and some say that the initial naming was unfortunate and suggest dropping the word "perfect". Some suggest using "forward secrecy" for the case where one long-term private key is compromised, and adding "perfect" for when both private keys (or, when the protocol is multi-party, all private keys) are compromised.</q>
</blockquote>
<figcaption>via <q lang="en"><a href="http://tools.ietf.org/html/rfc4949">RFC4949: Internet Security Glossary, Version 2</a></q></figcaption>
</figure>
<p>
と書かれていて,両者の違いに一致した見解はないそうだ。
ちなみに <a href="http://www.nist.gov/manuscript-publication-search.cfm?pub_id=915295">SP800-52 revision 1</a> では <q lang="en">perfect forward secrecy</q> について
</p>
<figure>
<blockquote>
<q lang="en">Perfect forward secrecy is the condition in which the compromise of a long-term private key used in deriving a session key subsequent to the derivation does not cause the compromise of the session key.</q>
</blockquote>
<figcaption>via <q lang="en"><a href="http://dx.doi.org/10.6028/NIST.SP.800-52r1">Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations<sup><i class="far fa-file-pdf"></i></sup></a></q></figcaption>
</figure>
<p>
と定義している。
大雑把に言えば「長期的に使われる秘密鍵が漏洩しても、漏洩前のセッションで交換された鍵の秘密が漏れない」という解釈でいいようだ。
</p>
</section>
<section id="key-exch">
<h3>SSL/TLS における DHE, DH, RSA の安全性評価</h3>
<p>
TLS で使われる鍵交換方式である DH(Diffie-Hellman), DHE(ephemeral DH), RSA(RSAES-PKCS1-v1_5)を比較すると
</p><p>
DHE > DH > RSA
</p><p>
となるらしい。
これは
</p><ul>
<li><strong>DHE</strong>: 安全な認証機能付き鍵交換であり,かつ Perfect Forward Secrecy を満たす</li>
<li><strong>DH</strong>: 安全な認証機能付き鍵交換である</li>
<li><strong>RSA</strong>: 安全な認証機能付き鍵交換ではない(ただし RSA-OAEP を使う場合は安全な認証機能付き鍵交換である)</li>
</ul><p>
ということらしい。
ちなみに CRYPTREC では RSAES-PKCS1-v1_5 は「運用監視暗号」としてリストされ,「利用実績があることから当面の利用を認める」という条件で利用可能である。
</p><p>
参考:
</p><ul>
<li><a href="http://www.nisc.go.jp/active/general/pdf/angou_ikoushishin.pdf">政府機関の情報システムにおいて使用されている暗号アルゴリズム SHA-1 及び RSA1024 に係る移行指針<sup><i class="far fa-file-pdf"></i></sup></a></li>
</ul><p class="offrec">
(CRYPTREC の「電子政府推奨暗号リスト」では,「鍵共有」用途としては DH および ECDH(Elliptic Curve Diffie–Hellman)しかリストアップされていない(推奨候補にも挙がってない)。
CRYPTREC において DHE や ECDHE(ephemeral ECDH)がどのような位置づけになるか,今後の動向が注目される)
</p>
</section>
<section id="rnd">
<h3>擬似乱数生成アルゴリズム Dual_EC_DRBG</h3>
<p>
Dual_EC_DRBG については<q><a href="http://www.cryptrec.go.jp/topics/cryptrec_20131106_dual_ec_drbg.html">擬似乱数生成アルゴリズム Dual_EC_DRBG について</a></q>を参照していただきたいが,最新動向として SP800-90 A Rev. 1 (2nd Draft) が登場している。
</p><ul>
<li><a href="http://csrc.nist.gov/publications/drafts/800-90/sp800_90a_r1_draft.pdf">DRAFT NIST Special Publication 800-90A, Rev. 1<sup><i class="far fa-file-pdf"></i></sup></a></li>
</ul><p>
このドラフトのパブリックコメントは2014年5月に締め切られている。
</p><p>
もともとこの脆弱性は2013年に Dual_EC_DRBG に NSA によるバックドアが仕込まれているという指摘からはじまったものだ。
NIST はこの脆弱性の修正に懸命になっているが,あまり芳しくないようである。
</p>
</section>
<section id="light-cipher">
<h3>軽量暗号</h3>
<p>
軽量暗号についてはまだまだこれからのようだが,いわゆる IoT(Internet of Things)を考える際には外せない要素技術であるといえる。
</p><p>
軽量暗号の特徴は以下のとおり。
</p><ul>
<li>ハードウェア規模が小さい,低消費電力で動作,消費電力が少ない,低コスト</li>
<li>コードサイズが小さい,RAM が少ない</li>
<li>低レイテンシ性,リアルタイム性</li>
</ul><p>
そして「軽量暗号の活用が期待されるアプリケーション」としては
</p><ul>
<li>RFID タグ,センサー,ワイヤレスセンサー</li>
<li>IC カード</li>
<li>医療機器(体内埋め込みや携帯型など),ヘルスケア製品</li>
<li>スマートメータ</li>
<li>モバイル製品</li>
<li>バッテリ</li>
<li>車, ITS システム</li>
</ul><p>
が挙がっている。
バッテリーかぁ。
</p><p>
車への応用は急務だろうね。
いまどきの車は ECU だらけだけどセキュリティに関してはこれからって感じだもんなぁ。
</p>
</section>
<section>
<h3>参考図書</h3>
<div class="hreview"><a class="item url" href="https://www.amazon.co.jp/exec/obidos/ASIN/B00H372H18/baldandersinf-22/"><img src="https://images-fe.ssl-images-amazon.com/images/I/51njmeGhpKL._SL160_.jpg" alt="photo" class="photo"/></a><dl><dt class="fn"><a class="item url" href="https://www.amazon.co.jp/exec/obidos/ASIN/B00H372H18/baldandersinf-22/">新版暗号技術入門 秘密の国のアリス</a></dt><dd>結城 浩 </dd><dd>SBクリエイティブ株式会社 2013-12-04</dd><dd>評価<abbr class="rating" title="4"><img src="https://images-fe.ssl-images-amazon.com/images/G/01/detail/stars-4-0.gif" alt=""/></abbr> </dd></dl><p class="similar"><a href="https://www.amazon.co.jp/exec/obidos/ASIN/B00H372H40/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/B00H372H40.09._SCTHUMBZZZ_.jpg" alt="プログラマの数学"/></a> <a href="https://www.amazon.co.jp/exec/obidos/ASIN/B00L0PDMJ0/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/B00L0PDMJ0.09._SCTHUMBZZZ_.jpg" alt="数学ガールの秘密ノート/整数で遊ぼう"/></a> <a href="https://www.amazon.co.jp/exec/obidos/ASIN/B00IP549AE/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/B00IP549AE.09._SCTHUMBZZZ_.jpg" alt="インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門"/></a> <a href="https://www.amazon.co.jp/exec/obidos/ASIN/B00L0PDMIQ/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/B00L0PDMIQ.09._SCTHUMBZZZ_.jpg" alt="数学ガールの秘密ノート/式とグラフ"/></a> <a href="https://www.amazon.co.jp/exec/obidos/ASIN/B00L0PDMK4/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/B00L0PDMK4.09._SCTHUMBZZZ_.jpg" alt="数学ガール/ガロア理論"/></a> </p>
<p class="description">まさに入門書。暗号がどのような要素技術で成り立っているのか体系的に理解できる良書。</p>
<p class="gtools">reviewed by <a href="#me" class="reviewer">Spiegel</a> on <abbr class="dtreviewed" title="2014-09-18">2014/09/18</abbr> (powered by <a href="http://www.goodpic.com/mt/aws/index.html">G-Tools</a>)</p>
</div>
</section>
FIPS PUB 186-3
tag:Baldanders.info,2009-09-28:/blog/000462/
2009-09-28T09:00:00+00:00
2009-09-28T09:00:00+00:00
いやぁ,全く気がつかなかったっス。
Spiegel
/profile/
<p>
いやぁ,
全く気がつかなかったっス。
<a href="http://csrc.nist.gov/groups/ST/toolkit/digital_signatures.html">6月にリリース</a>されてたんだねぇ。
</p><blockquote>
“NIST is proud to announce the publication of FIPS 186-3,
The Digital Signature Standard.
FIPS 186-3 is a revision of FIPS 186-2.
The FIPS specifies three techniques for the generation and verification of digital signatures: DSA, ECDSA and RSA.
This revision increases the length of the keys allowed for DSA,
provides additional requirements for the use of ECDSA and RSA,
and includes requirements for obtaining assurances necessary for valid digital signatures.”
</blockquote><p>
ちうわけで,
以下が FIPS 186-3 だ。
</p><ul>
<li><a href="http://csrc.nist.gov/publications/fips/fips186-3/fips_186-3.pdf">FIPS PUB 186-3, Digital Signature Standard (DSS)</a> (PDF)</li>
</ul><p>
今回のメインはやっぱり DSA (Digital Signature Algorithm)の要件が改良されたことだろう。
詳しくは拙文<a href="https://baldanders.info/blog/000204/">「暗号の危殆化と新しいアルゴリズム」</a>を参照のこと。
当時はドラフト案だったけど,
これで大手を振って使えるわけやね。
(あれから3年かかったんじゃねぇ)
</p><p>
あとは新しいハッシュ関数(SHA-3)か。
現在 SHA-3 コンペは第2ラウンドらしい。
しばらく前に MD6 が手を引いたみたいなニュースが流れていた。
</p><ul>
<li><a href="http://www.schneier.com/blog/archives/2009/07/md6.html">MD6 Withdrawn from SHA-3 Competition</a></li>
<li><a href="http://csrc.nist.gov/groups/ST/hash/sha-3/Round2/submissions_rnd2.html">Second Round Candidates</a></li>
<li><a href="http://www.schneier.com/blog/archives/2009/07/sha-3_second_ro.html">SHA-3 Second Round Candidates Announced</a></li>
</ul><p>
さて,
どうなるか楽しみである。
</p>
「安全な鍵長の下限」とは
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>