如果散列，为什么要使用经过身份验证的加密？

Question

与更简单的方法（如 CRC）或散列函数（如 SHA）相比，使用 GCM 或 EAX 等经过身份验证的加密方案有什么好处？

据我了解，这些方法基本上是在消息中添加消息身份验证代码 ( MAC )，以便对其进行验证。但是，如果将计算 CRC 或哈希值并将其附加到明文 ( MIC ) 中，则同样可能。这样也无法篡改消息，因为散列可能不再匹配。

链接的维基百科文章说 MIC 不考虑密钥等，但我不明白为什么这是一个问题。

Answer 1

认证加密方案（GCM、CCM、EAX 等）和通过加密消息提供 HMAC 之间在概念上没有区别，AE 算法只是限制和标准化字节模式（同时往往需要比串行操作更少的空间/时间加密和 HMAC）。

如果您在加密之前对明文计算未加密的摘要，您确实有一个防篡改算法。但是在明文上计算摘要比在密文上计算有两个缺点：

1. 如果你发送相同的东西两次你发送相同的哈希，即使你的密文不同（由于不同的 IV 或密钥）
2. 如果密文已被篡改以试图混淆解密程序，您仍将在发现篡改之前对其进行处理。

当然，后消化的缺点是在你的无密钥方法中，任何篡改密文的人都可以简单地重新计算篡改后密文的 SHA-2-256 摘要。对此的解决方案是不进行无键摘要，而是进行键摘要，如 HMAC。

选项是：

• 仅加密：可被篡改。假设每条消息都使用新的 IV（并且不使用 ECB）不会显示消息何时重复。
• 仅摘要：可能会被篡改。消息是纯文本的。
• MAC-only：不受篡改。消息是纯文本的。
• 摘要然后加密（DtE - 摘要本身已加密）：可能存在密文损坏攻击。篡改明文是可能的，如果它是已知的。消息重用没有透露。
• 摘要和加密（D&E/E&D - 摘要明文，以明文形式发送摘要）：可能存在密文损坏攻击。篡改明文是可能的，如果它是已知的。消息重用通过未更改的摘要显示。
• Encrypt-then-Digest (EtD)：这可以防止传输错误，但由于任何攻击者都可以重新计算摘要，这与仅加密相同。
• MAC-then-Encrypt (MtE)：与 DtE 具有相同的优势，但即使攻击者知道原始明文及其篡改内容，他们也无法更改 MAC（除非将明文更改为已知消息 + MAC ）。
• MAC-and-Encrypt (M&E/E&M)：与 D&E 一样，这揭示了消息重用。像 MtE 一样，它仍然容易受到密文损坏和很小的篡改。
• Encrypt-then-MAC (EtM)：MAC 发现任何更改密文的尝试未能验证，这可以在处理密文之前完成。由于 MAC 位于密文之上，因此不会显示消息重用。

EtM 是一般情况下最安全的方法。AE 算法解决的问题之一是，它将如何将 MAC 和密码从开发人员手中结合起来的问题交给密码学家处理。