我们应该先进行MAC然后加密还是对MAC进行加密？

#1 楼

我假设您实际上比我更了解所有这些。无论如何，本文巧妙地总结了所有这些方法以及它们提供或不提供的安全级别。按照我的理解，我将用英语而不是数学符号来解释它。



加密-MAC- >提供密文的完整性。假设MAC共享密钥没有受到损害，我们应该能够推断出给定的密文是确实是真实的还是已经伪造的；例如，在公开密钥加密中，任何人都可以向您发送消息。 EtM确保您只读取有效的消息。
纯文本完整性。
如果密码方案具有可扩展性，则不必担心，因为MAC会过滤掉无效的密码文本。
MAC不提供明文中的任何信息，因为假设密码的输出是随机的，则MAC也是如此。换句话说，从明文到MAC，我们没有任何结构。



MAC-then-Encrypt：


在密文上不提供任何完整性，因为在解密消息之前，我们是不知道的，它是否确实是真实的或欺骗性的。
纯文本完整性。可以将消息更改为看起来有效并具有有效的MAC。当然，这是一个理论上的观点，因为从实践上讲，MAC机密应该提供保护。
在这里，MAC也不能在明文上提供任何信息，因为它是加密的。



Encrypt-and-MAC：


再次没有密文完整性，因为MAC是针对明文的。这就打开了对密码进行某些选择的密文攻击的大门，如“破解并证明修复SSH认证的加密方案：第4部分：加密然后加密和MAC范式的案例研究”第4部分所示。明文的完整性可以得到验证
如果密码方案是可延展的，则可以很好地更改密文的内容，但是在解密时，我们应该发现明文是无效的。当然，到那时为止，解密过程中可以利用的任何实现错误都已经存在。
可能会泄露有关MAC中明文的信息。理论上当然可以，但是不理想。如果重复了纯文本消息，并且MACed数据不包含计数器（在SSH 2协议中，但仅作为32位计数器，则会发生这种情况，因此，在溢出之前，请务必小心地重新设置密钥）。简而言之，Encrypt-then-MAC是最理想的方案。对密文的任何修改，如果它们也没有有效的MAC，则可以在解密之前将其过滤掉，从而防止对实现的任何攻击。 MAC也不能用于推断有关纯文本的任何内容。 MAC-then-Encrypt和Encrypt-and-MAC都提供不同级别的安全性，但不能提供Encrypt-then-MAC提供的完整安全性。

#2 楼

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

Encrypt-then-MAC是大多数研究人员推荐的模式。通常，它可以更轻松地证明加密部分的安全性（由于使用了MAC，解密引擎无法获得无效的密文；这可以对选定的密文攻击提供自动保护），还可以避免来自MAC的机密性问题（由于MAC对加密的文本进行操作，因此无论其质量如何，它都无法显示有关纯文本的任何内容）。请注意，已在本领域应用到ASP.NET的padding oracle攻击是选择的密文攻击。 then-encrypt（或MAC-and-encrypt）是“自然”的顺序，那么，那么then-en-MAC过于复杂。加密-然后-MAC的痛点是，您必须注意自己的MAC：不要忘记初始化向量，或者（如果协议允许算法灵活性）加密算法的唯一标识符；否则，攻击者可能会改变其中之一，从而导致MAC无法检测到的纯文本更改。为了证明他们的观点，Ferguson和Schneier描述了对IPsec实例的攻击，在该实例中，加密然后MAC没有正确完成。

因此，从理论上讲，加密然后MAC更好，也很难正确。

#3 楼

Hugo Krawczyk发表了一篇题为《保护通信的加密和身份验证顺序》（或：SSL的安全性如何？）的论文。
它确定了将身份验证（MAC）与加密结合起来的三种类型： IPsec中使用的先加密然后认证（EtA）；
SSL中使用的先加密然后认证（AtE）；
SSH中使用的先加密然后认证（E＆A）。

