認証された暗号化と封じ込められた暗号化されたチェックサム/ハッシュ？
だから私は http://en.wikipedia.org/wiki/Authenticated_encryption と http://www.cryptopp.com/wiki/Authenticated_Encryption を読み、私はしませんコンセプトに従っているようです。
提供されている簡単な例から、Authenticated Encryptionは、メッセージが変更されていないことを証明することを目的としているようです。
私の質問はこれです-目標が単にペイロード/コンテンツが変更されていないことを確認することである場合（ここでも、攻撃者はキーを持っていないため、バイナリレベルでメッセージを変更しています）、なぜそうしないのですか？暗号化されたコンテナ内にペイロードの後続ハッシュを含めることで、検証に十分ですか？
暗号化されたAESメッセージの場合、メッセージが受信され、事前共有対称鍵を使用して復号化され、メッセージ（データ）とハッシュが評価されます。ペイロード/データはハッシュされ、受信したハッシュと比較されます-それらが一致する場合、メッセージが改ざんされていない可能性が非常に高いです。
だから...私の質問はこれです。それは本当にシンプルに見えますが、それでも私よりはるかに経験豊富でインテリジェントな人々は、認証済み暗号化に多くの時間を費やしてきました。
前もって感謝します。
概要。提案は安全ではありません（暗号解読については以下を参照してください）。これが、認証された暗号化の合理的な代替手段ではない理由です。
背景をもう少し。認証された暗号化が必要なのはなぜですか？ 認証なしの暗号化は安全ではありません であるためです。多くの開発者はこれを知らないため、暗号化の使用が安全ではなくなります。
暗号化アルゴリズムと認証アルゴリズムの両方を手動で使用することが可能です。たとえば、安全な暗号化スキームと安全なメッセージ認証（MAC）アルゴリズムを使用して encrypt-then-authenticate構文 を使用できます。ただし、これには開発者による追加の努力が必要です。
認証された暗号化は、開発者が簡単に使用できる単一のプリミティブとして設計され、必要なすべての認証を提供します（セキュリティを提供するために追加の作業を行う必要はありません）。したがって、セキュリティに役立ちます。一部の認証済み暗号化スキームには、個別に暗号化してから認証するよりもパフォーマンスが向上するという利点がありますが、これは2番目の考慮事項です。
この問題の詳細については、 認証なしで暗号化を使用しないでください を参照してください。
スキームの暗号解析。暗号化する前にメッセージのハッシュを追加することを提案しました：言い換えると、-[〜＃〜] c [〜＃〜] =暗号化（[〜＃〜] k [〜＃〜]、M || H（M））、ここでは、ビット文字列の連結を表します。このスキームは、多くの暗号化アルゴリズムにより、選択された平文攻撃に対して安全ではありません。たとえば、CBCモードの暗号化を使用している場合、提案に対する攻撃を示します（攻撃は他の多くの暗号化モードにも適用されます）。
中間者が（ブロック境界で）CBCモードで生成された暗号文を切り捨てた場合、受信者は切り捨てに気付かず、復号化後に送信者が切り捨てたバージョンのメッセージを受信することに注意してください。送信しようとしていました。だから、その背景で、ここに攻撃があります。アリスを送信者、ボブを受信者とし、選択された平文設定を想定します。
攻撃者は何らかのメッセージを選択します[〜＃〜] m [〜＃〜]アリスが送信することを望みますが、アリスはそれを送信することを拒否します（多分[〜＃〜] m [〜 ＃〜]は、「私のアカウントから$ 100を送金して攻撃者に渡す」などと言っています。攻撃者は、他の値[〜＃〜] x [〜＃〜]を作成して、アリスが喜んで送信するM ' = M || H（ M）|| X（たぶん[〜＃〜] x [〜＃〜]は「冗談ですよ！あえてしないでください」と言います）。攻撃者は、アリスに暗号化してM 'を送信するように仕向けます。これは、アリスが暗号文を送信することを意味しますC ' = Encrypt（[〜＃〜] k [〜＃〜]、M' || H （M '））=暗号化（[〜＃〜] k [〜＃〜]、M || H（M）|| X || H（M' ））。攻撃者は中間者を再生し、C 'をキャプチャして、飛行中に切り捨てます。 C ''を切り捨てた暗号文と呼びましょう。ボブはC ''を受け取り、それを復号化してから、ハッシュをチェックします。攻撃者が切り捨てポイントを正しく選択した場合、解読後にボブはM || H（M）を取得し、ハッシュをチェックして、ハッシュが正しいことを確認し、アリスが送信したはずであると結論付けます[〜＃〜] m [〜＃〜]。
言い換えると、この攻撃の終わりに、ボブはアリスがメッセージの送信を承認したと結論付けます[〜＃〜] m [〜＃〜]-しかし、彼女はそうしませんでした。 （彼女は他のメッセージの送信を許可しましたが、[〜＃〜] m [〜＃〜]は許可しませんでした。）
これが深刻なセキュリティの脆弱性であるかどうかは、メッセージの形式[〜＃〜] m [〜＃〜]など、それが使用されるコンテキストに依存します。しかし、経験的には、少なくとも一部のアプリケーションでは、この種の攻撃はアプリケーションに深刻な危険をもたらす可能性があります。したがって、暗号学者は、これは適切な汎用スキームではないと考えています。
are慎重に吟味され、汎用的な使用のために安全であることが証明されている優れたスキームがあることを考えると、暗号技術者はこれらの汎用スキームの1つを使用することをお勧めします（認証された暗号化、または、encrypt-then-authenticate構造）-特に、あなたが言及したものは使用しないでください。
このスタンフォード大学の暗号化コース をご覧ください。 Authenticated Encryptionについての講義があり、Authenticated Encryptionを使用する理由とその使用方法が示されています。また、さまざまなアプローチに欠陥がある可能性があることも示しています（SSHまたはSSLなど）。
Authenticated Encryptionを使用し、正しく使用する必要があります。つまり、自分で発明したり実装したりしないでください。
Authenticated Encryptionの使用は、適切な暗号化モード（CCM、GCM、EAXなど）を使用するのと同じくらい簡単です。残念ながら、フレームワークがこれらの動作モードを含まないことは非常に一般的であるため、追加のライブラリを使用する必要がある場合があります。