So user A has a huge text that needs to be encrypted and send to user B. User A creates a symmetric key for AES and encrypts the messages with that AES key. Then, user A encrypts the AES key with the public RSA key of user B and sends both to user B. User B decrypts the AES key with the private RSA key and then decrypts the text with the decrypted AES key. Now, how should user A sign the message / AES key in order user B to verify that the message was actually sent from user A. If user A signs the encrypted AES key, would it be possible for user B to decrypt the signed AES key with the public RSA key of user A and then decrypt the AES key with his private RSA key?

2 Answers 2


Signing using RSA is done by first applying a cryptographic hash and then "encrypting" it with the private key of the sender (i.e. A). "Decrypting" the signature using the public key of the sender thus results only in the hash value, but not in the AES key. Since the hash function is one-way the original input (i.e. the AES key) can not be derived from the hash value.

Validating the signature by the recipient is instead done by first re-computing the hash value of the input (which is known after decryption) and then comparing this against the hash value returned by "decrypting" the signature with the public key of the sender. If they match the signature is valid.


If user A and user B know the same password used for AES (without sending it through the network) then it is enough add a checksum at the end of the message and encrypt [message + checksum]. The man in the middle can not decrypt the message without knowing the key. If he tries to send his own data encrypted with wrong key (he does not know the right key) then user B would receive a bunch of nonsense after trying to decrypt it with proper key and the checksum will obviously be wrong which confirms the message has been forged. On the other hand if the AES key is sent through unsafe connection it makes encrypting the message meaningless.

To create a shared key without agreeing on it beforehand and without it leaking through unsafe connection during exchange one could use Diffie-Hellman handshake. Both users create a pair of private and public key for Diffie-Hellman handshake. The public keys are signed and sent through unsecure connection. Then a shared secret is generated (look Diffie-Hellman handshake in wikipedie for more info). Basically even if everything sent through the connection is visible to man in the middle he would not be able to recover the shared secret unless he participated in it's creation. And the signatures will make sure he does not forge the initial handshake.

Another way to create a secure connection is RSA + signature. User A encrypts the message with the public key from user B and signs it (before or after encrypting, does not matter. signing after encryption would allow man in the middle to verify that A is the aughtor which is not a secret and allow user B to drop the forged message with wrong signature without having to decrypt it first). Then [message + signature + checksum] is sent to user B. The checksum must be added before encrypting. User B verifies the signature, decrypts the message and verifies the checksum.

From what you said I would dare to imply that you have a misunderstanding of how signature works. Signature does not change the message. It creates an additional block of data (the signature). Then you send message + signature to user B. The user B combines your public key, the message itself and the signature to verify.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .