ストリーム暗号とブロック暗号の違い

ブロック暗号 は、 $ k $ ビットキーと $ n $ ビット（プレーンテキスト）の決定論的で計算可能な関数です。 $ n $ ビット（暗号文）ブロックへのブロック。 （より一般的には、ブロックはビットサイズである必要はありません。 $ n $ -文字ブロックもここに収まります）。つまり、暗号化するとき同じキーを持つ同じ平文ブロックでも、同じ結果が得られます。 （通常、関数が反転可能であることも必要です。つまり、キーと暗号文ブロックが与えられると、平文を計算できます。）

（任意のサイズの）メッセージを実際に暗号化または復号化するには、必要ありません。」ブロック暗号を直接使用しますが、 操作モード 。このような最も単純なモードは電子コードブックモード（ECB）で、メッセージをブロックに分割し、各ブロックに暗号を適用します。結果のブロックを出力します（ただし、これは通常、セキュアモードではありません）。

Caesarで使用されているような初期の暗号化スキームの中には、「ECBで1文字のブロックを持つブロック暗号」として分類できるものがあります。 -mode “。または、通常、コードブックを持つすべてのもの。

通常、初期化ベクトルとある種のフィードバックにより、すべてのブロックがすべてのメッセージの暗号化方法は異なります。

ストリーム暗号 は、 $ k $ ビットキーと任意の長さの平文を（同じ任意の長さの）暗号文に直接マッピングする関数です。平文の接頭辞が暗号文の接頭辞にマップされる方法。つまり、平文の末尾部分がわかる前に、暗号文の開始部分を計算できます。 （多くの場合、メッセージサイズは「ブロックサイズ」の倍数に制限されることもありますが、通常はバイト全体などの小さなブロックになります。）

平文の一部が繰り返される場合、対応する暗号文は通常は同じではありません。メッセージのさまざまな部分がさまざまな方法で暗号化されます。

このようなストリーム暗号は、実際のキー（および場合によっては初期化ベクトル）からキーストリームを生成することで機能することがよくあります。 ）次に、メッセージと単純にXORします。これらは 同期ストリーム暗号 。他のストリーム暗号は、前の部分に応じてメッセージの将来の部分の暗号化を変える可能性があります。

一部のブロック暗号操作モードでは、 CTR および OFB モード。

同期ストリーム暗号（ストリーミングモードのブロック暗号を含む）のキー（および該当する場合はIV）を異なるメッセージに再利用しないでください。これにより、侵害が発生する可能性があります。 （同じメッセージの場合でも、メッセージを繰り返したことが表示されます。）

実際の使用では、MACも必要になることに注意してください。あなたのメッセージのための完全性保護。 （たとえば、選択暗号文攻撃の場合、一部のスキームは壊れており、そのようなMACはこれを防ぎます（MACをチェックした後にメッセージを復号化ツールに渡すだけの場合）。）

コメント

• ストリームとブロックのどちらを選択しますか？セキュリティに違いはありますか？または暗号化の速度？
• @anoopeliasブロック暗号は、一般にストリーム暗号と比較して低速です。また、よくわかりませんが、ストリーム暗号は情報セキュリティの提供に優れているのに対し、ブロック暗号は計算セキュリティの提供に優れていると思います
• 最後の段落に関して、例のリンクを提供してください。 MACを追加すると、選択暗号文攻撃から保護されますか？

数学的には、ブロック暗号は単なる$ n $ビットブロックのセット$ \ {0,1 \} ^ n $上のキー付き疑似ランダム順列ファミリ。 （実際には、通常、逆順列を計算する効率的な方法も必要です。）少なくとも小さな暗号化が必要な場合を除いて、ブロック暗号自体は実際の暗号化にはあまり役立ちません。 それぞれが単一のブロックに収まるメッセージ。

ただし、ブロック暗号は、他の暗号化ツールを構築するための非常に用途の広いビルディングブロックであることがわかります。優れたブロック暗号を入手したら、ストリーム暗号からハッシュ関数、メッセージ認証コード、キー派生関数、疑似ランダム番号ジェネレーター、エントロピープールなど、1つのブロック暗号だけで簡単に構築できます。

これらのアプリケーションのすべてが必ずしもブロック暗号が必要;たとえば、それらの多くは、順列である必要のない疑似乱数関数に基づいている可能性があります（ただし、便利なことに、補題は、それでも疑似ランダム順列が機能することを示しています。また、構築の多くは間接的です。たとえば、メッセージ認証コードから鍵導出関数を構築できます。ハッシュ関数から構築します。これは—できますが、ブロックから—構築することはできません 。暗号。ただし、それでも、ブロック暗号を使用している場合は、残りのすべてを 構築できます。

