2

I'm trying to understand the process of digital signature verification, however I don't quite get the explanation in my book.

If A wants to send a message to B with a digital signature, the process is apparently as follows:

  • The message being sent has a public hashing algorithm applied to it to create a hash
  • The hash is encrypted using A’s private key, and is then appended to the message which will also be encrypted. This encrypted hash is the digital signature
  • B will then decrypt the hash using A’s public key
  • The original message is then decrypted and put through the same hashing algorithm to produce a hash
  • If the two hashes are the same, the message is authenticated, otherwise it cannot be authenticated

First off, is this explanation correct?

Second, how can B decrypt the hash using A's public key? The purpose of a public key is so data can be encrypted.

Why would A encrypt something with their private key? If sending a message to B, would A not use B's public key?

How can the original message be put through the same hashing algorithm to produce the same hash if A initially used their private key to produce the 1st hash (the private key of A won't be known to B)?

If this explanation isn't correct, where does it go wrong?

  • hash is not encryption - you can't decrypt hashes – schroeder Jun 21 '17 at 14:11
  • 1
    you also need to review how public and private keys work: if you encrypt with one, you decrypt with the other – schroeder Jun 21 '17 at 14:12
3

Encryption and (Digital)Signing are different applications of PKI.

First (only) the most relevant concepts:

  • Encryption (so that a 3rd party wouldn't see the content): Use the receiver's Public Key (B-PubKey). Encrypt the content. You know the content because it originated from you. The receiver can decrypt using their Private Key (B-PvtKey) and see the content.
  • Digital Signing (so that any party can check whether the document is exactly as it was, when you signed it; and that be sure that only you could've signed it): Use the sender's Private Key (A-PvtKey) to encrypt the hash. NOT the content.

In your example, one of the issues is that you combined both. A normal digital signature process involves

  1. Hashing the Message Plain Text using a well-known (public) hashing algorithm.
  2. Encrypting it with sender's (A-PvtKey) Private Key.
  3. Appending the encrypted hash to the Message Plain Text and send/store/...
  4. Receivers can be one/many/any. None of the receivers' keys are used.
  5. Anyone wishing to verify the document just follows the reverse process. i.e.,
  6. Separate the encrypted hash from the message
  7. Decrypt with sender's public key (A-PubKey) (usually from a Digital Signature Certificate issued by a trustworthy / legally-acceptable CA).
  8. Generate the hash from the Message Plain Text independently and compare with the decrypted hash from #7 above.

That B was able to decrypt the hash with A-PubKey establishes the technical aspect of non-repudiation. That (if) the hashes were the same establishes the document integrity.

You should be able to see illustrations of these in a number of articles / videos freely available on the web.

1

The hash process and the encryption process are two different things.

There are two ways to encrypt the message 1) use the sender's private key to encrypt then receiver uses sender's public key to decrypt 2) use the receiver's public key to encrypt then receiver uses the private key to decrypt.

The hash part... the hashing of the message is a separate process where the sender hashes the message and sends the result. The receiver also hashes the decrypted message and then compares the result. If there is a match the receiver is sure the decrypted message is verified.

1

This description is correct.

Edit: added this to hopefully clarify the technical operations When you send a signed message, you are sending the plain text AND a block of ciphertext that is the hash-output of the plaintext. The hash-output has to be protected from alteration, that is why it is encrypted with the private key. Only the public key can properly decrypt it. The recipient can then do the hash-function on the plaintext and compare the output to the decrypted hash-output you attached to the message. If both match, the message can be considered "genuine". end of edit

The point that seems to be confusing you is the role of the Private versus the Public key. These keys are functionally the same. With symmetric encryption, two keys are used to encrypt and decrypt plaintext. It's a one way function from one key to another, but in either direction.

This is where the technical, mathematical part of cryptography hands things off to the administrative/policy part of public key infrastructure. When a key pair is generated, one key is designated "private" and the other "public"; it does not matter which key is used for which, they are interchangeable. As far as the algorithm goes (at least, in the one way functional part of things...I'm not big on the technical math part, just the theory).

You sign things with your private key because, theoretically, ONLY YOU have access to that key. It's the "guarantee" that you sent the message. The public key is theoretically available to anyone and everyone. If a message is signed/encrypted and that public key happens to validate/decrypt it then one can be pretty certain that the private key signed/encrypted the message.

So using the private key to send things out is not really effective from a cryptographic "hiding the message" stand point, but it is HIGHLY effective from a "guarantee of the authenticity/origination of the message".

This is why with PKI and symmetric encryption, if you want to have a two-way private conversation, both parties need their own key-pair.

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.