我们应该MAC-then-encrypt还是加密然后MAC?

大多数情况下,当某些数据必须加密时,还必须使用MAC来加以保护,因为加密只能保护被动攻击者。有一些漂亮的加密模式,其中包括一个MAC(EAXGCM …),但假设我们正在做旧式加密,所以我们有一个独立的加密方法(例如带有CBC链接和PKCS#5填充的AES)和独立的MAC(例如带有SHA-256的HMAC)。我们应该如何组装加密和MAC?

  • MAC-then-Encrypt:在明文上计算MAC,将其附加到数据,然后加密整个?(这就是TLS所做的)
  • 加密和MAC:在明文上计算MAC,加密明文,然后将MAC附加到密文的末尾?(这就是SSH所做的)
  • Encrypt-then-MAC:加密明文,然后在密文上计算MAC,并将其附加到密文?(在这种情况下,我们不要忘记将初始化矢量(IV)和加密方法标识符包含在MACed数据中。)

前两个选项通常称为“MAC-then-encrypt”,而第三个选 项则是“encrypt-then-MAC”。什么是支持或反对的论据?

答案


我假设你比我更了解所有这些……无论如何,这篇论文总结了所有这些方法以及它们提供或不提供的安全级别。据我了解,我将用英文解释它,而不是数学符号,在这里:

  • 加密-然后-MAC:
    • 提供密文的完整性。假设MAC共享密钥没有被破坏,我们应该能够推断给定的密文是真的还是伪造的; 例如,在公钥密码学中,任何人都可以向你发送消息。EtM确保您只能阅读有效的消息。
    • 明文完整性。
    • 如果密码方案具有延展性,我们不必如此担心,因为MAC会过滤掉这个无效的密文。
    • MAC不提供关于明文的任何信息,因为假设密码的输出是随机的,MAC也是如此。换句话说,我们没有从明文进入MAC的任何结构。
  • MAC-然后加密:
    • 不对密文提供任何完整性,因为我们无法知道,直到我们解密消息,无论它是真的还是伪造的。
    • 明文完整性。
    • 如果密码方案具有延展性,则可能会将消息更改为显示有效并具有有效的MAC。这当然是理论上的一点,因为实际上MAC秘密应该提供保护。
    • 在这里,MAC无法提供任何有关明文的信息,因为它是加密的。
  • 加密和-MAC:
    • 因为MAC是针对明文的,所以密文没有完整性。这为密码上的某些选择密文攻击打开了大门,如Breaking and proofvach修复SSH认证的加密方案的第4部分所示:Encode-then-Encrypt-and-MAC范例的案例研究
    • 可以验证明文的完整性
    • 如果密码方案是可延展的,密文的内容可以被改变,但是在解密时我们应该发现明文是无效的。当然,在解密过程中可以利用的任何实现错误都是在那一点上。
    • 可能会显示有关MAC中明文的信息。当然理论,但不是理想的情况。如果明文消息重复出现,并且MACed数据不包含计数器(它在SSH 2协议中执行,但仅作为32位计数器,所以在溢出之前应该注意重新生成密钥)。

简而言之,Encrypt-then-MAC是最理想的方案。对不具有有效MAC的密文的任何修改都可以在解密之前被过滤出来,以防止对实现的任何攻击。MAC也不能用来推断明文的任何内容。MAC-then-Encrypt和Encrypt-and-MAC都提供不同级别的安全性,但不是Encrypt-then-MAC提供的完整集合。


@Ninefingers相当好地回答了这个问题。我只想添加一些细节。

加密 – 然后MAC是大多数研究人员推荐的模式。大多数情况下,它更容易证明加密部分的安全性(因为得益于MAC,解密引擎不能输入无效的密文;这样可以自动防止选择的密文攻击),并且还可以避免MAC的机密性问题(因为MAC使用加密文本进行操作,所以不管它的质量如何,它都不能透露任何有关明文的内容)。请注意,在本领域已应用于ASP.NET 的填充oracle攻击是选择密文攻击。

Ferguson和Schneier在其着作Practical Cryptography中提出了相反的观点:MAC-then-encrypt(或MAC-and-encrypt)是“自然”的顺序,并且加密 – 然后MAC过于复杂。加密 – 然后MAC的痛点是你必须小心你的MAC:你不能忘记初始化向量,或者(如果协议允许算法的灵活性)加密算法的明确标识符; 否则,攻击者可能会改变,导致一个明文的改变,而这个改变不会被MAC检测到。为了证明他们的观点,Ferguson和Schneier描述了对IPsec实例的攻击,其中加密 – 然后MAC没有正确完成。

因此,虽然加密 – 然后MAC理论上更好,它也有点难以正确。


Hugo Krawczyk的论文题为“保护通信的加密和身份验证顺序”(或:SSL的安全性如何?)。它识别3种类型的组合认证(MAC)与加密:

  1. 然后加密IPsec中使用的 Authenticate(EtA);
  2. 验证SSL中使用的加密(AtE);
  3. SSH中使用的加密和验证(E&A)。

它证明,ETA是使用安全的方式,并且两个ATE和E&A受到攻击,除非加密方法或者是在CBC模式下,或者它是一个流密码。

摘要说明了一切; 我强调了他们的重要部分:

我们研究如何在通过不安全网络保护通信时建立“安全通道”时,如何统一构成对称加密和认证。我们证明,设计用于安全加密(针对所选明文攻击)和安全MAC的任意组合的任何安全通道协议都必须使用加密后验证方法。我们通过表明撰写加密和认证,其中包括的其他常用的方法证明这种身份验证,然后,加密中使用的方法SSL,是不是一般安全。我们展示了一个加密函数的例子,该函数提供了(Shannon的)完美的保密性,但是当与authenticate-then-encrypt方法下的任何MAC函数结合时,会产生完全不安全的协议(例如,查找在保护下传输的密码或信用卡号这种协议对于主动攻击者来说变成一件容易的事情)。这同样适用于SSH中使用的加密和验证方法。

从积极的方面来看,如果所使用的加密方法是CBC模式(具有底层安全块密码)或流密码(该数据具有随机或伪随机底座),那么验证后加密方法是安全的,。因此,虽然我们展示SSL的通用安全性被破坏,但使​​用上述加密模式的协议的当前实际实施是安全的。


虽然在这里已经有很多答案,但我想强烈主张AGAINST MAC-then-encrypt。我完全同意托马斯的答案的前半部分,但完全不同意下半场。密文是整个密文(包括IV等),这就是必须的MAC。这是被授予的。

但是,如果您以简单的方式进行MAC加密,那么您完全容易受到padding-oracle攻击。通过“直接的方式”,我的意思是你称之为“解密”功能,然后是“mac验证”。但是,如果在解密函数中出现错误,则会立即返回,作为填充错误。你现在已经有了一个完整的填充甲骨文攻击,你已经死了。您现在可以破解API并仅给出单个错误消息,但返回错误所需的时间必须相同,无论是MAC错误还是填充错误。如果您认为这很容易,那么请查看SSL上的Lucky13攻击。它确实非常非常困难(并且比仅仅对所有密文进行MAC处理都要困难得多)。

Schneier和Ferguson提出的MAC加密算法根本没有正式的基础。认证加密的定义是通过加密 – 然后MAC来实现的,而不是通过MAC加密来实现的。此外,MAC-then-encrypt的大多数实现实际上完全容易受到填充Oracle攻击的影响,所以在实践中实际上被破坏了。不要这样做!

说了以上所有内容,我的建议是不使用任何这些。你今天应该使用GCM或CCM(GCM要快得多,所以只要你确定你的IV不会重复使用它)。结合认证加密方案,只需一次API调用,现在您不会遇到麻烦。

添加评论

友情链接:蝴蝶教程