Consider a normal PKI encryption flow - hash the plaintext, then encrypt the hash with the private key of the sender and then encrypt it with the public key of the recipient. All this is good - and I am good even with the decryption steps taken by the recipient.

I still don't understand how the recipient gets the plaintext from the hashed ciphertext. The recipient can easily 'decrypt the hashed plaintext'. But then what - all you are left with is a hashed plaintext. There is no way to un-hash it. How does the recipient retrieve the plain text message from the hashed message?

  • $\begingroup$ Is security.stackexchange.com/questions/124555/… helpful? $\endgroup$ – SamG101 Jan 20 '20 at 19:42
  • $\begingroup$ It's impossible to get plaint text from the hashed ciphertext. Show us the article where you read that. $\endgroup$ – mentallurg Jan 20 '20 at 20:44
  • $\begingroup$ It only partly helps - 'Adding in a hash to the process stops that kind of attack because you've also got to check what the hash pre-image of the modified ciphertext is," - I get this part. What I don't get is how does one retrieve plaintext once the hash is verified. Hashes are ONE WAY only - once hashed, a message cannot be unhashed. Cheers $\endgroup$ – user2736158 Jan 20 '20 at 21:35
  • $\begingroup$ @mentallurg - that's exactly my point. If you start with plaintext, one way hash it - then encrypt the hashed payload, how the heck do you ever get the plaintext payload back?? How would a recipient ever read the plaintext data after decryption? $\endgroup$ – user2736158 Jan 20 '20 at 21:47
  • 1
    $\begingroup$ If anyone tells you that something is "encrypted with a private key" you can be certain that they have some serious misconceptions about cryptography. $\endgroup$ – Maeher Jan 20 '20 at 22:26

Signature generation is not encryption with the private key. Still, the basic flow of what you describe is correct for signature generation. However, the verification step is where everything derails.

As indicated in the comments, it is impossible to reverse a cryptographic hash. However, for signature verification, it is assumed that the verifying party knows the signed message M. The verifying party can then re-calculate the hash and use that as input for the rest of the verification procedure. So if the verifying party doesn't have the message M then you simply need to send it together with the signature.

See for instance step 2 in RSA signature verification specified for the PSS signature scheme:


      M      message to be verified, an octet string

and then later:

 2. Let mHash = Hash(M), an octet string of length hLen.

The verification procedure may indeed involve retrieving the original hash and perform comparison. However, other signature verification functions such as the verification function of ECDSA may simply require the re-calculated hash as input for the verification function. So in that case the original message hash isn't even retrieved from the signature.

There are schemes that perform message recovery. A few of those schemes are outlined in ISO/IEC 9796-2: Digital signature schemes giving message recovery. However, they are not often used anymore. In that case the message itself - or at least part of it - is included with the hash, the message is still not retrieved from the hash.

Remember that signatures do not provide message confidentiality. If you also want to keep your data secret then you should encrypt the data and signature over the data.

  • $\begingroup$ Now - that makes some sense. Signature verification - I am okay with - compare the hashes. So - if I understand what you are saying - there is no way to get to the plaintext from the hashed message (which was part of my original question). You would need to actually send the plaintext message along with the hashed message. That's all I was trying to confirm. Thanks $\endgroup$ – user2736158 Jan 21 '20 at 15:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.