対称暗号化はデータの整合性を提供しますか？
たとえば、対称鍵でファイルを暗号化するサーバーが1台あるとします。 AES-CBC、それを復号化するクライアントに送信します。復号化するとデータの整合性が得られますか？または、ファイルが暗号化されている間に誰かがファイルを改ざんし、後でクライアントがファイルを復号化するときに、変更されたファイルを作成することは可能ですか？
私は通常、デジタル署名またはMACの使用に関してデータの整合性と信頼性について説明しますが、暗号化のコンテキストでは決して説明しません。暗号化はハッシュよりも高価であることを示すベンチマークも見ましたが、それは私の主な考慮事項ではありません。
[〜＃〜]更新[〜＃〜]
Linuxのopensslツールを使用してファイルを暗号化する実験を試みました。次に、さまざまな方法でファイルを変更してみました（バイトの変更、バイトの削除、バイトの追加）。いずれの場合も、解読しようとすると、「不正な解読」メッセージが表示されます。私が使用したコマンドは次のとおりです。
openssl enc -aes-128-cbc -in test -out test.enc
openssl enc -d -aes-128-cbc -in test.enc -out test.dec
対称暗号化は整合性を提供しますしません。攻撃者が暗号化されたデータを制御できる量は、暗号化の種類によって異なります。いくつかの暗号化モードの具体的な詳細によっては、攻撃者が外科的な変更を加えようとする場合、生活が少し難しくなる可能性があります。 CBCを使用すると、攻撃者は他の数十バイトをランダムなジャンクに変換することを気にしない限り、希望するビットを反転できます。
対称暗号化と整合性チェックを組み合わせた 最近の暗号化モード があります（ [〜＃〜] mac [〜＃〜] を使用）。これらのモードは、機密性と整合性の両方を保証します。 AES-CBCはそれらの1つではありません。整合性のある暗号化モードが必要な場合は、 [〜＃〜] eax [〜＃〜] をお勧めします。
更新：実験について：CBCは、ソースデータ長がブロック暗号ブロック長（AESの場合は16バイト）の倍数でなければならないモードです。任意の入力メッセージは任意の長さを持つ可能性があるため、いくつかのpaddingが追加されます。数バイトで、特定の内容が含まれているため、復号化時に明確に削除できます。あなたの場合、OpenSSLは、復号化の際に適切なパディング構造を見つけられないと不平を言っています。ただし、攻撃者が暗号化されたデータの最後の32バイトを変更しない場合、パディングは損傷を受けないため、最後の32バイト以外のすべての変更は検出されないままになります。また、最後の32バイトであっても、それほど小さな確率で検出を回避する方法があります。
CBC暗号化はデータの整合性を提供しません。理由は次のとおりです。
いくつかのキーk（攻撃者には不明）を修正します。 E（k、-）とD（k、-）をいくつかのブロック暗号の裸の暗号化および復号化関数とします。 pを平文の単一のブロックとする。 XOR=で示します。IVを修正した後、次のように暗号化します。
c = E（k、p + IV）。
次に、IVとcをネットワーク経由で送信します。復号化するには、
p = D（k、c）+ IV。
（これは、ステートメントD（k、c）= IV + pと同等であることに注意してください。）
ここで、攻撃者が単一の平文/暗号文のペアを知っているとします。上記のように、それらをpおよび（IV、c）と表記します。ここで、攻撃者が、自分が選択した他のプレーンテキストブロック（p 'など）に復号化する暗号文を作成したいとします。 （IV + p + p '、c）がp'に復号化すると主張します。どうして？
さて、上記の解読手順に従って、IVをIV + p + p 'に置き換えます。我々は持っています
D（k、c）+（IV + p + p '）=（IV + p）+（IV + p + p'）= p '。
面白いことに、ECBモードはこの問題の影響を受けません（ただし、私はその使用を推奨していません）。
AES-CBC暗号化は整合性を提供しません。実装および使用方法によっては、暗号テキストへの偶発的な変更を検出する場合がありますが、暗号テキストの悪意のある改ざんを防ぎます 。
認証なしの暗号化は、暗号化の使用における最も一般的な誤りの1つです 。 ASP.NET、XML暗号化、Amazon EC2、JavaServer Faces、Ruby on Rails、OWASP ESAPI、IPSEC、WEPなど）を含む多くのシステムに深刻な脆弱性をもたらしました。前のリンクを参照してください詳しくは。
修正：EAXなどの認証された暗号化スキーム（AES-CBCではない）を使用するか、CMACなどのメッセージ認証コードを暗号化してから認証モードで使用する必要があります。
暗号化を自分で実装する場合は、ここにある質問 暗号化と暗号化に関する学習した教訓と誤解 を読んで、最も一般的な間違いのいくつかを回避することをお勧めします。認証なしの暗号化の使用はその1つです。
対称暗号は、悪意のある、または偶発的な暗号文の変更を検出しないため、それ自体では整合性を提供しません。復号化では、元の平文以外のものが出力されます。これにより、復号化されたペイロードのプロトコル違反が発生しない限り、整合性の問題が発生します。
解決策は、パッケージの整合性を検証するために使用できるデータを含むパッケージ内にプレーンテキストをラップすることです。通常はハッシュベースのチェックサム（edit：キー付きHMAC）。これが行われることです。トランスポート層セキュリティ。
これが 例 であり、Versile Platformセキュアバイトトランスポートプロトコルで使用される平文保護スキームです（免責事項：私はVP開発に関与しています）。
編集：メッセージのカプセル化は、完全なファイルを使用するシナリオでは過剰であるため、完全なファイルにキー付きMACを追加するだけの方がよいことに気付きました暗号文。パッケージ保護形式の場合、D.W。詳細事項を指摘し、「チェックサム」はキー付きMACとして実行する必要があります。