さらに、これらの構造には通常、セキュリティを低下させる（条件付きの）セキュリティ証明が付属しています。構築された関数の基礎となるブロック暗号の関数への変換。したがって、これらの各関数を個別に暗号化分析するという面倒で信頼性の低いタスクを実行する必要はありません—代わりに、すべての努力をブロック暗号に集中することができます。ブロック暗号のセキュリティに対する信頼は、それに基づくすべての機能に対する信頼に直接変換されることを知っています。

明らかに、これは、たとえば、次の作業をしている場合に非常に便利です。多数の個別の暗号プリミティブに効率的で安全なコードを含めることは困難で費用がかかる可能性がある小さな組み込みプラットフォーム。ただし、このような制約のあるプラットフォームを使用していない場合でも、サイドチャネル攻撃などに注意を払う必要があるため、低レベルの暗号コードの記述と分析は面倒な場合があります。 。限られた数の低レベルのビルディングブロックに制限し、それらから必要なものをすべて構築する方が簡単です。

また、大量のメモリを備えた高速プラットフォームでも、デスクトップCPUのように、ハードウェアに直接低レベルの暗号化操作を実装することは、ソフトウェア—で実行するよりもはるかに高速ですが、それらのいくつかに対してそれを実行することは実用的ではありません。 。その汎用性により、ブロック暗号はハードウェア実装の優れた候補です（最新のx86CPUの AES命令セットのように）。

では、ストリーム暗号についてはどうでしょうか？

数学的には、ストリーム暗号 —用語の最も一般的な意味で—もキー付きの可逆疑似乱数関数ファミリーですが、長さが制限されたブロックではなく、任意の長さのビット文字列のセット$ \ {0,1 \} ^ * $にあります。

（ここには微妙な点がいくつかあります。たとえば、ほとんどのストリーム暗号構造では、入力に一意の nonce 値を含める必要があります。同じナンスが2つの異なる入力に使用された場合、真にランダムな関数—と区別がつかないという意味でセキュリティ—を保証します。ランダム関数を選択するための$ \ {0,1 \} ^ * $からそれ自体への可逆関数の均一な分布はありません。ストリーム暗号が「ランダムと区別できない」ように見えることの意味を注意深く定義する必要があり、この定義は 実際のセキュリティに影響を及ぼします—たとえば、ほとんどのストリーム暗号はメッセージの長さをリークします。実際には、通常、ストリーム暗号も必要です。実際、任意の長さの入力ビットストリームを暗号化—し、oを使用して—復号化できるという意味で、「ストリーミング」であるほぼ一定のストレージとメッセージ長の時間線形。）

もちろん、ストリーム暗号はブロック暗号よりもはるかにすぐに役立ちます。ストリーム暗号を直接使用して、任意の長さのメッセージを暗号化できます。ただし、他の暗号化ツールの構成要素としては「あまり有用ではない」ことがわかりました。ブロック暗号を使用している場合は、簡単にできます。それをストリーム暗号に変換するのに対し、任意のストリーム暗号をブロック暗号に変換することは不可能ではないにしても困難です。

では、なぜ人々は専用のストリーム暗号を設計する必要があるのでしょうか。ブロック暗号でも同じように機能するのであれば、ほとんどの場合、理由は速度です。多くのデータを暗号化するために高速な暗号が必要な場合があります。 em>本当に高速な専用ストリーム暗号設計があります。これらの設計の一部は、ソフトウェアまたはハードウェア、あるいはその両方で実装するために非常にコンパクトに設計されているため、本当にストリーム暗号のみが必要な場合は、一般的なブロック暗号ベースの暗号ではなく、これらの暗号の1つを使用することで、コード/回路サイズを節約できます。

ただし、速度とコンパクトさで得られるものは、汎用性を失います。たとえば、「ストリーム暗号からハッシュ関数を作成する簡単な方法はないようです。そのため、これらのいずれかが必要な場合（そして頻繁にハッシュ関数は、それ自体で役立つだけでなく、他の暗号ツールの一般的な構成要素でもあるため、個別に実装する必要があります。そして、ほとんどのハッシュ関数はブロック暗号に基づいているので、もしあれば、同じブロック暗号を暗号化にも再利用することもできます（専用のストリーム暗号の生の速度が本当に必要な場合を除く）。

コメント

