encrypt,sign,verify, and decrypt CryptoAPI

Question

I'm using win32 cryptoAPIs to encrypt and sign a message then verify a signature and decrypt the message.

every thing worked fine until I realized that the cryptSignHash() will sign the calculated hash from my data and generate a signature. Meaning, on the other side (the recipient side) the recipient will need to receive the signature and the cipher msg (separated), which is something I don't want.

I want to combine the signature with the encrypted message in one single container and send it all together and then the recipient will be able to verify and decrypt it.

my order of using the APIs was as the following:

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

Is there a way without using the certificate stores?

Answer 1

I think you fundamentally misunderstood how this process is supposed to work. In your particular scenario that you presented (sending the hash signature and the encrypted message to your recipient) you will also need to include your public key as well.

The recipient will use your public key to decrypt the hash signature and verify if it matches the hash of the encrypted message. That is all the recipient can do with this information, namely verify that the encrypted message is valid and originates from you.

The recipient will not be able to decrypt the encrypted message because he doesn't have your private key that was used to encrypt it!

Usually the message should be encrypted with a symmetric key algorithm (such as AES). The signing and verifying is done with an asymmetric private/public key algorithm (such as RSA).

For example, your scenario could be expanded as follows:

1. You encrypt the message with AES but your recipient needs the password to decrypt it and you need to send it to him somehow in a secure way.
2. Your recipient needs to send you his public RSA key.
3. You encrypt the AES password with your recipient's public RSA key.
4. You sign both the encrypted message and the encrypted AES password with your private RSA key.
5. You send your public RSA key to your recipient along with the signed encrypted message, the signed encrypted AES password and their respective encrypted signatures.
6. Your recipient is now able to verify both signatures with your public RSA key that you sent him.
7. If the signatures are valid then your recipient can decrypt the encrypted AES password with his private RSA key.
8. Finally your recipient is able to decrypt the encrypted message with the now decrypted AES password.

As you can see this is a rather complicated process. It can be simplified somehow for shorter messages. If the message is shorter than the length of the RSA key then you can skip the AES encryption and use your recipient's public RSA key to encrypt the whole message but in real world this isn't usually the case.