在签名加密标志（电子邮件）设置中是否可以接受同时使用相同证书进行签名操作，还是应该选择两个单独的证书？ 加密操作使用预期的收件人公共证书执行。
祝你好运， 布赖恩
答案 0 :(得分：0)
首先，在直接回答您的问题之前，我需要谈谈 Sign-then-encrypt与Encrypt-then-sign ，这是一个非常常见的加密问题，而且不常见正确回答。我的意思是没有一个简单的答案，正确的答案取决于你遇到的情况。
首先，请注意，当双方之间进行实时交换时，Encrypt-then-sign可以防止基于私钥和加密时间之间的相关性的攻击。这是因为在检查签名之前进行解密时，中间人攻击者可以让您解密他想要的任何内容。然后，他可以测量您解密的延迟，因为您的响应将在您解密他修改的内容之后（响应通常是“错误”，因为在解密密文之后，您将看到内容没有正确签名）。因此，对于具有实时交换的双方之间的协议，主要规则是在检查签名之前永远不会解密。为了防止这种时间侧信道攻击，奥克兰大学的P. Gutmann在2013年末提出了drafted RFC。这个RFC开始说：本文档描述了一种协商使用加密的方法 - 然后-MAC安全机制取代TLS'/ DTLS'现有的MAC-then-encrypt，这已经成为多年来许多安全漏洞的主题。
现在，当你进行异步交换时，比如在SMTP之上使用PGP或S / MIME，就不能进行这样的定时攻击。所以，你应该更喜欢Sign-then-encrypt，这是由你在评论中讨论的线程中的DW 解释的其他原因：https://crypto.stackexchange.com/questions/5458/should-we-sign-then-encrypt-or-encrypt-then-sign（这主要是为了避免密文由别人而不是发射器。）
那么，让我们回答你的问题：
在签名加密标志（电子邮件）设置中是否可以接受同时使用相同证书进行签名操作，还是应该选择两个单独的证书？加密操作使用预期的收件人公共证书执行。
你说这是一个电子邮件上下文。因此，不应该有可能进行定时侧信道攻击。因此，您应该只对Sign-then-encrypt进行加密。
但是既然你想要Sign-then-encrypt-then-sign，我认为你想要避免因任何其他原因引起的旁道攻击。
因此，对两个签名操作使用相同的证书（和私钥）都不会影响您的交易所的安全级别：您可以理解，最后一次签名操作用于确保没有人会解密修改后的内容并测量延迟，并且在此之前的第一个符号是检查密码文本是否无法由无法解密的人签名。因此，这两个操作都没有链接，因此对两个操作使用或不使用相同的证书都不会改变任何内容。