AES-256-GCMの方が安全なのに、なぜAES-256-CBCを使用するのですか？
私の質問の要点は：CBCがGCMよりも優れているケースはありますか？
私が尋ねている理由は、マシュー・グリーンによる この投稿 と、暗号スタック交換に関する この質問 、および この説明 XMLへの攻撃（私は仕事でjsonを暗号化していますが、どこにもストリーミングされていませんが、選択されたCipertext攻撃が可能であると思われます）ので、CBCを決して使用せず、GCMのみを使用してください。
言い換えると、GCMが存在する限り、CBCを使用する理由はありません（ OpenSSLで機能します 、私の暗号化作業に使用するライブラリ）。なぜなら：
GCM = CBC +認証。
私の結論が正しいかどうか誰かに教えてもらえますか？
重要な更新：この質問は非常に人気が出てきているので、私は私の研究からそれを指摘したいと思います GCM IS NOT A SILVER BULLET。GCMには大きな問題があります。つまり、同じIVを2回使用すると、キーが危険にさらされる可能性があります（ GMACを使用しているので、それは誰にでもできることではありません。（私のように）偏執狂の場合は、HMACを使用したCBC（ encrypt then MAC ）が、安全を確保したい場合に最適です。 （このアップデートで間違っていた場合は修正してください）。
CBCとGCMはかなり異なります。どちらも正しく使用すれば安全ですが、CBCはそれほど並列化できず、組み込み認証がありません。このため、CBCは、ランダムアクセスを必要としないローカルファイルを暗号化する場合にのみ実用的です。
それが持つかもしれないどんな利点に関しても、IVが再利用される場合、CBCは破滅的なほど失敗することはなく、基本的なハードウェアに実装される場合、それはより速くなることができます。
GCMに関しては、基本的にはGCM = CTR + Authentication（CBCではない）です。正しく使用すれば高速で安全であり、非常に用途が広いため、人気があります。
- CBCの方が古いため、互換性が高くなり、全体的な歴史的な理由だけです。
- 信頼性のためにGCMが必要ない場合、 パフォーマンス上の利点 があります。多くの場合、いくつかの追加の特性を備えた真正性のために独自のシステムが必要になるか、まったく必要ない場合があります。
大きなひっくり返る：
GCM = CBC +認証。
いいえ、GCM = CTR +認証。
しかし、一般的にはあなたが正しいです。 CBCは、暗黒時代に暗号学的に言えば（1970年代までに）発明された古いモードであり、組み込み認証の欠如と、オラクルのパディングによって引き起こされるすべての問題のため、現在は好まれていません。この良い例の1つは、TLS 1.3がCBCのサポートを廃止したことです。
ただし、GCMも万能薬ではありません。それは厳密に言えば正しいですが、実際には絶対確実ではないことが証明されています。
- Nonceを再利用すると、見事に失敗します。単一の繰り返されたナンスにより、攻撃者はその認証サブキーを回復でき、さらに、同じナンスを持つ2つのメッセージのXORを学習できます。
- そのノンスは不快に短く（96ビット）、これは ランダムなノンスで使用するのが難しい場合があります です。
CBCにはこれらの問題はありません。ランダムIVは問題なく動作し（実際には必須です）、IVを繰り返しても致命的なエラーは発生せず、平文の同じプレフィックスに関する情報が漏洩するだけです。
簡単に言うと、CBCが最初に来ました。 CBCのみをサポートするシステムを使用している可能性があります。
これは、「AESとSHA-2が利用可能な場合、なぜRC4とMD5を使用するのですか？」と同じ質問になります。互換性と歴史。 （他の多くの暗号の選択肢と同じです。）
すべてのシステムがAES-256-GCMをサポートし、それを実行するためのリソースがあり、より高いセキュリティが必要な場合は、AES = 256-GCMを使用します。
たとえば、1024ビットの証明書を使用して、SSL3、RC4、MD5より新しいものをサポートしていないシステムがあります。 （2018年、はい）。確かに、最近のROT13ほど良くはありませんが、実際に暗号化を必要としないこのデータには十分です。 （最近、人々はこれらのものをIoTと呼びます。）