在他的论文Defective Sign & Encrypt in S/MIME, PKCS#7, MOSS, PEM, PGP, and XML中,Don Davis 经常谈论这个术语
天真的签名和加密
读完这篇论文后,我不能 100% 确定这到底是什么意思。
他是否意味着(主流)用户认为签名和加密是可接受的安全实践的可能习惯?(尽管无法保证谁加密了您的消息)
在他的论文Defective Sign & Encrypt in S/MIME, PKCS#7, MOSS, PEM, PGP, and XML中,Don Davis 经常谈论这个术语
天真的签名和加密
读完这篇论文后,我不能 100% 确定这到底是什么意思。
他是否意味着(主流)用户认为签名和加密是可接受的安全实践的可能习惯?(尽管无法保证谁加密了您的消息)
作者似乎可以互换使用“简单”和“天真”。是的,他似乎指的是在传输之前对明文进行签名(使用发送者私钥)和加密(使用接收者公钥)的行为。
他认为这是幼稚的,因为第三方能够将发送者编写的预先存在的签名消息转发给接收者,并且接收者假设可以安全地信任它。
想象一下 Bob 和 Alice 试图安全通信的情况。Chuck 是他们俩都知道的不受信任的第三方。
您应该在密码学和安全行业的人员确定将签名和加密组合成经过身份验证的加密以允许您发送签名的秘密消息的正确顺序的上下文中阅读签名和加密方案。
天真的签名和加密是任何加密方案,其中消息由作者的私钥签名,然后以最简单、最明显的方式加密为收件人的公钥:
message = encrypt(recipient public key, sign(author private key, message))
如本文所述,这种简单的方案存在许多漏洞。
另一个幼稚的命令:“加密然后签名”也有一些漏洞。过去,密码学 API 用于公开签名和加密原语,而不是经过身份验证的加密原语,因此协议设计者和应用程序程序员总是不得不重新发明自己的组合机制,这通常归结为两种朴素排序和协议设计者和应用程序程序员结合这些原语的方式通常会导致意想不到的漏洞。
然后,非朴素签名和加密将是任何经过身份验证的加密方法,它将传统的签名和加密原语与将签名和加密操作相互链接的附加操作相结合,以避免朴素签名和加密的漏洞。这与从头开始设计以满足认证加密的设计标准的真正认证加密相反。
这种从传统签名和加密构建经过身份验证的加密的方法很诱人,因为如果做得正确,它允许您将任何签名算法与任何加密算法结合起来,并且当您从众所周知的、经过实战考验的原语开始时,它可能会使分析变得更容易,而不是而不是设计全新的密码。这种方法也有先例,PBKDF 和 HMAC 等高级操作是基于现有的散列原语构建的。