证明EtA是一种安全的使用方式，除非加密方法是处于CBC模式或流密码，否则AtE和E＆A都将受到攻击。我通过用粗体字强调了重要部分：

我们研究在构建“安全通道”以保护不安全网络上的通信时，如何一般地组成对称加密和身份验证的问题。我们表明，旨在与安全加密（针对选定的纯文本攻击）和安全MAC的任意组合一起使用的任何安全通道协议都必须使用crypto-then-authenticate方法。我们通过证明构成加密和身份验证的其他常见方法（包括SSL中使用的authenticate-then-encrypt方法）并不普遍安全来证明这一点。我们以一个提供（Shannon）完美保密性的加密功能为例，但是在authenticate-then-encrypt方法下与任何MAC功能结合使用时，会产生一个完全不安全的协议（例如，找到受密码保护的传输密码或信用卡号）对于主动攻击者而言，这样的协议变得容易。 SSH中使用的加密和认证方法也是如此。
从积极的方面来看，如果所使用的加密方法是CBC模式（具有基础安全块密码）或流密码（使用随机或伪随机填充对数据进行异或），则Authenticate-then-encrypt方法是安全的。 。因此，尽管我们证明了SSL的通用安全性已被破坏，但是使用上述加密模式的协议的当前实际实现是安全的。

#4 楼

尽管这里已经有很多答案，但我还是强烈建议再次反对MAC-then-encrypt。我完全同意托马斯回答的上半部分，但完全不同意后半部分。密文是整个密文（包括IV等），这是必须MAC的内容。这是可以实现的。通过“直截了当的方式”，我的意思是，您称为“解密”功能，然后称为“ mac验证”。但是，如果在解密函数中出现错误，则立即将其作为填充错误返回。现在，您刚刚获得了一次完整的填充oracle攻击，您已经死了。现在，您可以修改API并仅给出一条错误消息，但是无论是MAC错误还是填充错误，返回错误所需的时间必须相同。如果您认为这很容易，请查看针对SSL的Lucky13攻击。这确实真的非常困难（而且不仅仅将所有密文都进行MAC传输也要困难得多）。经过身份验证的加密的定义由“加密然后MAC”来满足，而“ MAC然后没有加密”则不被满足。此外，MAC-then-encrypt的大多数实现实际上完全容易遭受填充oracle攻击，因此实际上在实践中被破坏了。不要这样做！

以上已经说了所有，我的建议是不要使用其中任何一个。您今天应该使用GCM或CCM（GCM速度要快得多，因此，只要您确定IV不会重复，就可以使用它）。结合了身份验证加密方案和一个API调用，现在您将不会遇到麻烦。

#5 楼

Moxie Marlinspike在他的文章http://www.thoughtcrime.org/blog/the-cryptographic-doom-principle/厄运原理中称其为：


如果必须执行任何加密操作在验证收到的消息上的MAC之前进行操作，将不可避免地导致
毁灭。


他还演示了两次攻击，这可能是因为在检查MAC之前尝试解密的方法。

总结：“先加密然后进行身份验证”是解决方法。

#6 楼

我认为Encrypt-then-MAC不能提供纯文本完整性，而只能提供密文完整性。如果密文上的MAC正常，但我们使用错误的密钥解密（出于某种原因），则接收方将收到发送方未发送且未提供担保的明文。如果发生这种情况，那就是违反了纯文本完整性。在检查MAC完全正确之后，对密文执行的其他处理/解码。这是Encrypt-then-MAC的一个比较脆弱的方面，也是Ferguson和Schneier提倡反对Encrypt-then-MAC的原因之一。

#7 楼

真正重要的是，不是加密和mac。您可以辩论另外两个，但至少在理论上都是合理的-一个实际上可能比另一个更好。但是，“加密和MAC”由于一个非常简单的原因而破裂：MAC并不是要保留明文的秘密。

