协议设计

2018-03-18

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

大多数情况下,当某些数据必须加密时,还必须使用MAC来加以保护,因为加密只能保护被动攻击者。有一些漂亮的加密模式,其中包括一个MAC(EAX,GCM …),但假设我们正在做旧式加密,所以我们有一个独立的加密方法(例如带有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-然后加密: 不对密文提供任何完整性,因为我们无法知道,直到我们解密消息,无论它是真的还是伪造的。 明文完整性。...

Read More