I have a confusion in a concept under cryptography context. What is the major difference between an encrypted hash and digital signed hash?

I have used PKI Encryption i.e. public / private key based encryption.

I calculated the hash and encrypted it with the private key of sender. Now, the receiver can unlock the hash with the public key of sender. Hence it proves the authenticity of the data. Now receiver can regenerate the hash and match with the decrypted one and if matches then it proves the data integrity.

Similarly, the signature is created by an hash and same is encrypted; and it is done by private key of sender. Now the receiver can verify the signature by public key of sender. It proves both authenticity and integrity.

I have used both in my case (that i am developing). I think I am using signature / hash as an extra element and only one of them will suffice.

Or is their any benefit of using both or any difference?

  • $\begingroup$ This came up yesterday on StackOverflow as well; that question has been deleted however. $\endgroup$
    – Maarten Bodewes
    Apr 22 '20 at 11:00

The difference between encrypted hash and a digital signed one is twofold:

  1. the key to be used for signature generation is the private key, so technically it is not encryption;
  2. the padding scheme is different for both situations.

The use of the wrong key is already enough to not talk about encryption as explained in my Q/A here.

In the case of PKCS#1 v1.5, both encryption and signature generation are often referred to by the same name. However, both use a rather different scheme for the padding of the content (the plaintext message for encryption and the hash for signature generation). For RSA v1.5, RSA encryption is called RSAES-PKCS-v1_5 and uses the EME-PKCS1-v1_5 encoding scheme. Signature generation is called RSASSA-PKCS-v1_5 and it uses the EMSA-PKCS1-v1_5 encoding method. Note that these names have only been introduced in version 2.0 from the specification.

The main issue is that the padding for encryption was designed to add a random component to the padding. This is required because otherwise identical messages would result in identical ciphertext, leaking information to anybody seeing both ciphertext. As it is random padding, it cannot be validated. On the other hand, signature generation uses a known padding which can be validated. This is important because you would want the unpadding to fail when verifying the signature in case it has been tampered with.

So using the wrong padding scheme means that the security premises of the RSA mode and padding are not valid anymore. This is one more reason why signature generation should not be thought of as encryption of a hash value. Both use the RSA problem to be secure. Practically speaking only the modular exponentiation is identical for both.

  • $\begingroup$ My question is a bit different then the answer of yours. I want to know that encrypting the hash with one key and send to the receiver and he/she decrypts it with the other key. Is this same as signing a content? does it proves both authenticity and integrity of data? if yes than whats the need of Signature? ( in java terms: the signature function with SHA256withRSA algorithm $\endgroup$
    – user79366
    Apr 22 '20 at 15:51
  • $\begingroup$ That's exactly what I was trying to explain. It is not. What part of the answer are you not getting? Or are you still hoping for a positive answer? As indicated, Signature will use a different padding. Most of the time Cipher will not even accept a private key as input parameter for encryption, and - as explained in the other answer and here - if it did the algorithm may not be secure. $\endgroup$
    – Maarten Bodewes
    Apr 22 '20 at 15:52
  • $\begingroup$ So it means encrypting a hash is better approach for signing the content in my case? $\endgroup$
    – user79366
    Apr 22 '20 at 16:00
  • $\begingroup$ However, encryption is private key is restricted in IBM JCE. SUNJCE and BouncyCastle allows this method of encryption. $\endgroup$
    – user79366
    Apr 22 '20 at 16:02

TLDR: No encryption with a private key. To sign a message in Java, Signature is appropriate.

Encryption is not performed with the help of a private key. Hence in the first option of the question

calculated the hash and encrypted it with the private key of sender

and in the second option

signature is created by an hash and same is encrypted, it is done by private key of sender

both are terminology errors. In either case, what's described is not encryption. At least the intent is signature production. I see no fundamental difference between these two actions as detailed in the question, when assuming that in the second "same" refers to the hash (and disregarding the question's title and first paragraph). If on the other hand we read "same" as "similarly to the first option", then there often is a security difference. That's the reading in this other answer.

Encrypting a hash is possible, but is never done with a private key used as such. If something on that tune is attempted, that's not encryption, that's signature, or meaningless, or impossible. In the case of RSA (but not many other asymmetric cryptosystems), it is possible and meaningful to compute $(H(M))^d\bmod N$ where $(N,d)$ is the private key, and the outcome is a signature of $M$, of the appendix kind. It is more or less secure¹. Proper RSA signature schemes differ from that by the choice of $H$, which becomes a signature padding, and may incorporate a random input and/or recoverable information conveying some or all of the message.

Encrypting a hash can only be meaningfully performed using (1a) symmetric encryption with a secret key, or (1b) asymmetric encryption with a public key. There's a major difference with (2) signing with a private key:

  • Anyone with the trusted public key can verify the signature of (2) and that can prove integrity and origin of the signed message, but not in the other cases.
  • The outcome of (1a) can be verified only with the secret key, and can at best prove to a party holding the private key that the message was approved by another party holding the secret key. Thought with many encryption schemes in common use (including stream ciphers), that goal is missed and forgery is easy.
  • The outcome of (1b) can be decrypted by the holder of the private key matching the public key, but its virtue is different: proving that whoever produced that cryptogram knew the hash of the message, or/and conveying that hash to the holder of the private key, without revealing the message or its hash to another party (this is not a commonly pursued goal, and it has no name).

¹ Security depends on the width of $H$ and attack model. In particular, a collision-resistant hash such as SHA-224 or even SHA-256 is not suitable in an attack model where the adversary can obtain the signature of chosen messages: forgeries may be possible, see this.

  • $\begingroup$ My project requires digital signing of content.. So whats the best approach? Encrypting hash with one key and decrypting with the other? or generating a signature with Signature function of java using SHA256withRSA? $\endgroup$
    – user79366
    Apr 22 '20 at 15:52
  • 1
    $\begingroup$ The latter, you use Signature to create signatures. $\endgroup$
    – Maarten Bodewes
    Apr 22 '20 at 15:53
  • $\begingroup$ as communicated in the answer Encrypting a hash with private key is meaningless or signature? $\endgroup$
    – user79366
    Apr 22 '20 at 16:06
  • $\begingroup$ So in a nutshell, the signature function has different padding scheme then encryption of hash. However, signature padding is much stronger as it uses random generation. So signature shall be used instead of encryption of hash? $\endgroup$
    – user79366
    Apr 22 '20 at 16:07
  • $\begingroup$ I think you should read the answers more carefully before asking additional questions. $\endgroup$
    – Maarten Bodewes
    Apr 22 '20 at 16:17

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.