MAC是基于明文的。身份验证的目的不是掩盖明文。因此，MAC提供了一些有关用于创建明文的明文的信息。如果我们有一个9位数字的明文和一个1位的校验和，并以加密的前9位数字发送它，但没有校验和，则校验和将帮助我了解有关明文的前9位数字的知识。如果我能以某种方式找出九位数中的八位数，则可以使用校验和找出最后一位是什么。该校验和可能还有很多其他事情，破坏了前九位数字的完整性。否则，不管怎么说，你很好。

#8 楼

MAC没有属性，该属性规定不应泄露有关输入的信息。因此，您应该先加密消息，然后再应用MAC。这样，即使MAC泄漏了信息，泄漏的也是密文。

#9 楼

除了许多其他答案提到的先加密然后再加密（MAC）的安全性优势之外，还有性能优势。首先在接收端检查MAC，可以拒绝伪造的邮件，而无需进行解密工作。伯恩斯坦（Bernstein）在http://cr.yp.to/snuffle/design.pdf中提到了这一点（在“流应独立于明文吗？”部分中）。

#10 楼

如果您看一下Moses Liskov，Ronald L.Rivest和David Wagner撰写的论文“可调整的块密码”，该论文发表在“加密技术的进展-加密2002，论文集” 2442，第4.3节“可调整的认证加密（TAE）”中，则MAC计算纯文本，附加到纯文本，并与纯文本一起加密。然后，他们提供了定理3的证明“如果E是安全的可调整块密码，则在TAE模式下使用的E将不可伪造且是伪随机的”。

#11 楼

为了提供消息完整性，使用了哈希或消息身份验证功能（MAC）。有时，加密和完整性可以一起使用，例如：


加密-然后-MAC：提供密文完整性，但不提供纯文本完整性， ：提供纯文本完整性，但不提供密文完整性。
加密和MAC：提供纯文本完整性，但不提供
密文完整性。
这是最安全的模式，因为可以使用有效的MAC代码在解密之前过滤出密文的所有更改，从而保护消息免受任何修改攻击。但是，加密和MAC的组合，例如Galois / Counter Mode（GCM）：将加密的计数器模式与Galois身份验证模式结合，或Counter with Cipher Block Chaining（CBC）-MAC（CCM）：将CBC-MAC与出于安全考虑，首选
加密的计数器模式。

#12 楼

在许多应用程序中，仅部分数据（m）被加密，而某些所谓的附加身份验证数据（AAD，通常包括一些随机数的标头数据）a仅经过身份验证，但未加密。

这是我的论点：使用AAD时，Authentication-then-Encryption比Encryption-then-Authentication提供了对AAD的另一层保护，因此有人可能会认为在某些用法中它可能更安全。 。

使用AAD a时，如果我们使用Encryption-then-Authentication，则将得到：

E（m）+ A（a + E（m））

for scheme，这意味着我们首先加密m，然后将其与a串联，然后对结果进行加密。请注意，a是如何仅由一层加密操作（即MAC操作A）保护的。 + A（a + m））

，这意味着我们首先加密级联的a和m，然后将生成的MAC代码与m进行级联，然后进行加密。请注意，a受到A和E两层加密操作的有效保护。

现在假定身份验证方法已被破坏，并且加密没有被破解，由于某些MAC算法，这并不是那么牵强（例如HMAC-MD5）确实被发现很弱，那么当使用Encryption-then-Authentication时，a将完全受到篡改。对于身份验证然后加密，不能说相同。



2016年9月27日更新：

我同意某些多次使用密码并不总是可以提高安全性，因此我撤回了该声明。但这实际上与我的主要目的无关，因为AtE提供了额外的安全层，因为在这些A / E方案中我们没有两次将相同的密码应用于相同的数据。

#13 楼

阅读所有这些内容后，我认为最好的解决方案是：

MAC-then-Encrypt-then-MAC

同时提供纯文本和密文的保证。

我完全同意，两者都是重要的：


如果您的纯文本不是结构化的，并且不允许在没有MAC的情况下确认其完整性，MAC-then-Encrypt
出于其他答案中提供的原因，先加密然后再添加MAC，尤其是避免解密不良数据