-1

Digital signature provides authentication by encrypting the text with the sender's private key and decrypting the text with the sender's public key. But how do we add integrity to it so that the text sent by the sender does not vary at the receiving end?

radhika
  • 3
  • 1
  • 3
  • You use the words `data` and `text`. Are you referring to two different things or the same things? – Neil Smithline Apr 10 '18 at 14:16
  • https://searchsecurity.techtarget.com/definition/digital-signature has a good explanation. The use of the hash is key in digital signatures. – Neil Smithline Apr 10 '18 at 14:17
  • 1
    That's not how signatures work. [Here's](https://security.stackexchange.com/q/183347/151903) a similar recent question, though there's probably a better duplicate if you dig. – AndrolGenhald Apr 10 '18 at 14:17
  • @NeilSmithline Not sure I'd call that explanation good. `The reason for encrypting the hash instead of the entire message or document is that a hash function can convert an arbitrary input into a fixed length value, which is usually much shorter.` It's misleading people into thinking that the purpose of the hash is to produce a shorter value to "encrypt", which misleads people into thinking the hash might not be necessary when signing smaller data such as in the question I linked. It's also perpetuating the common misconception of signing as "encryption". – AndrolGenhald Apr 10 '18 at 14:27
  • @AndrolGenhald - Fair enough. I picked it because it clearly discussed the hash something the OP, seems to have missed. – Neil Smithline Apr 10 '18 at 14:35

1 Answers1

1

Your question implies a slight misunderstanding. First, to clear that up: Digital signatures do not encrypt the original data. You can choose to both sign and encrypt the original data, but those are two totally distinct processes. I will address signed and encrypted messages at the end. The original data is called the plaintext below, which is the official term.

A standard digital signature works by hashing the plaintext first. For message signing, only the hash is encrypted. Since both the sender and the recipient can hash the plaintext, they should get the same result. A digital signature requires the sender to append the hash to message, and he encrypts the hash with his private key.

Since the sender encrypted the hash with his private key, the recipient knows that only the sender's public key will allow him to decrypt a hash that matches the plaintext. This is the essential concept behind signing.

In order to verify the plaintext, the recipient decrypts the hash attached to the message. Then he computes a hash for the plaintext on his own. If his computed hash matches the decrypted hash, then he knows the message has not been changed. If his computed hash does not match the decrypted hash, then the message cannot be trusted.

If the sender wants to encrypt the entire message, he can do that as well. He would simply encrypt the plaintext with the recipient's public key (the encrypted data is called ciphertext). Then he calculates a hash for the ciphertext, and he sends the ciphertext with an encrypted copy of the hash, just like a regular signed message. The process is similar for the recipient, except this time the recipient will use the hash to verify the ciphertext. If it matches, he will then decrypt the ciphertext into plaintext.

DoubleD
  • 3,882
  • 1
  • 6
  • 14
  • 1
    I take some issues with the terms "encrypted/decrypted" in the context of digital signatures, also because signing and encrypting are different processes as you so well explained. – A. Darwin Apr 10 '18 at 17:56
  • I'm not sure where you have a problem. The hash is generated based on the plaintext, but that hash is encrypted afterward by the signer/sender. Digital signatures require both hashing and asymmetric cryptography. I can edit if there is a point where the answer is ambiguous or uses the wrong term. – DoubleD Apr 10 '18 at 18:01
  • 2
    The hash is not encrypted. It is signed using public-key cryptography, but cryptography!=encryption. The fact that you use one kind of key (private) to "encrypt" the hash and another kind (public) to actually encrypt messages is a bit confusing to explain if you say that the hash is "encrypted" just as if it were a message to actually encrypt. Even more confusing if you consider that encryption (in public-key schemes) is done with the *receiver*'s key, while signing obviously requires the *sender*'s key. IMO it's better to say that the hash is signed/verified than encrypted/decrypted. – A. Darwin Apr 10 '18 at 18:11
  • I agree, technically, it should be sign/verify for most of that post. I wanted to simplify as much as possible though. Primarily, to convey that the hash provides the guarantee. The original question doesn't seem to understand that the signed message includes more than just the plaintext/ciphertext. – DoubleD Apr 10 '18 at 18:29
  • In RSA cryptography, the underlying function used to sign the hash is more or less the same as the function used to encrypt the session key when encrypting message, except with public and private key reversed and session key replaced with the message hash. This is why people often speak of signing as encrypting using private key, but strictly speaking this is just an implementation detail of RSA cryptography, so using the same terminology can be confusing. – Lie Ryan Apr 10 '18 at 23:34
  • -1 for `For message signing, only the hash is encrypted.`. This is incorrect as others have pointed out. Please don't keep spreading this myth. – forest Apr 11 '18 at 01:35