• 2つの異なる用語が必要かどうか疑問に思いました。あなたが説明したことによると、ストリーム暗号は単にブロック暗号の特殊なケースです。つまり、セット{0,1} ^ nのnが1であるという限定的なケースのケースです。したがって、現在の暗号を維持しないことを主張します。用語の区別。
• @ Mok-KongShen実際には、ストリーム暗号は、ブロックサイズが1の単なるブロック暗号ではありません（両方と見なすことができる従来のモノアルファベット暗号を除く）。ストリーム暗号は通常、暗号の現在の内部状態に応じて、ストリームのビット/バイト/ …を異なる方法で変換しますが、同じ入力のブロック暗号は同じ出力を持ちます（したがって、通常は"動作モード"でストリーム暗号を作成します。
• @PauloEbermann。 "ダイナミクスと変動性"に関するCodesinChaosの質問に答えてくれたIMHO。
• @ Mok-KongShen No彼は' tしませんでした。適切なモードでのブロック暗号に対する専用ストリーム暗号の唯一の利点は、パフォーマンスです。 '適切なチェーンなしでブロック暗号を使用する人はいないため、チェーンモードを無視することはできません。
• @CodesInChaos。アプリケーションが異なれば、パフォーマンス要件も異なります。暗号化するには電子メールの場合、'たとえばビデオファイルの暗号化に必要なパフォーマンスは必要ありません。

ブロック暗号自体は、nビットをnにマップします。キーを使用したビット。つまり、「キー付きの疑似ランダム順列です。長いテキストや短いテキストを受け入れることはできません。

メッセージを実際に暗号化するには、常にチェーンモードが必要です。ECBはそのようなチェーンモードの1つです。 （そして本当に悪いもの）、そしてそれは純粋なブロック暗号ではありません。 ECBでさえ「アドオン処理操作」で構成されています。これらのチェーンモードは、まったく異なるプロパティを持つことができます。

最も一般的なチェーンモードの1つであるカウンターモード（CTR）は、ブロック暗号から同期ストリーム暗号を構築します。別のモードであるCFBは、CBCのプロパティと同期ストリーム暗号の中間のプロパティを持つ自己同期ストリーム暗号を構築します。

したがって、ストリームとブロック暗号の間に暗号がないという仮定は実際には真実ではありません。完全に新しいシステムを作成するのではなく、よく理解されているブロック暗号プリミティブから構築することをお勧めします。

期間が短すぎるとはいえ、Vigenèreをストリーム暗号と呼びます。 2シンボルエンコーディングの代わりに26シンボルエンコーディングを使用しますが、それはストリーム暗号ではないという意味ではありません。 Solitaire / Pontifex を見て、26個のシンボルを持つストリーム暗号の最新の構造を確認してください。

コメント

• エラーが発生しない場合は'、"チェーン"ブロック暗号化は通常、"ブロックチェーン"のコンテキストで使用されます。つまり、連続するブロックを相互に依存させて、分析はより困難です。したがって、IMHO ECBは、定義上、そのような連鎖効果はありません。
• 間違いを犯します。 良いチェーンモードにはこれらのプロパティがありますが、悪いモードはまだ存在します！

暗号化には2つの基本的なタイプがあります

1. 対称。暗号化と復号化に同じキーを使用します。
2. 非対称。暗号化と復号化に2つの異なるキー（公開鍵と秘密鍵）を使用します。

ブロック暗号とストリーム暗号は対称暗号化の一部を形成します。 Stream Cipherは、ユーザーが指定したキーから拡張キーストリームを生成し、プレーンテキスト（暗号化用）/暗号文（復号化用）でXoRします。

Block Cipherはデータのブロックを入力として受け取りますが、複数のラウンドを実行します。キーミキシングと一緒に暗号文を作成します。ブロック暗号にはさまざまな動作モードがあり、そのうちカウンター（CTR）モードはストリーム暗号と同様に機能します。ブロック暗号には連番が入力され、その出力は平文とXoredされて暗号文になります。この動作モードでは、ブロック暗号の暗号化コードのみが必要です。復号化コードは必要ありません。復号化では、同じ連番を入力して暗号をブロックし、その出力を暗号文でXoredしてプレーンテキストを取得します。カウンターと一緒にナンスが使用されることがあるため、入力ブロック暗号は2つに分割されます。つまり、固定ナンスとインクリメンタルカウンターです。

その他の操作モード-

1. ECB（機密性を提供）
2. CBCおよびCTR（機密性を提供し、選択平文攻撃に対してセメント的に安全）
3. EAX、CCM、およびGCM（認証された暗号化を提供）

詳細はこちら