PKI Encrypted hash vs Signing

Question

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?

Answer 1

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.

Answer 2

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.