AES暗号化モードを選択する方法（CBC ECB CTR OCB CFB）
どの状況でそれらのどれが好ましいですか？
さまざまなモードの評価基準のリストと、各基準の適用可能性についての議論を参照してください。
たとえば、暗号化と復号化の「コードのサイズ」が基準の1つであると考えています。これは、802.11ネットワークアダプタなどのマイクロコード組み込みシステムにとって重要です。 CBCの実装に必要なコードがCTRに必要なコードよりはるかに小さい場合（これは本当だとはわかりません。これは単なる例です）、小さいコードのモードが優先される理由を理解できます。しかし、私がサーバー上で動作するアプリケーションを作成していて、私が使用しているAESライブラリがとにかくCBCとCTRの両方を実装している場合、この基準は無関係です。
私が「評価基準のリストと各基準の適用性」とはどういう意味かを見てください。
これは実際にはプログラミング関連ではありませんが、アルゴリズム関連です。
ECBは、同じキーを使用して複数のデータブロックを暗号化する場合には使用しないでください。
CBC、OFB、およびCFBは似ていますが、暗号化のみが必要で復号化は不要であるため、OFB/CFBの方が優れているため、コードスペースを節約できます。
CTRは、CBC/OFB/CFBの代わりに、優れた並列化（つまり速度）が必要な場合に使用されます。
ランダムアクセス可能なデータ（ハードディスクやRAMなど）をエンコードする場合は、XTSモードが最も一般的です。
OCBは、シングルパスで暗号化と認証を可能にするため、はるかに優れたモードです。しかし、アメリカにはそれに関する特許があります。
あなたが本当に知っておかなければならないことは、あなたが1ブロックだけを暗号化しているのでなければ、ECBは使われないということです。あなたがストリームではなくランダムにアクセスされたデータを暗号化しているならXTSを使うべきです。
独自の暗号化の実装を回避できない場合は、長くて難しいことを検討してください
問題のい真実は、この質問をしている場合、おそらく安全なシステムを設計および実装できないことです。
私のポイントを説明しましょう：Webアプリケーションを構築していて、セッションデータを保存する必要があるとします。各ユーザーにセッションIDを割り当て、セッションIDをセッションデータにマッピングするハッシュマップでサーバーにセッションデータを保存できます。しかし、その後、サーバー上でこの厄介な状態に対処する必要があり、ある時点で複数のサーバーが必要になると、事態は面倒になります。そのため、代わりに、セッションデータをクライアント側のCookieに保存するという考えがあります。もちろん、ユーザーがデータを読み取って操作できないように暗号化します。それでは、どのモードを使用する必要がありますか？ここに来ると、一番上の答えが表示されます（myforwikを1つだけ削除して申し訳ありません）。最初の1つ-ECB-はあなたのためではありません、あなたは複数のブロックを暗号化しますXTSと特許はPITAなので、OCBはありません。暗号ライブラリを使用すると、ブロックサイズの倍数しか暗号化できないため、パディングが必要であることがわかります。 PKCS7 を選択します。これは、いくつかの重大な暗号化規格で定義されているためです。 CBCが provably secure である場所を読んだ後、ランダムIVおよび安全なブロック暗号を使用すると、クライアント側に機密データを保存していても安心します。 。
サービスが実際にかなりの規模に成長した数年後、ITセキュリティスペシャリストが責任を持って開示します。彼女は、 padding Oracle attack を使用してすべてのcookieを復号化できると言っています。これは、パディングが何らかの理由で壊れている場合、コードでエラーページが生成されるためです。
これは架空のシナリオではありません：Microsoftは数年前までASP.NETにこの正確な欠陥がありました。
問題は、暗号に関して多くの落とし穴があり、素人には安全に見えるが、知識のある攻撃者にとっては簡単に破れるシステムを構築することは非常に簡単です。
データを暗号化する必要がある場合の対処方法
ライブ接続にはTLSを使用します（証明書と発行者チェーンのホスト名を必ず確認してください）。 TLSを使用できない場合は、システムがタスクに対して提供する必要がある最高レベルのAPIを探し、システムが提供する保証と、保証しないものをより重要に理解してください。上記の例では、Playのようなフレームワークは client side storage facilities を提供しますが、しばらくすると保存されたデータは無効になりませんただし、クライアント側の状態を変更した場合、攻撃者は気付かずに以前の状態を復元できます。
高レベルの抽象化が利用できない場合は、高レベルの暗号化ライブラリを使用します。顕著な例は NaCl であり、多くの言語バインディングを備えたポータブルな実装は Sodium です。このようなライブラリを使用すると、暗号化モードなどを気にする必要はありませんが、nonceを2回使用しないなど、より高いレベルの抽象化よりも使用の詳細に注意する必要があります。
何らかの理由で、たとえば特定の方法で既存のシステムとやり取りする必要があるために、高レベルの暗号ライブラリを使用できない場合、徹底的に自分自身を教育する方法はありません。 Ferguson、Kono、Schneierによる Cryptography Engineeringを読むことをお勧めします 。必要なバックグラウンドがなくても安全なシステムを構築できると信じ込まないでください。暗号化は非常に微妙であり、システムのセキュリティをテストすることはほとんど不可能です。
モードの比較
暗号化のみ：
- パディングが必要なモード：例のように、パディングは一般的に危険です。なぜなら、パディングはOracle攻撃のパディングの可能性を開くからです。最も簡単な防御策は、復号化の前にすべてのメッセージを認証することです。下記参照。
- ECBはデータの各ブロックを個別に暗号化し、同じ平文ブロックは同じ暗号文ブロックになります。 ECB Wikipediaページ でECB暗号化Tuxイメージを見て、なぜこれが深刻な問題なのかを確認してください。 ECBが受け入れられるユースケースは知りません。
- CBCはIVであるため、メッセージが暗号化されるたびにランダム性が必要です。メッセージの一部を変更するには、変更後にすべてを再暗号化する必要があります。ある暗号文ブロックの送信エラーは、平文を完全に破壊し、次のブロックの復号化を変更します。復号化は並列化できます/暗号化はできません。平文はある程度可鍛性があります- 問題 。
- ストリーム暗号モード：これらのモードは、プレーンテキストに依存する場合としない場合があるデータの擬似ランダムストリームを生成します。一般にストリーム暗号と同様に、生成された擬似ランダムストリームはプレーンテキストとXORされて、暗号テキストが生成されます。ランダムストリームのビットを好きなだけ使用できるので、パディングはまったく必要ありません。この単純さの欠点は、暗号化が完全に malleable であるということです。これは、平文p1、暗号文c1に関して、攻撃者が好きな方法で解読を変更できることを意味します。疑似ランダムストリームrと攻撃者は、暗号文c2 =c1⊕dの復号化がp2 =p1⊕dになるように、p2 =c2⊕r=（c1⊕d）⊕r = d⊕（ c1⊕r）。また、2つの暗号文c1 =p1⊕rおよびc2 =p2⊕rの場合と同じ疑似ランダムストリームを2回使用してはなりません。攻撃者は2つの平文のxorをc1⊕c2=p1⊕r⊕p2⊕r=として計算できますp1⊕p2。また、元のメッセージが攻撃者によって取得された可能性がある場合、メッセージを変更するには完全な再暗号化が必要であることを意味します。以下のSteam暗号モードはすべて、ブロック暗号の暗号化操作のみを必要とするため、暗号によっては、非常に制限された環境で（シリコンまたはマシンコード）スペースを節約できます。
- CTRは単純で、プレーンテキストに依存しない擬似ランダムストリームを作成します。異なるノンス/重複を防ぐために最大メッセージ長を乗算したIV、メッセージごとのランダム性なしでノンスメッセージ暗号化を使用可能、復号化と暗号化は並列化可能、送信エラーは間違ったビットにのみ影響を与える
- OFBは、プレーンテキストに依存しない疑似ランダムストリームも作成します。メッセージごとに異なるノンスまたはランダムIVで開始することにより、異なる疑似ランダムストリームが取得されます。 、暗号化も復号化も並列化できません。ノンスメッセージ暗号化を使用したCTRでは、メッセージごとのランダム性がなくても、CTR送信エラーは間違ったビットにのみ影響し、
- CFBの擬似ランダムストリームはプレーンテキストに依存し、CTRやOFBでノンスを使用する場合と同様に、すべてのメッセージに異なるナンスまたはランダムIVが必要ですメッセージの暗号化は、メッセージごとのランダム性なしで可能であり、復号化は並列化可能/暗号化は不可能であり、伝送エラーは次のブロックを完全に破壊しますが、現在のブロックの誤ったビットのみに影響します
- ディスク暗号化モード：これらのモードは、ファイルシステム抽象化の下でデータを暗号化するために特化されています。効率上の理由から、ディスク上の一部のデータを変更するには、最大で1つのディスクブロック（512バイトまたは4kib）の書き換えのみが必要です。使用シナリオは他とは大きく異なるため、これらはこの回答の範囲外です。 ブロックレベルのディスク暗号化 以外には使用しないでください。一部のメンバー：XEX、XTS、LRW。
認証された暗号化：
パディングOracle攻撃と暗号文への変更を防ぐために、暗号文で message認証コード （MAC）を計算し、改ざんされていない場合にのみ暗号化を解除できます。これはencrypt-then-macと呼ばれ、 は他の注文より優先されるべきです 。ごく少数のユースケースを除いて、信頼性は機密性と同じくらい重要です（後者は暗号化の目的です）。認証済み暗号化スキーム（関連データ（AEAD）を使用）は、暗号化と認証の2つの部分のプロセスを1つのブロック暗号モードに結合し、プロセスで認証タグも生成します。ほとんどの場合、これにより速度が向上します。
- CCMは、CTRモードとCBC-MACの単純な組み合わせです。ブロックごとに2つのブロック暗号暗号化を使用すると、非常に遅くなります。
- OCBは高速ですが、特許によって妨げられています。ただし、無料（自由の場合）または非軍事ソフトウェアの場合、特許所有者 は無料ライセンスを付与しました 。
- GCMは、CTRモードと、2 ^ 128要素のガロア体上のMACであるGHASHの非常に高速ですが、おそらく複雑な組み合わせです。 TLS 1.2などの重要なネットワーク標準で広く使用されていることは、 special instruction に反映されています。IntelはGHASHの計算を高速化するために導入しました。
勧告：
認証の重要性を考慮すると、ほとんどのユースケースで次の2つのブロック暗号モードをお勧めします（ディスク暗号化の目的を除く）。データが非対称署名で認証される場合はCBCを使用し、そうでない場合はGCMを使用します。
2011年にPhil Rogawayによって正式な分析が行われました、 here 。 1.6節では、私がここで転記し、私自身の強調を大胆に付け加えて要約しています（あなたが焦っている場合は、CTRモードを使用することをお勧めします。
これらのほとんどはIVがランダムである必要があることに注意してください。これは予測不可能であることを意味し、したがって暗号化セキュリティで生成されるべきです。しかしながら、そのプロパティを要求するのではなく、代わりにそれが再利用されないことを要求するだけである、 "nonce"のみを要求するものもあります。したがって、一回だけに頼る設計はそうでない設計よりもエラーが少ない傾向があります（そして私は、CBCが適切なIV選択で実装されていない多くのケースを見ました）。ですから、Rogawayが「IVがノンスであると機密性が達成されない」のようなことを言ったとき、私が大胆に付け加えたことがわかるでしょう。しかし、そうしないと、あなたは良いセキュリティ特性を失うことになります。 これらのモードのいずれにもIVを再使用しないでください。
また、メッセージの整合性と暗号化の違いを理解することも重要です。暗号化はデータを隠しますが、攻撃者が暗号化されたデータを変更する可能性があるため、メッセージの整合性をチェックしないと、結果がソフトウェアに受け入れられる可能性があります。開発者は「しかし、復号化後に変更されたデータはゴミとして戻ってくる」と言うでしょうが、優れたセキュリティエンジニアは、ゴミがソフトウェアに悪影響を及ぼす原因となる可能性を見つけ、その分析を実際の攻撃に変えます。暗号化が使用されていても、メッセージの整合性が暗号化よりも実際に必要とされている多くのケースを見ました。必要なものを理解してください。
GCMには暗号化とメッセージの整合性の両方がありますが、それは非常に壊れやすい設計です。IVを再利用すると、窮地に陥ります - 攻撃者はあなたの鍵を回復することができます。他のデザインはそれほど壊れにくいので、私は実際に私が実際に見た貧弱な暗号化コードの量に基づいてGCMを推薦することを恐れています。
メッセージの整合性と暗号化の両方が必要な場合は、2つのアルゴリズムを組み合わせることができます。通常はCBCとHMACの組み合わせを使用しますが、CBCと結びつける必要はありません。知っておくべき重要なことは 最初に暗号化し、次に暗号化されたコンテンツをMAC であり、その逆ではありません。また、IVはMAC計算の一部である必要があります。
私は知的財産権の問題を意識していません。
Rogaway教授からの良いものになりました：
ブロック暗号モード、暗号化、ただしメッセージの完全性
ECB：ブロック暗号化。モードは、各nビット部分を別々に暗号化することによって、nビットの倍数であるメッセージを暗号化します。 セキュリティ特性が弱い、この方法ではブロックの位置と時間の両方にわたってブロックの等価性が漏れる。かなりの遺産的価値、そして他の計画のためのビルディングブロックとして価値があります、しかしモードはそれ自身で一般的に望ましいセキュリティ目標を達成しないで、そしてかなり慎重に使用されなければなりません。 ECBは「汎用の」機密モードと見なされるべきではありません。
CBC：IVベースの暗号化方式。このモードは確率的暗号化方式として安全であり、ランダムIVと仮定して、ランダムビットとの区別がつかなくなります。 秘密保持は、標準で誤って提案されているように、IVが単なるnonceでも、スキームで使用されているのと同じ鍵で暗号化されたnonceでもない場合には達成されません。暗号文は非常に順応性があります。選択された暗号文攻撃（CCA）セキュリティはありません。多くのパディング方法で正しいパディングのOracleが存在すると、機密性は失われます。暗号化は本質的にシリアルであることから非効率的です。広く使用されている、モードのプライバシーのみのセキュリティプロパティは頻繁に悪用をもたらします。 CBC-MACアルゴリズムのビルディングブロックとして使用できます。 CTRモードに勝る重要な利点はありません。
CFB：IVベースの暗号化方式。このモードは確率的暗号化方式として安全であり、ランダムIVと仮定して、ランダムビットとの区別がつきません。 秘密保持は、IVが予測可能である場合、またはスキームで使用されているのと同じ鍵で暗号化された一回だけで作成された場合は達成されません。暗号文は順応性があります。 CCAセキュリティはありません。暗号化は本質的にシリアルであることから非効率的です。 Schemeはパラメータsに依存し、1≤s≤n、通常はs = 1またはs = 8です。sビットだけを処理するために1つのブロック暗号呼び出しを必要とするのは非効率的です。このモードは、興味深い「自己同期」特性を実現します。暗号文に任意の数のSビット文字を挿入または削除しても、正しい復号化が一時的に中断されることはありません。
OFB：IVベースの暗号化方式。このモードは確率的暗号化方式として安全であり、ランダムIVを想定して、ランダムビットとの区別がつきません。 IVがnonceの場合、機密性は達成されませんが、IVの決まった順序（例えば、カウンター）はうまくいきます。暗号文は非常に順応性があります。 CCAセキュリティなし暗号化と復号化は本質的にシリアルであることから非効率的です。任意のビット長の文字列をネイティブに暗号化します（パディングは不要です）。 CTRモードに勝る重要な利点はありません。
CTR：IVベースの暗号化スキーム。このモードでは、ナンスIVを仮定してランダムビットとの区別がつきません。安全なnonceベースのスキームとして、このモードは確率的暗号化スキームとして、ランダムIVとともに使用することもできます。暗号化または復号化にナンスが再利用された場合、プライバシーの完全な失敗。モードの並列化可能性は、他の機密モードよりもはるかに速く、ある設定ではそれをより速くします。認証暗号化方式の重要な構成要素。 全体的に見て、通常はプライバシーのみの暗号化を実現するための最善かつ最新の方法。
XTS：IVベースの暗号化方式で、モードは調整可能なブロック暗号（強いPRPとして安全）を各nビットチャンクに適用することによって機能します。 nで割り切れない長さのメッセージの場合、最後の2ブロックは特別に扱われます。このモードの唯一の許可された使用法は、ブロック構造の記憶装置上のデータを暗号化することです。基礎となるPRPの幅が狭く、端数ブロックの扱いが不十分であることが問題です。 （ワイドブロック）PRPセキュアブロック暗号よりも効率的ですが、あまり望ましくありません。
MAC（メッセージの完全性、暗号化ではない）
ALG1–6：MACの集まりで、すべてCBC-MACに基づいています。スキームが多すぎます。 VIL PRFとして証明されているもの、FIL PRFとして証明されているもの、証明可能なセキュリティがないものもあります。いくつかのスキームは有害な攻撃を認めています。いくつかのモードは日付付きです。キー分離はそれを持っているモードのために不適切に注意されています。まとめて採用すべきではありませんが、「最良の」スキームを選択的に選択することは可能です。 CMACを支持して、これらのモードのどれも採用しないのも良いでしょう。 ISO 9797-1 MACの中には、特に銀行業務で広く標準化され使用されているものがあります。規格の改訂版（ISO/IEC FDIS 9797-1：2010）はまもなくリリースされる予定です[93]。
CMAC：CBC-MACに基づくMAC。モードは（VIL）PRF（基本となるブロック暗号が良いPRPであると仮定して）として確かに安全です（誕生日の上限まで）。 CBCMACベースのスキームのための本質的に最小限のオーバーヘッド。本質的に本質的にシリアルな性質があるアプリケーション分野での問題、そして64ビットブロック暗号での使用は時折の再キーイングを必要とするでしょう。 ISO 9797-1のMACコレクションよりもクリーンです。
HMAC：ブロック暗号ではなく暗号ハッシュ関数に基づくMAC（ほとんどの暗号ハッシュ関数はそれ自体がブロック暗号に基づいていますが）。メカニズムは、好ましい前提からではありませんが、強力な証明可能なセキュリティ限界を享受します。文献中の密接に関連した複数の変種は、知られていることの理解を得ることを複雑にする。有害な攻撃はこれまでに示唆されていません。広く標準化され使用されています。
GMAC：GCMの特別な場合であるnonceベースのMAC。 GCMの長所と短所の多くを継承しています。しかし、nonce-requirementsはMACには不要で、ここではほとんどメリットがありません。タグが64ビット以下に切り捨てられ、復号化の程度が監視されず、縮小された場合の実用的な攻撃。 nonce-reuseで完全な失敗GCMが採用されている場合は、とにかく使用は暗黙的です。個別の標準化にはお勧めできません。
認証された暗号化（暗号化とメッセージの整合性の両方）
CCM：CTRモードの暗号化と生のCBC-MACを組み合わせた、nonceベースのAEADスキーム。本質的にシリアルで、状況によっては速度を制限します。基礎となるブロック暗号が優れたPRPであると想定して、適切な範囲で証明可能に安全です。明らかにその仕事をしているとんでもない建設。 GCMよりも実装が簡単です。 nonceベースのMACとして使用できます。広く標準化され使用されています。
GCM：CTRモード暗号化とGF（2128）ベースのユニバーサルハッシュ関数を組み合わせた、nonceベースのAEADスキーム。いくつかの実装環境に適した効率特性。最小限のタグの切り捨てを想定した、証明可能で安全な結果。実質的なタグの切り捨てが存在する場合の攻撃と貧弱な証明可能なセキュリティの限界。その後、GMACと呼ばれる、nonceベースのMACとして使用できます。 96ビット以外のnonceを許可するという疑問のある選択。ノンスを96ビットに、タグを最低96ビットに制限することをお勧めします。広く標準化され使用されています。
- ECB以外の何でも。
- CTRを使用している場合は、メッセージごとに異なるIVを使用することが不可欠です。そうしないと、攻撃者が2つの暗号文を取得し、結合された暗号化されていない平文を得ることができます。その理由は、CTRモードは基本的にブロック暗号をストリーム暗号に変換するためです。ストリーム暗号の最初の規則は、同じKey + IVを2回使用しないことです。
- モードを実装するのがどれほど難しいかには、それほど大きな違いはありません。一部のモードでは、暗号化方向に操作するためにブロック暗号のみが必要です。ただし、AESを含むほとんどのブロック暗号では、復号化を実装するためのコードをそれほど多く取りません。
- すべての暗号モードで、メッセージが最初の数バイトで同一である可能性があり、攻撃者にこれを知られたくない場合は、メッセージごとに異なるIVを使用することが重要です。
あなたはウィキペディアでこれについての情報を読むことから始めましたか - ブロック暗号モードの動作モード ？それから へのウィキペディアの参照リンクに従ってください：/ - NIST：操作のブロック暗号モードのための推奨 。
広く利用可能なものに基づいて選択することをお勧めします。私は同じ質問をしました、そしてここに私の限られた研究の結果があります。
ハードウェアの制限
STM32L (low energy ARM cores) from ST Micro support ECB, CBC,CTR GCM
CC2541 (Bluetooth Low Energy) from TI supports ECB, CBC, CFB, OFB, CTR, and CBC-MAC
オープンソースの制限
Original rijndael-api source - ECB, CBC, CFB1
OpenSSL - command line CBC, CFB, CFB1, CFB8, ECB, OFB
OpenSSL - C/C++ API CBC, CFB, CFB1, CFB8, ECB, OFB and CTR
EFAES lib [1] - ECB, CBC, PCBC, OFB, CFB, CRT ([sic] CTR mispelled)
OpenAES [2] - ECB, CBC
[1] http://www.codeproject.com/Articles/57478/A-Fast-and-Easy-to-Use-AES-Library