それらのどれがどのような状況で好まれますか？
さまざまなモードの評価基準のリストと、各基準の適用可能性についての議論が欲しいです。
たとえば、基準の1つは、暗号化と復号化の「コードのサイズ」であると思います。これは、802.11ネットワークアダプタなどのマイクロコード組み込みシステムにとって重要です。CBCを実装するために必要なコードがCTRに必要なコードよりもはるかに小さい場合（これが正しいかどうかはわかりませんが、これは単なる例です）、小さいコードのモードが優先される理由を理解できます。ただし、サーバー上で実行されるアプリを作成していて、使用しているAESライブラリがCBCとCTRの両方を実装している場合、この基準は関係ありません。
「評価基準の一覧と各基準の適用性」の意味をご覧ください。
これは実際にはプログラミング関連ではありませんが、アルゴリズム関連です。
問題の醜い真実は、あなたがこの質問をしているなら、あなたはおそらく安全なシステムを設計して実装することができないだろうということです。
私のポイントを説明しましょう。Webアプリケーションを構築していて、セッションデータを保存する必要があると想像してください。各ユーザーにセッションIDを割り当て、セッションIDをセッションデータにマッピングするハッシュマップでサーバー上のセッションデータを保存できます。ただし、サーバー上でこの厄介な状態に対処する必要があり、ある時点で複数のサーバーが必要になると、問題が発生します。したがって、代わりに、クライアント側のCookieにセッションデータを保存するというアイデアがあります。もちろん、ユーザーがデータを読み取ったり操作したりできないように暗号化します。では、どのモードを使用する必要がありますか？ここに来て、あなたはトップの答えを読みます（myforwikからあなたを選び出してすみません）。最初に取り上げたもの（ECB）はあなたには向いていません。複数のブロックを暗号化したい場合、次のブロック（CBC）は良さそうです。また、CTRの並列処理は必要ありません。また、ランダムアクセスも必要ありません。したがって、XTSや特許はPITAではないため、OCBはありません。暗号ライブラリを使用すると、ブロックサイズの倍数しか暗号化できないため、パディングが必要であることがわかります。選んでPKCS7は、いくつかの深刻な暗号化標準で定義されているためです。ランダムIVと安全なブロック暗号を使用するとCBCが確実に安全であることをどこかで読んだ後は、機密データをクライアント側に保存している場合でも安心できます。
サービスが実際にかなりの規模に成長してから数年後、ITセキュリティスペシャリストが責任ある開示についてあなたに連絡します。彼女は、パディングが何らかの理由で壊れている場合、コードがエラーページを生成するため、パディングオラクル攻撃を使用してすべてのCookieを復号化できると言っています。
これは架空のシナリオではありません 。Microsoftは、数年前までASP.NETにこの正確な欠陥がありました。
問題は、暗号化に関して多くの落とし穴があり、素人にとっては安全に見えるシステムを構築するのは非常に簡単ですが、知識のある攻撃者にとっては簡単に破ることができるということです。
ライブ接続にはTLSを使用します（証明書のホスト名と発行者チェーンを必ず確認してください）。TLSを使用できない場合は、システムがタスクに対して提供する必要のある最高レベルのAPIを探し、TLSが提供する保証、さらに重要なことは保証されないものを理解していることを確認してください。上記の例では、Playのようなフレームワークはクライアント側のストレージ機能を提供しますが、しばらくすると保存されたデータが無効になることはありません。クライアント側の状態を変更した場合、攻撃者は気付かないうちに以前の状態を復元できます。
利用可能な高レベルの抽象化がない場合は、高レベルの暗号ライブラリを使用してください。顕著な例はNaClであり、多くの言語バインディングを備えたポータブル実装はSodiumです。このようなライブラリを使用すると、暗号化モードなどを気にする必要はありませんが、ナンスを2回使用しないなど、高レベルの抽象化よりも使用法の詳細にさらに注意する必要があります。カスタムプロトコルの構築（TLSのようなものが必要だが、TCPやUDPを介さないものが必要な場合）には、Noiseのようなフレームワークや関連する実装があり、手間のかかる作業のほとんどを実行しますが、その柔軟性はエラーの余地がたくさんあることも意味します、すべてのコンポーネントが何をするのかを深く理解していない場合。
特定の方法で既存のシステムと対話する必要があるなどの理由で高レベルの暗号ライブラリを使用できない場合、自分自身を徹底的に教育する方法はありません。ファーガソン、河野、シュナイアーによる暗号工学を読むことをお勧めします。必要なバックグラウンドがなくても安全なシステムを構築できると信じ込まないでください。暗号化は非常に微妙であり、システムのセキュリティをテストすることはほぼ不可能です。
オラクル攻撃のパディングと暗号文への変更を防ぐために、暗号文でメッセージ認証コード（MAC）を計算し、改ざんされていない場合にのみ復号化することができます。これはencrypt-then-macと呼ばれ、他の順序よりも優先されます。ごくわずかなユースケースを除いて、信頼性は機密性と同じくらい重要です（後者は暗号化の目的です）。認証付き暗号化スキーム（関連データ（AEAD）を使用）は、暗号化と認証の2つの部分のプロセスを1つのブロック暗号モードに結合し、プロセスで認証タグも生成します。ほとんどの場合、これにより速度が向上します。
認証の重要性を考慮すると、ほとんどのユースケース（ディスク暗号化の目的を除く）では、次の2つのブロック暗号モードをお勧めします。データが非対称署名によって認証される場合はCBCを使用し、そうでない場合はGCMを使用します。
同じキーで複数のデータブロックを暗号化する場合は、ECBを使用しないでください。
CBC、OFB、CFBは似ていますが、暗号化のみが必要であり、復号化は不要であるため、OFB / CFBの方が優れており、コードスペースを節約できます。
CTRは、CBC / OFB / CFBの代わりに、適切な並列化（つまり、速度）が必要な場合に使用されます。
XTSモードは、ランダムにアクセス可能なデータ（ハードディスクやRAMなど）をエンコードする場合に最も一般的です。
OCBは、シングルパスで暗号化と認証を行うことができるため、これまでで最高のモードです。ただし、米国では特許があります。
本当に知っておく必要があるのは、1ブロックだけを暗号化しない限り、ECBは使用されないということだけです。ストリームではなくランダムにアクセスされるデータを暗号化する場合は、XTSを使用する必要があります。
正式な分析は、2011年にPhilRogawayによってここで行われました。セクション1.6は、私がここで書き写した要約を示し、太字で私自身の強調を追加しています（焦りがちな場合は、CTRモードを使用することをお勧めしますが、以下のメッセージの整合性と暗号化に関する私の段落を読むことをお勧めします）。
これらのほとんどは、IVがランダムである必要があることに注意してください。これは、予測できないことを意味するため、暗号化セキュリティを使用して生成する必要があります。ただし、「nonce」のみを必要とするものもあります。これは、そのプロパティを要求せず、代わりに、再利用されないことのみを要求します。したがって、ナンスに依存する設計は、ナンスに依存しない設計よりもエラーが発生しにくくなります（そして、私は、CBCが適切なIV選択で実装されていない多くのケースを見てきました）。したがって、Rogawayが「IVがナンスの場合は機密性が達成されない」などと言ったときに太字を追加したことがわかります。つまり、暗号的に安全な（予測不可能な）IVを選択した場合、問題はありません。しかし、そうしないと、優れたセキュリティプロパティが失われます。 これらのモードのいずれにもIVを再利用しないでください。
また、メッセージの整合性と暗号化の違いを理解することも重要です。暗号化はデータを隠しますが、攻撃者が暗号化されたデータを変更できる可能性があり、メッセージの整合性をチェックしないと、ソフトウェアが結果を受け入れる可能性があります。開発者は「ただし、変更されたデータは復号化後にガベージとして返されます」と言いますが、優れたセキュリティエンジニアは、ガベージがソフトウェアに悪影響を与える可能性を見つけ、その分析を実際の攻撃に変えます。暗号化が使用された多くのケースを見てきましたが、メッセージの整合性は暗号化よりも本当に必要でした。必要なものを理解します。
GCMには暗号化とメッセージの整合性の両方がありますが、非常に壊れやすい設計です。IVを再利用すると、失敗します。攻撃者はキーを回復できます。他の設計は脆弱性が低いため、実際に見た暗号化コードの量に基づいて、個人的にGCMを推奨することを恐れています。
メッセージの整合性と暗号化の両方が必要な場合は、2つのアルゴリズムを組み合わせることができます。通常はCBCとHMACがありますが、CBCに縛られる理由はありません。知っておくべき重要なことは、最初に暗号化してから、暗号化されたコンテンツをMACすることであり、その逆ではありません。また、IVはMAC計算の一部である必要があります。
私はIPの問題を認識していません。
さて、ロガウェイ教授からの良いものに：
ECB：ブロック暗号。このモードは、各nビット部分を個別に暗号化することにより、nビットの倍数であるメッセージを暗号化します。セキュリティプロパティは弱く、この方法ではブロックの位置と時間の両方でブロックの同等性がリークされます。かなりのレガシー価値があり、他のスキームの構成要素としても価値がありますが、モード自体は一般的に望ましいセキュリティ目標を達成していないため、かなりの注意を払って使用する必要があります。ECBは、「汎用」機密モードと見なされるべきではありません。
CBC：IVベースの暗号化スキームであるこのモードは、確率的暗号化スキームとして安全であり、ランダムIVを想定して、ランダムビットとの区別がつかないようにします。IVが単なるナンスである場合、または標準で誤って提案されているように、スキームで使用されるのと同じキーで暗号化されたノンスである場合、機密性は達成されません。暗号文は非常に順応性があります。選択暗号文攻撃（CCA）セキュリティはありません。多くのパディング方法で正しいパディングのオラクルが存在する場合、機密性は失われます。暗号化は本質的にシリアルであるため非効率的です。広く使用されているこのモードのプライバシーのみのセキュリティプロパティは、頻繁に誤用されます。CBC-MACアルゴリズムの構成要素として使用できます。CTRモードに勝る重要な利点はわかりません。
CFB：IVベースの暗号化スキームであるこのモードは、確率的暗号化スキームとして安全であり、ランダムIVを想定して、ランダムビットとの区別がつかないようにします。IVが予測可能である場合、または標準で誤って提案されているように、スキームで使用されるのと同じキーで暗号化されたナンスによって作成された場合、機密性は達成されません。暗号文は順応性があります。CCAセキュリティはありません。暗号化は本質的にシリアルであるため非効率的です。スキームはパラメータs、1≤s≤n、通常はs=1またはs=8に依存します。sビットのみを処理するために1つのブロック暗号呼び出しが必要な場合は非効率的です。このモードは、興味深い「自己同期」プロパティを実現します。暗号文への任意の数のsビット文字の挿入または削除は、正しい復号化を一時的に中断するだけです。
OFB：IVベースの暗号化スキームであるこのモードは、確率的暗号化スキームとして安全であり、ランダムIVを想定して、ランダムビットとの区別がつかないようにします。IVがナンスである場合、機密性は達成されませんが、IVの固定シーケンス（カウンターなど）は正常に機能します。暗号文は非常に順応性があります。CCAセキュリティはありません。暗号化と復号化は、本質的にシリアルであるため非効率的です。任意のビット長の文字列をネイティブに暗号化します（パディングは必要ありません）。CTRモードに勝る重要な利点はわかりません。
CTR：IVベースの暗号化スキームであるこのモードは、ナンスIVを想定したランダムビットとの区別がつかないようにします。安全なナンスベースのスキームとして、このモードは、ランダムIVを使用した確率的暗号化スキームとしても使用できます。ナンスが暗号化または復号化で再利用される場合、プライバシーの完全な失敗。モードの並列化により、多くの場合、他の機密モードよりもはるかに高速になります。認証付き暗号化スキームの重要な構成要素。全体として、通常、プライバシーのみの暗号化を実現するための最良かつ最新の方法です。
XTS：IVベースの暗号化スキームであるこのモードは、微調整可能なブロック暗号（強力なPRPとして保護）を各nビットチャンクに適用することで機能します。nで割り切れない長さのメッセージの場合、最後の2つのブロックは特別に扱われます。このモードで許可されている唯一の使用法は、ブロック構造のストレージデバイス上のデータを暗号化することです。基礎となるPRPの幅が狭く、小数の最終ブロックの処理が不十分であることが問題です。（ワイドブロック）PRPセキュアブロック暗号よりも効率的ですが、あまり望ましくありません。
ALG1–6：MACのコレクションであり、すべてCBC-MACに基づいています。スキームが多すぎます。いくつかはVILPRFとして証明可能安全であり、いくつかはFIL PRFとして証明可能であり、いくつかは証明可能安全性を持っていません。一部のスキームは、有害な攻撃を認めています。一部のモードは古くなっています。キー分離は、それを備えたモードでは十分に注意されていません。まとめて採用するべきではありませんが、「最良の」スキームを選択的に選択することは可能です。また、CMACを優先して、これらのモードを採用しないこともできます。ISO 9797-1 MACの一部は、特に銀行業務で広く標準化され、使用されています。規格の改訂版（ISO / IEC FDIS 9797-1：2010）がまもなくリリースされます[93]。
CMAC：CBC-MACに基づくMACであり、モードは（VIL）PRFとして（誕生日の境界まで）証明可能安全です（基礎となるブロック暗号が優れたPRPであると想定）。CBCMACベースのスキームの本質的に最小限のオーバーヘッド。一部のアプリケーションドメインでは本質的にシリアル性の問題があり、64ビットブロック暗号で使用すると、ときどきキーの再生成が必要になります。MACのISO9797-1コレクションよりもクリーンです。
HMAC：ブロック暗号ではなく暗号化ハッシュ関数に基づくMAC（ただし、ほとんどの暗号化ハッシュ関数自体はブロック暗号に基づいています）。メカニズムは、好ましい仮定からではありませんが、強力な証明可能安全性の限界を享受しています。文献に密接に関連する複数の変種は、何が知られているのかを理解することを複雑にします。有害な攻撃はこれまで提案されていません。広く標準化され、使用されています。
GMAC：GCMの特殊なケースであるナンスベースのMAC。GCMの良い点と悪い点の多くを継承します。しかし、MACにはノンス要件は不要であり、ここではほとんどメリットがありません。タグが64ビット以下に切り捨てられ、復号化の範囲が監視および削減されない場合の実際の攻撃。ノンス再利用で完全に失敗。GCMが採用されている場合、とにかく使用は暗黙的です。個別の標準化にはお勧めしません。
CCM：CTRモード暗号化と生のCBC-MACを組み合わせたナンスベースのAEADスキーム。本質的にシリアルであり、状況によっては速度が制限されます。基礎となるブロック暗号が優れたPRPであると仮定すると、十分な範囲で安全である可能性があります。明らかに仕事をする不格好な建設。GCMよりも実装が簡単です。ノンスベースのMACとして使用できます。広く標準化され、使用されています。
GCM：CTRモード暗号化とGF（2128）ベースのユニバーサルハッシュ関数を組み合わせたナンスベースのAEADスキーム。一部の実装環境で優れた効率特性。タグの切り捨てが最小限であると仮定すると、証明可能安全性の高い結果が得られます。実質的なタグの切り捨てが存在する場合の攻撃と証明可能安全性の限界。ノンスベースのMACとして使用できます。これはGMACと呼ばれます。96ビット以外のナンスを許可するための疑わしい選択。ナンスを96ビットに制限し、タグを少なくとも96ビットに制限することをお勧めします。広く標準化され、使用されています。
広く利用可能なものに基づいて選択することをお勧めします。私は同じ質問をしました、そしてここに私の限られた研究の結果があります。
ハードウェアの制限
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
ウィキペディアでこれに関する情報を読むことから始めましたか？ブロック暗号操作モード？次に、ウィキペディアの参照リンクをたどってNIST：ブロック暗号モードの操作に関する推奨事項を参照してください。
私は1つの側面を知っています。CBCはブロックごとにIVを変更することでセキュリティを向上させますが、ランダムにアクセスされる暗号化されたコンテンツ（暗号化されたハードディスクなど）には適用できません。
したがって、シーケンシャルストリームにはCBC（およびその他のシーケンシャルモード）を使用し、ランダムアクセスにはECBを使用します。