暗号化ハッシュとMAC（または、ハッシュだけでは不十分な理由）
ハッシュとMACを比較して、いくつかの質問が既に出されていますが、私は検索しましたが、私の質問に対する回答が見つかりませんでした。
通常、「Encrypt（M、k）|| MAC（M、K）」を送信して、受信者がメッセージの整合性と認証を確認できるようにします。
しかし、「Encrypt（M、k）|| Hash（M）」も同じように機能するようです。このメッセージ認証のスキームは脆弱ですか？
単純なEncrypt-and-MAC（つまりEncrypt(M, k) || MAC(M, K)）にも脆弱性があることに注意してください。攻撃者がメッセージに含まれる可能性のあるプレーンテキストの数を知っている場合、既知のプレーンテキストのMAC /ハッシュと比較することにより、メッセージの内容を把握できます。暗号化とハッシュにも同じ脆弱性があり、攻撃者は同じ内容の過去のメッセージを傍受する必要がなく、類似したテキストのハッシュを計算することで独自のハッシュを生成できるため、はるかに簡単です。
たとえば、アリスが常に午前6時にボブにメッセージを送信することがわかっている場合、「今日のコーヒーはカプチーノ/ブラック/モッカチーノ」の3つの可能なコーヒーの選択肢の1つです。メッセージのハッシュがそれらのいずれかに一致する場合、アリスの選択肢がわかります。コーヒーの。
MACでは、それを以前の既知の平文または「Oracle」（選択した平文で暗号化されたメッセージを生成できる）と照合する必要があります。これは 選択された平文攻撃 と呼ばれます。
現在受け入れられているベストプラクティスは、MACを暗号化することです（つまり、Encrypt(M, k) || MAC(Encrypt(M, k), K)）。
問題は、なぜこれをEncrypt-then-hashに置き換えないのかということです：Encrypt(M, k) || Hash(Encrypt(M, k))は明白です。誰でも暗号化部分のハッシュを計算できるため、このハッシュは実際には認証を提供しません。
おまけ：MAC-then-Encrypt（つまりEncrypt(MAC(M, K), k)）も考えられます。これは、暗号化されたテキストを変更する攻撃に対して脆弱であり、サーバー上でガベージを生成し、不正なハッシュのために拒否されますが、それでも攻撃者に役立つ情報を提供できます。そのような攻撃の1つが パディングOracle攻撃 です。 Hash-then-Encryptは同じ攻撃に対して脆弱です。
Authenticated encryptionまたはAuthenticated Encryption with Associated Dataのトピックについて読むことをお勧めします。
authenticationタグを質問に追加したのと同じように、それが実際の答えです。 MACには、通信している当事者だけが知っておくべき情報、つまり鍵が含まれます。 （質問のように）暗号化とペアになっている場合、MACは対称暗号化で使用されるため、鍵は同じであり、通信している2つの当事者だけが知っている必要があります。
単純なハッシュ（これはintegrityを提供します）とは対照的に、MACはauthenticationも提供します。
（非対称暗号化では、デジタル署名がこれらの機能を提供します。）
攻撃者はとにかくハッシュを生成するために復号化されたメッセージを必要とするため、暗号化を実行する場合、これはそれほど重要ではありません。 MACのauthenticationの部分は、暗号化されていない通信ではより重要です。
地獄、Kがブロック暗号の鍵であり、Mが平文であると仮定すると：
Encrypt(M, K) || MAC(M, K)Encrypt(M, K) || Hash(M || K)
高レベルの意味で同等です。秘密鍵を入力として受け取る暗号化ハッシュは、MACを生成する有効な方法であるためです。