ノート:ブロック暗号

ページのコンテンツが他言語でサポートされていません。

定義について[編集]

2008年2月2日 (土) 05:04の版にて、「ブロック暗号(- あんごう、Block cipher)とは、共通鍵暗号の一種で、ブロックと呼ばれる固定長のデータを単位として鍵によって与えられる全単射写像である。」に変更されていましたが、元に戻しました。“鍵によって与えられる全単射写像”では分っている人にしか理解できないと思います。 ブロック暗号は写像としてみれば全単射なのですが、それはブロック暗号の性質であり、記事冒頭の定義に採用するのは不適切なように思えました。暗号利用モードを議論する際には、ブロック暗号は擬似ランダム置換族と仮定して安全性証明を行うので、「ブロック暗号はnビットの平文からnビットの暗号文への置換である」と説明することもあると思いますが、これはブロック暗号の説明であって定義ではないと思います。 例えば、黒澤馨・尾形わかは著『現代暗号の基礎知識』の「2.3.1 ブロック暗号とは」によれば「ブロック長と呼ばれる長さnビットの平文mをまとめて暗号化する共通鍵暗号系をブロック暗号という」といった説明になっています。『情報セキュリティハンドブック』の「3.1.1 ブロック暗号とは」によれば「ブロック暗号は、図3.1に示すように、一定の長さのブロック単位で暗号化・復号を行う共通鍵アルゴリズムである」となっています。Sina 2008年2月2日 (土) 21:37 (UTC)[返信]

B.Schneier,Applied Cryptographyで引用されていた、R.A.Rueppel,Stream Ciphersの記述, Block ciphers operate with a fixed transformation on large blocks of plaintext data; stream ciphers operate with a time-varying transformation on individual plaintext digits.をもとに改稿したのですが、確かに定義としては理解しづらい所ではあると思います。一方で、近年処理単位の大きなストリーム暗号もあるので、そこらへん誤解無く表記できないか、というのを考えていたりします。でも、いいアイディアはないので、定義の所はとりあえず、現状でおいておきます。 一方で、概要の方にはその辺の性質に付いて記述する必要があると考えています。もうちょっと、じっくりどう改稿するか考えてから記述したいなと思ってます.池田尚隆 2008年2月4日 (月) 13:33 (UTC)[返信]

加筆改稿を期待してます。今の記述では鍵長ksについて2^ksの全数探索が安全性の上限になっていることは説明されていますが、ブロック長が安全性にいかに影響しているのかが全く触れられていませんから、その他にも改稿の余地は沢山あるかと思います。「近年処理単位の大きなストリーム暗号もある」とのことですが、OFBモードのことを考えると・・・、近年?処理単位?そもそもストリーム暗号とは?といった点からも誤解が無いように書き尽くすことができればよいかと思います。あとOMACなどのここ数年の話も暗号利用モードに加筆されるとよいのですが、暗号利用モードは全面的に改稿したほうがよいかもしれません。時間があったら自分でしたいのですが。Sina 2008年2月11日 (月) 06:52 (UTC)[返信]

定義について2[編集]

下記の文章の「初期値に依存する内部データをもち」という部分について(なんとなく気持ちはわかりますが)適当な文献をご存知でしたら提示していただけないでしょうか。特に文献が無いようでしたらリバートします。文献があるようでしたらそれを確認したいと思います。

これに対して、初期値に依存する内部データをもち、ビット単位やバイト単位で暗号化を行う暗号はストリーム暗号と呼ばれる。

というのは、このように記述すると「初期値に依存する内部データ」を持たない暗号はストリーム暗号とは呼ばないことになりますが、例えば One Time Pad のようにストリーム暗号に分類されるが「初期値に依存する内部データ」があるとは言い難いようものがあるように思うからです。One Time Pad にはメッセージと同じ長さの鍵があるだけではないでしょうか。もしかしたら、ストリーム暗号の定義とストリーム暗号の構成法の1つに内部状態が時間と共に変化する関数を利用したものがあることを混同してはいないでしょうか。記事「ストリーム暗号」の定義部分についても同じですね。Sina 2008年11月28日 (金) 15:52 (UTC)[返信]

しばらく待ちましたが(アクセスされていないのかもしれませんが)反応がないのでリバートしました。もしも上記の部分を再度加筆されたいならば、ノートにてコメントされることを希望します。Sina 2008年12月5日 (金) 13:46 (UTC)[返信]

