https://blog.cryptographyengineering.com/2011/12/matt-green-smackdown- watch-are-aead.html
因此，我的问题是：
AEAD是否更有可能失败（容易受到选择的明文攻击，而HMAC更能保护加密部分安全地），如果这样，它是否会以更灾难性的方式失败？
假设您已经安全地生成了HMAC和加密密钥，那么Encrypt + HMAC是否更安全？
#1 楼
在某些方面，我倾向于不同意Colin Percival的观点。最大的陷阱是使用短路串比较与恒定时间串比较。给定前者，人们可以使用定时攻击为任意密文伪造有效的HMAC。使用像CBC这样的加密模式，它可以用于读取加密消息的内容。其他陷阱还包括意外地实现了Encrypt-and-MAC或MAC-then-encrypt，这些历史上一直存在与其构造相关的漏洞。另一方面，EAX和GCM模式透明地提供了此功能。对于潜在的针对专用AEAD模式的侧信道攻击存在一些担忧，并且还存在可能将未经身份验证的数据包传递到解密算法的概念性问题。当然，您必须正确了解诸如独特的IV之类的详细信息，但您也需要对Encrypt-then-MAC进行此操作。人员立即获得相关库的补丁。非密码学专家天真地比较HMAC的缺点很普遍，甚至像Google的KeyCzar这样的备受瞩目的项目也犯了这个简单的错误。如果您完全知道自己在做什么，那么Encrypt-then-HMAC是一种可证明是安全的结构。如果您不知道自己在做什么，则可能会发现诸如EAX或GCM之类的弱点，但肯定比自己实现某些弱点更好。编辑：我可能使Encrypt-then-HMAC的声音比实际要容易。 Encrypt-then-HMAC的另一个主要缺陷是没有对所需的信息进行HMAC处理，或者没有对HMAC进行正确的处理。 HMAC必须包含密文，附加身份验证数据和初始化向量。它可能还必须（可能是其他人可以确认或否认）包括描述符以标识所使用的加密算法。要将这些字段传递到HMAC，您必须使用明确描述字段的格式。最简单的方法是在任何可变长度字段（通常只是身份验证数据和密文）之前添加一个4字节的大端长度。如果您没有HMAC所有这些信息，则攻击者可以修改未包括的任何数据。如果您没有明确地使用HMAC，则攻击者可以操纵消息边界，这可能使他能够进行利用。
编辑2：我忘记了Encrypt-then-HMAC的另一个细节。希望你能明白这是多么困难。理想情况下，永远不要在安全上下文之间重用同一密钥。我不知道将加密密钥用作HMAC密钥会导致任何攻击，但是最佳实践是使用其他密钥进行加密和身份验证。一种简单的方法（假设使用256位加密算法和256位HMAC）是使用“虚拟” 512位密钥。将前半部分用于加密，将后半部分用于身份验证。另一种方法是使用256位密钥，但将其通过512位输出的HKDF传递。像以前一样使用它：将其分为两部分，一个用于加密，另一个用于身份验证。
编辑3：几个月前，我在安全性StackExchange上提出了一个高度相关的问题。 Thomas Pornin的详细答案可能会有所帮助。
评论
$ \ begingroup $
我从这个答案中缺少的是协议在所有这一切中扮演的角色。有很多协议，其中一个不正确的MAC会终止该协议，删除会话密钥，然后要求重新认证。这样检索辅助信道信息相当棘手。您需要某种预言才能使之实用。
$ \ endgroup $
–马腾·博德威斯♦
2014年8月1日13:48
$ \ begingroup $
当然，对于挑战响应协议，如果挑战确实是随机的，那么旁道攻击也不会有太大帮助。
$ \ endgroup $
–马腾·博德威斯♦
2014年8月1日13:50
#2 楼
我认为这个问题分为两个部分，一个是关于AEAD原则上与Encrypt + HMAC，另一个是关于AES-GCM。在校验和中，这可能会降低其强度，并且在您绝对应重新协商之前，对传输大小（64GB）的众所周知的限制是众所周知的；阅读本文以获取更多信息：http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/CWC-GCM/Ferguson2.pdf我还记得阅读过一篇论文将galois字段MAC计算与DJB的poly1305进行了比较，指出质数（2 ^ 130-5）具有明显更好的性能。但是，对于实际的攻击而言，这还不够。
这些弱点与特定的AEAD加密方案AES-GCM有关；其他人更安全。被认为比AES-GCM更安全的AEAD密码套件的例子有DJB的ChaCha20 + Poly1305，以及双工模式下的Keccak。仅是加密库的用户，而不是Encrypt + HMAC。这并不意味着它们必须在技术上不同于Encrypt + HMAC，而只是您使用将加密和HMAC都结合在一起的库，例如ChaCha20 +聚1305。从技术上讲，ChaCha20只是没有身份验证的流密码，而Poly1305只是身份验证。另一方面，双工模式下的Keccak实际上是通过相同的操作来计算身份验证和加密，因此它是通过设计集成的。
评论
$ \ begingroup $
GCM的“校验和”有哪些缺点？
$ \ endgroup $
–森林
19年9月9日在7:10
评论
在GCM之类的模式下，基于通用哈希的身份验证的属性与CTR模式加密的属性非常相似：如果正确使用，它的性能很强，但是如果重用（密钥，随机数）对，则灾难性地失败。 HMAC不需要随机数。就个人而言，我在使用长期密钥时更喜欢HMAC，而在使用会话密钥（以计数器为随机数）时更喜欢通用哈希。
请注意，Encrypt + HMAC的组合可以看作是EAED方案。
@CodesInChaos可以设计一个通用的哈希函数，以使现时重用不会导致灾难性的失败，不是吗？