我们应该签名然后加密，还是加密然后签名？

#1 楼

假设您要询问公用密钥签名+公用密钥加密：

简短答案：我建议先签名然后加密，但将收件人的名字放在消息的前面。

理由：这样做的原因是要击败一些微妙的攻击。这些攻击不一定在所有情况下都存在问题，但是最好尽可能地加强这种方法。完整的说明将比此处提供的空间更多，但是请参见下面的推理草图。

有关是否先签名还是先加密的详细分析，以下是一个很好的资源： S / MIME，PKCS＃7，MOSS，PEM，PGP和XML中的缺陷签名和加密。

我不建议先加密再签名。它可以工作，但是在某些情况下会有一些细微的陷阱，因为签名不能证明发送者知道明文的上下文。例如，假设Alice的SSH客户端发送消息“亲爱的SSH服务器，请将我的公钥附加到/root/.ssh/authorized_keys －您可以知道我已被授权，因为我知道root密码是lk23jas0”（然后加密（使用Alice的公钥签名），并且如果根密码正确，则SSH服务器将对其进行操作。然后，Eve可以进行窃听，捕获此消息，剥离Alice的签名，使用Eve自己的密钥对密文进行签名，然后将其发送到SSH服务器，即使Eve不知道root密码也获得了根级别的访问权限。

评论

---

$ \ begingroup $
@RickyDemer，我不知道。不管怎么说，这是我第一次听说SIM-NME。 IND-CCA2安全性是公钥加密方案的标准安全性概念，旨在防止选择的密文攻击。有关IND-CCA2安全性的定义，请参阅任何有关现代（理论）加密的优秀教科书...，或者，如果您感到胆怯，请参阅Wikipedia。
$ \ endgroup $
– D.W.
2012年11月24日，1：15

---

$ \ begingroup $
@RickyDemer，到目前为止，我从未听说过这种“边界CCA2不可恶意攻击”；据我所知，它的实用程度大约为零。任何人都可以发明一些疯狂的安全性概念，但这并没有意义。我坚持我所有的建议和声明。老实说，我不确定您要发表评论的地方。如果您有问题，则可能想在一个单独的问题中提出来-我不确定我是否理解您的意思，但似乎有点切线。
$ \ endgroup $
– D.W.
2012年11月24日，下午2:21

---

$ \ begingroup $
@RickyDemer，就您的注释为何设置有趣的格式而言，似乎是因为您正在注释文本中手动插入LaTeX间距命令（例如\;，\ hspace，手动换行符等）。建议您避免这样做，如果您想避免注释的有趣格式。我认为这仍然是有效的建议。
$ \ endgroup $
– D.W.
2012年11月24日在2:21

---

$ \ begingroup $
它有什么作用？作为鲍勃，我收到消息，将其解密，然后给我的消息是，该消息带有我的身份？
$ \ endgroup $
–krzychu
16年11月8日在7:51

---

$ \ begingroup $
@ M-elman我想在名称前加上一个原因是，恶意的Bob可以使用Charlie的公钥加密完全相同的消息+ Alice的签名，从而冒充Alice，并欺骗Charlie相信Alice向他发送了信息。
$ \ endgroup $
– bkjvbx
17年2月28日在14:40

---

#2 楼

应该签名然后加密，还是先加密然后签名？
...
（对称密钥）MAC然后加密的相同问题是否适用于密钥）签名然后加密？


是。从安全工程的角度来看，如果您先进行mac-then-encrypt或sign-then-encrypt，则在解密过程中将使用未经身份验证的数据。一篇非常相关的论文是Krawczyk的“用于保护通信的加密和身份验证顺序”。但是，正如SSL / TLS人士反复表明的那样，它在实践中是有问题的。

D.W.引用了另一篇重要论文。和Sashank：Don Davis的S / MIME，PKCS＃7，MOSS，PEM，PGP和XML中的缺陷符号和加密。

我认为符号vs mac的原始意义不那么重要。在所有条件都相同的情况下（例如安全级别，密钥管理和绑定），效率是最高标准之一。显然，对称密码比非对称密码更有效。