私が書いた部分じゃないですが、気持ちはわからなくもないです。One Time Padの場合は初期値は、乱数表をどこから使うかという開始位置に相当するような気がします。確かに、暗号化の実行の際にはメッセージと同じ長さの鍵があるように見えるんですが、実際には十分巨大な乱数表があって、それをどこから使用するかという使い方になると思います。与えられた乱数表から現在位置に基づいて乱数を返すような関数とみなせるんじゃないでしょうか。 --池田尚隆 2008年12月5日 (金) 23:30 (UTC)[返信]

どうもコメントありがとうございます。Sinaも気持ちは分かるので直ぐには除去しないでしばらく様子をみてました(1週間ですけど短かったかもしれません)
One Time Pad の場合は乱数表のどこを使うかは秘密にする必要はなくて、例えば日付や時刻をつかって指定することも可能ですよね?このような使い方をした One Time Pad もストリーム暗号に分類してよいと思いますが、このような使い方だと「現在位置」つまり使用するごとに値が更新される "内部データ" に相当するものがあるとは言い難いのではないでしょうか。もちろん、池田尚隆さんのご説明のように "内部データ" を持たせて乱数表をどこまで使ったかを保持させる使い方もあると思います。つまり、使い方によってあったりなかったりするのだと思います。なのでSinaは「初期値に依存する内部データ」はストリーム暗号の構成法に関する説明であって、ストリーム暗号自体の定義とは別にしておくのが説明上便宜と考えてます。
それよりもこのノートで以前に池田尚隆さんが引用されいていた "with a time-varying transformation" にあるようにストリーム暗号には時間の概念が必要という点の方が先に説明されるべきと感じます。このことはストリーム暗号の攻撃類型にも影響しますから、ストリーム暗号の概要部分や本文に反映させるとよいと思います。ブロック暗号の定義で、ストリーム暗号の説明として「初期値に依存する内部データ」と加筆するのはあまり適切ではないように思います。
(余談になるので控えるべきと思いますが) HANDBOOK of AC をみると、1.5.4 Stream cipher(p.20) では、ブロック長が1のものがストリーム暗号という説明(定義?)をしながら、6.1 Note(p.192) では、state cipher という言葉を紹介して、"This distinction between block and stream ciphers is not definitive..." としています。7.25 Remark(p.233) になると、CBCモードはブロック長がnのストリーム暗号と考えてもよいのかも(意訳)と述べていて、あまり明確になっていないみたいです。公開鍵/共通鍵の分類は原理的で明快だと感じますが、ストリーム/ブロックの分類は、まだこれから定義が変遷していくかも知れません。なので文献の追跡が必要と思います。CBCモードはストリーム暗号か?の他、RSA-OAEPはブロック暗号なのか?など等を考えると、ストリーム/ブロックという分類ではなくて、ランダム置換/乱数ジェネレータ/・・・といった暗号プリミティブレベルの分類と、暗号モードレベルの分類を区別した分類がすっきりするかもしれないと思い、そのような整理をした文献がないかも探しています。
長文失礼しました。加筆改稿を期待してます。Sina 2008年12月6日 (土) 05:32 (UTC)[返信]

計算量的でない安全性 項について[編集]

2009年4月8日 (水) 11:33版 で、追加された部分について独自研究っぽいのでいったんコメントアウトします。 この問題は等価鍵の問題であり、どちらの鍵か特定できないことは問題ではなく、どちらかの鍵が導出されればOKです。 鍵復元攻撃は等価鍵を求めればいいので。

ただ、この項目を読んでで、ブロック暗号の項目には、ブロック長と鍵の問題が出ていないことに気づきました。 64ビットブロック128ビット鍵の暗号の場合、1個の平文-暗号文ペアでは鍵を特定できません(情報理論的問題から) 一方で、複数のペアを用いれば鍵は特定できます。ただし、二つのペアでは特定できない可能性もあります。 これはアルゴリズムによって変わるし、証明するのも難しそうです。

重要なのは、1個の平文-暗号文ペアが漏らす鍵に関する情報はたかだかブロック長であること あたりの説明は必要な気がします。 --池田尚隆 2009年4月11日 (土) 04:11 (UTC)[返信]