AES-CTRのデメリット？
紙の上では、それは私にとって*非常に*良いように聞こえます：
- 安全
- 高速（私のテストではECBよりもやや遅いですが（ただし、ほとんどの弱点はありませんが、以下で詳しく説明します）
ECB, CTR, CBC, OFB, CFB、パフォーマンスの順に記述された他のすべての代替手段よりも高速です（ベンチマークコードへのリンク）） - 理解しやすい
- パディングは必要ありません（これにより、安全でない方法でパディングを実装する可能性が大幅に減少すると思います）
- 並列化をサポート（暗号化と復号化の両方）
- ランダムアクセスをサポート
..私が考えることができる唯一の欠点は、パディングを必要としないため、実際の実装では、メッセージの長さの前後を明らかにするのと比較して、おそらく正確なメッセージの長さを明らかにすることです（たとえば、パディングされたスキームはthe message is within 15 bytes of this length、 -パディングされたスキームはthe message is *exactly* this long）を明らかにするかもしれません、そしてそれが懸念であるならば、それはとにかくパディングを追加するだけでそれを軽減することができないというわけではありません。
何か足りないので…
欠点は何ですか？
回答
短所：
メッセージの長さ：暗号化では、通常、メッセージの長さは秘密とは見なされません。これが本当に情報漏えいである場合は、最後または最初、あるいはその両方にランダムな値を追加できるアプローチがあります。ランダムなアプローチは、実際のデータケースによって異なります。電子メールは512文字に制限できるため、事前に決定された固定サイズを使用することもできます。結局、すべての場合において、少なくとも上限が明らかになります。
（IV、キー）ペアの再利用は、ベビーベッドをドラッグする手法で機密性を排除できる実際の問題です。これは暗号化キーを明らかにしません。
認証の欠如すべての認証されていない暗号化モードと同様に、ベアCTRモードには整合性と認証がありません。CTRモードの順応性により、1ビットの反転で壊滅的な結果が生じる可能性があります。
AES-GCMの操作のCTRモードを使用するモードは、一度ALL-IN-、しかし、それは同じ（IV、キー）ペアの再利用の問題を持っているあなたに提供します。これを排除するノンス誤用耐性（紙、rfc8452）として合成初期化ベクトル（SIV）モードがあります。SIVモードでも、同じメッセージが同じキーで送信されることをリークする可能性があるため、オブザーバーはこれを区別できます。
長いメッセージの区別： CTRモードは、疑似ランダム関数（PRF）を使用して設計されています。CTRモードでAESを使用する場合、疑似ランダム置換（PRP）で使用します。$$E_k\colon \{0,1\}^n \to \{0,1\}^n.$$ メッセージブロックがシーケンスを繰り返さない限り、PRPをホイットします $E_k(0), E_k(1), \dots, E_k(\ell - 1)$ と $\ell < 2^n$繰り返されません。長さのあるメッセージの場合$\ell$-ブロックには繰り返しブロックがありません。これは問題ありません。均一なランダムブロックとしてメッセージに近づくと、衝突が予想されます$\ell \approx \sqrt{2^n} = 2^{n/2}$ 誕生日のパラドックス/攻撃によって。
長いメッセージにAES-128を使用する場合は、繰り返しを確認してください。この繰り返しにより、攻撃者はこれを無視できない確率で一様ランダムと区別することができます。
つまり、任意の位置に重複する暗号文があると、メッセージが異なることがリークされます。
キーあたりのメッセージサイズ： NISTは64ナンスと64ビットカウンターと言っていますが、かなり前にキーの使用を停止する必要があります$2^{64}$ブロック。これは、CTRモードでPRFの代わりにPRP（AES）を使用しているためです。
その他の利点：
復号化の必要はありません： CTRモードでは、ブロック暗号の復号化は必要ありません。常に暗号化に使用されます。これは、制約環境で非常に役立ちます。ソフトウェアとハードウェアのコードも簡素化します。
PRPは不要：ブロック暗号（PRP）はまったく必要ありません。ハッシュ関数は、 ChaChaのシリーズのように使用することができます。
前処理： CTRモードで生成されたキーストリームは前もって準備できます。これは、バッファの使用に役立ちます。
CTRモードにはCPAセキュリティがあります。
クリック率の小さな歴史
CTRモードは、1979年にホイットフィールドディフィーとマーティンヘルマンによって導入されました。
プライバシーと認証： IEEEの議事録に関する招待論文としての暗号化入門、67（1979）、397〜427ページ。
対称暗号化の処理の具体的なセキュリティ、Bellareet。al、97はセキュリティの限界を提供します。
も参照してください。AES動作モードに関するNISTへのコメント：CTRモード暗号化、Lipmaa他による。長所と短所のその他の詳細については。
SchneierとFergusonは当初CTRモードを推奨していましたが、カウンターがキーで再利用されないようにすることが難しい可能性があるため、CBCモードの推奨に切り替えました。
あなたの質問は物事のCTR側に焦点を当てているように見えますが、物事のAES側についても議論する価値があります。他のブロック暗号がより適切である可能性がある状況は少なくとも2つあります。
安全な計算：
安全な計算に関して、AESには2つの主な「難しさ」があります（主にマルチパーティ計算とNIZKを意味しますが、完全準同型暗号化も可能です）。
AESは、特性2のフィールドに対して計算されます。MPC/ FHEシステムが特性を使用する場合 $p$ 算術、標数2に暗号がある場合、異なる表現間の変換が必要です（たとえば、 $\mathbb{Z}/p\mathbb{Z}$、またはそのような要素の2を底とする分解）は、標準の計算よりもコストがかかります。
一般的に、安全な計算のコンテキストでは、乗算は加算よりもはるかにコストがかかります（比較的）。これは、暗号を構築するための異なる「コストモデル」を持つことができることを意味します。この場合、一般的に暗号の乗算の数を減らすことに関心があります。
このトピックを探すための暗号はMiMCです（最近、この暗号に対する部分的な攻撃が「$\mathbb{F}_{2^k}$ それのバージョン」。それはまた「$\mathbb{F}_p$「攻撃を受けないバージョン）。
組み込みシステム：
標準のマシンでは、（AES-NI命令を介した）AESのハードウェア実装により、AESの最適化されたソフトウェア実装よりも約40倍高速化されます。これにより、AES-NIを他の暗号のソフトウェア実装と比較するときにAESとの競争が難しくなります。ただし、AES-NIがない場合は、他の暗号の方が競争力が高くなる可能性があります。Matthew Greenによるこの投稿では、 AESの代替手段の使用について説明しています（記録として、これを8年前に書いたときの彼の推奨は、これを行っていませんでした）。ソフトウェアでAESよりも2倍から3倍高速化するSalsa20などの特定の暗号について説明しています。Salsa20は技術的にはブロック暗号であるAESと比較してストリーム暗号ですが、これはAES-NIにアクセスできないときにAESを高速で「打ち負かす」ことができるようにするためです。
制約のあるコンピューティング環境でより高速な暗号を入手するためのより良い情報源は、進行中のNIST Lightweight CryptographyStandardizationです。私はこれを厳密に追跡していませんが、現在、組み込みシステムでの（本質的に）使用のために標準化する新しい暗号を見つけることに多くの研究関心があります。彼らは現在、来たる12月に第3ラウンドのファイナリストを投稿することを計画しているので、今後数年以内に組み込みシステムでのAESの使用に代わる「新しい暗号」があったとしても私は驚かないでしょう。
CTRは確かに非常に優れたブロック暗号モードの動作です。その主な欠点は次のとおりです。
- メッセージの整合性を保護しません（実際、攻撃者は暗号化されたメッセージの任意のビットを復号化せずに簡単に反転できます）。
- カウンタブロックが再利用されると、平文がリークする可能性があります。特に、CTRモードの暗号化には、同じキーで暗号化された2つの異なるメッセージに絶対に再利用してはならない一意のナンス入力が必要です。
幸い、これらの問題は両方とも、CTRモードを高レベルの構造のコンポーネントとして使用することで解決できます。
- 最初の問題は、認証された暗号化モードを使用することで解決できます。その多く（EAXやGCMなど）は、CTRモードとメッセージ認証コードの組み合わせに基づいています。
- 2番目の問題は、暗号化されているプレーンテキストメッセージに基づいて初期カウンター値を導出する「ノンス誤用防止」暗号化モードを使用することで解決できます。このようなモードには、SIVおよびGCM-SIVが含まれ、どちらもCTRモードに基づいており、上記のようにメッセージ認証も提供します。
もちろん、メッセージ認証を追加するには、これらのモードを生のCTRよりも遅くする追加の処理が必要です（ただし、GCMの適切な実装は依然として非常に高速です）。特に、これらのモードが保証する完全なセキュリティを取得するには、受信者は、復号化されたプレーンテキストを渡す前にメッセージ全体を認証する必要があります。誤用防止モードの場合、暗号化する前にメッセージ全体を処理して初期カウンター値を導出する必要があるため、暗号化時にも同じことが当てはまります。
それでも、セキュリティを強化するために支払うのは一般的に小さな代償です。SIVやGCM-SIVのようなノンス誤用防止モードを使用できる場合は、使用することを強くお勧めします。そうでない場合は、少なくともGCMのようなノンスベースのAEモードを使用してください。