数据身份验证与实体身份验证是不同的属性。您可以使用MAC进行数据身份验证，也可以使用签名进行实体身份验证。

但是，对于我来说，要进行数据身份验证还是实体身份验证并不清楚。您在（b）中声明的安全目标是请求数据身份验证（MAC），而不是实体身份验证（签名）。这是说他签名然后加密然后是Macs的另一种方式。如果MAC正确，则他解密并验证签名以验证谁发送了消息。如果MAC错误，那么他就不用费心解密-他只会返回FAIL。

如果您查看Sashank提供的链接，CodesInChaos的修复实际上是对5.2节的Sign / Encrypt / Sign。纸。 D.W的解决方案是有效地命名第5.1节中的修复。


还有第三种选择尚不明显。它将用于大容量加密的Encrypt-Then-MAC与公用密钥密码相结合。它的IND-CCA2也称为D.W.建议您努力。

该选项是“集成加密方案”。我知道其中有两个。第一个是Shoup的ECIES，它可以运行椭圆曲线。第二个是Abdalla，Bellare和Rogaway的DLIES，它们对整数进行运算。 Crypto ++同时提供ECIES和DLIES。 Bouncy Castle提供ECIES。

ECIES和DLIES结合了密钥封装机制（KEM）和数据封装机制（DEM）。该系统从一个共同的秘密中独立地获得对称密码密钥和MAC密钥。首先使用对称密码对数据进行加密，然后在身份验证方案下对密码文本进行MAC加密。最后，公用密钥在公用/专用密钥对的公用部分下被加密。加密函数的输出是元组{K,C,T}，其中K是加密的公共密钥，C是密文，而T是身份验证标签。 。这些方案使用的流密码对明文与KDF的输出进行XOR。这里的设计选择是避免带有填充的分组密码。您可以在流模式（例如AES / CTR）中使用分组密码来达到相同效果。然后使用KDF消化共享机密。密钥协议功能使用接收者的静态公共密钥和临时密钥对。临时密钥对由执行加密的人员创建。执行解密的人员使用其公共密钥来执行密钥交换的另一半，以得到“公共机密”。

KEM和DEM避免了填充，因此无需考虑填充预言。这就是为什么使用KDF来消化KEM下的大型“公共秘密”的原因。省略填充可以大大简化系统的安全性证明。

#3 楼

这取决于您的要求，


如果您先签名然后加密，则只有接收者可以解密然后
验证。
如果先加密再签名，那么任何人都可以验证真实性，只有接收者可以解密它。加密签名，无法回忆起讨论此问题的论文

还有另一篇很受欢迎的论文，并且对此问题进行了一般讨论

#4 楼

如何使用三个不同的密钥：$ S_K1，C_K $和$ S_K2 $。$ br_ $ S_K1 $用于签名明文消息。加密在（1）中生成的签名和明文的连接。
最后$ S_K2 $用于对（2）的加密输出进行签名。然后，要发送的消息是（2）的输出与（3）的输出的串联。

我认为这是Thunderbird的milimail扩展完成的。

#5 楼

对于身份验证加密，最佳实践是“先加密然后再进行MAC”。加密，然后MAC始终是AE安全的（假设加密是CPA安全的，而MAC是安全的），但是MAC然后Encrypt并不总是安全的。 NIST AES-GCM AEAD方案基于“先加密，然后进行MAC”。 SSL填充攻击利用了其AE基于“ MAC然后加密”的事实。同样，当您先进行“ MAC然后加密”操作时，由于MAC的增加，加密的数据熵降低了，这取决于数据，并且不增加熵。因此，对于AEAD，最好先使用加密，然后再使用MAC。不过，您正在询问数字签名，尽管我没有找到安全性证明，但直觉上我认为应该使用相同的做法（即先加密再签名）。

#6 楼

这些方法之间的唯一区别与隐藏有关发件人的信息有关。如果您不希望攻击者知道签名者是谁，则需要签名然后加密。在其他情况下，没关系。