加密，签名，验证和解密加密

Question

我正在使用win32加密加密来加密并签署消息，然后验证签名并解密消息。

每件事都很好，直到我意识到CryptSignHash（）将从我的数据中签署计算出的哈希并生成签名。意思是，在另一侧（收件人侧），收件人将需要接收签名和密码（分开），这是我不想要的。

我想将签名与一个单个容器中的加密消息结合在一起，然后将其全部发送在一起，然后收件人能够验证和解密。

我使用API​​的顺序如下：

CryptAcquireContext()
CryptGenKey()
CryptExportKey()
CryptImportKey()
CryptEncrypt()
CryptCreateHash()
CryptHashData()
CryptSignHash()
CryptVerifySignature()
CryptDecrypt()

有没有使用证书存储的方法？

Answer 1

我认为您从根本上误解了这个过程应该如何工作。在您呈现的特定情况下（将哈希签名和加密消息发送给收件人）也需要包括您的公钥。

收件人将使用您的公钥来解密哈希签名，并验证它是否与加密消息的哈希相匹配。这就是收件人可以用这些信息来完成的，即验证加密消息是否有效，并源自您。

收件人将无法解密加密的消息，因为他没有用于加密的私钥！

通常，该消息应使用对称密钥算法（例如AES）加密。签名和验证是通过不对称的私人/公钥算法（例如RSA）完成的。

例如，您的方案可以按以下方式扩展：

1. 您将消息加密AES，但您的收件人需要密码来解密该消息，并且您需要以安全的方式将其发送给他。
2. 您的收件人需要向您发送他的公共RSA密钥。
3. 您将使用收件人的公共RSA密钥加密AES密码。
4. 您可以使用私有RSA密钥签署加密消息和加密AES密码。
5. 您将公共RSA密钥与已签名的加密消息，已签名的加密AES密码及其各自的加密签名一起发送给收件人。
6. 您的收件人现在能够使用您发送的公共RSA密钥验证这两个签名。
7. 如果签名有效，则您的收件人可以使用其私有RSA密钥解密加密的AES密码。
8. 最后，您的收件人能够使用现在解密的AES密码解密加密的消息。

如您所见，这是一个相当复杂的过程。可以以某种方式简化较短的消息。如果消息短于RSA密钥的长度，则可以跳过AES加密并使用收件人的公共RSA密钥来加密整个消息，但是在现实世界中，情况通常不是这种情况。