# Why do we need a digital signature?

First of all, I want to say that I'm totally new to cryptography. I searched on crypto stackexchange but couldn't find the answer to the following question.(probably because it's easy, but I still don't get it)

My question is based on this question. So a signature basically does the following: message $\rightarrow$ hash $\rightarrow$ Bob's private key $\rightarrow$ combine signature with message $\rightarrow$ send to Alice $\rightarrow$ Alice decrypts the signature using Bob's public key $\rightarrow$ compares the hash of the signature with the text in the message: Now the real question: Why not just encrypt the whole message with the private key of Bob send it to Alice and decrypt it with bobs public key? Because we can get Bob's public key from a CA and make sure we got the right public key, so if someone else sends the message we simply couldn't decrypt it.

• for RSA scheme, if we don't hash the message, it's not secure. Given $\sigma_0 = m_0^e, \sigma_1 = m_1^e$, one can forge a valid pair $(m_3,\sigma_3)$ where $m_3 =m_1 \cdot m_2, \sigma_3 = \sigma_0 \cdot \sigma_1$ Jun 17, 2017 at 19:55
• That's not really clear for me, as in the question: "I'm totally new to cryptography" @DiamondDuck Jun 17, 2017 at 20:05
• @DiamondDuck Couldn't a padding scheme prevent that attack without requiring the message to be hashed? Rick: what DiamondDuck is saying is that raw/textbook RSA (modular exponentiation) has the property that if an attacker multiplies two "signatures" then you get another signature for a different message. That would signify that the signature scheme is broken; an attacker should not be able to produce valid signatures. Jun 18, 2017 at 9:15

First an important point of terminology: the real question should be phrased "Why not just sign the whole message with the private key of Bob, send it to Alice, and verify it with Bob's public key?". Signature and encryption are very different things. We use "encryption" only when the goal is confidentiality; and encryption is performed with the public key of the receiver, rather than with the private key of the sender (as is the case for signature).

With that terminology issue set aside, what the question describes is the rough principle of signature with RSA, where the encryption operation can be carried with the private key instead of the public one. However that does not transpose to arbitrary asymmetric ciphers: their public and private key is often so different that there's no way to encrypt with the private key.

Further, there are security issues with what's proposed:

if someone else sends the message we simply couldn't decrypt it.

Not true. If an attacker prepares the message as a legitimate sender but a different key, the message could be decipherable, only most likely into gibberish. So at least we need a procedure to recognize real messages from gibberish, and that's not easy (it might be impossible if what's signed was already encrypted, which is common practice).

Also, an attacker is not restricted to applying a proposed protocol with a different key. S/he can alter or combine existing cryptograms, and that opens to attacks. That's a reason why secure RSA encryption and secure RSA signature differ by more than an exchange of the role of keys.

We usually sign a hash of the message, rather than the message, primarily because the signature schemes that we use can only directly sign small amounts of data (in the order of tens to a few hundreds bytes). A hash reduces an arbitrarily large message to a small size (32 or 64 bytes are common), that we can sign in a single chunk. Signing the hash is as secure as signing the message, because (for a good hash algorithm) we do not know how to make two different messages with the same hash (collision resistance). Without this hash trick, we could still sign, but we'd need to break the message into numbered pieces, and sign each piece individually. Signatures tends to be several times larger than what they can directly sign, and at least one of signature generation or verification is typically compute-intensive; thus hashing saves bandwidth and improves performance except for very small messages.

For many signature schemes, there's another reason: hashing the message is necessary for security. Otherwise, some property of the signature scheme would allow forgery: perhaps some few messages would have a trivial signature, or the signature of a message could be derived from the signature(s) of some related message(s). With addition of the hash step, messages allowing such attacks can not be exhibited, because (for a good hash algorithm) we do not know how to make a message with a particular hash value (preimage resistance), or more generally with a special property.

• Thankyou! I have one question, what do you mean with: "not the private key of the sender as signature is." Jun 17, 2017 at 20:36
• Note that there is such a thing as "signatures giving message recovery" that do include (part of) the message in the signature. These are mainly used to create smaller certificates such as those verified by a smart card. Usually - because of the security requirements - these also contain the hash in the signature though. And they are not used much, especially since Elliptic Curve cryptography is more secure for small signatures. Jun 18, 2017 at 9:13
• @Maarten Bodewes: last time I checked, my credit card used ISO 9796-2 (scheme 1), which implements message recovery.
– fgrieu
Jun 18, 2017 at 9:28
• ElGamal signature scheme without signing, for example, is weak to existential forgery Jun 18, 2017 at 15:19

Why not just encrypt the whole message with the private key of Bob send it to Alice and decrypt it with bobs public key?

Simply put, because that's harder. Encrypting with a public/private (aka asymmetric) key scheme is slower than a symmetric key encryption scheme.

You're right that encrypting the whole message would give the same security, but at a huge performance hit. It's much faster to encrypt a small hash.

Like fgrieu said, there are different implementations of asymmetric encryption. When Bob signs a message with his private key, Alice can use Bob's public key to verify Bob's identity. (This is accomplished by proving to Alice that Bob owns the corresponding private key without actually revealing it to her.) This does not encrypt the message in the true sense of the word since theoretically everyone has access to Bob's public key and can easily decipher the message.

If Bob wants to send a confidential, encrypted message to Alice, he must use her public key to encrypt it. In this scenario, only Alice (the owner of the private key) will be able to decipher it.

• I should mention that you can combine these two methodologies. Bob can sign a message with his private key (authentication) and encrypt with Alice's public key (encryption). Jun 18, 2017 at 14:42