Digital signatures and asymetric keys

On a previous post, I had an excellent answer, but I did not understand it fully.   The answer contained the following:

Most cryptographic signatures are in fact the hash of the message encrypted with the signer's private asymmetric key. By decrypting the key using the matching public key, the verifier can obtain the original hash, and hence, match that to a locally calculated value of the message's hash.

My confusion is the asymetric keys.  The answer stated that you encypted the hash with the private key, and decrypt with the public key.  This seems backwards to me

In SSL, I thought the client would encrypt the hash with the public key and the server would decrypt the hash with the private key

Or am I mistakeninly thinking of SSL with digital signatures.   Does SSL make use of digital signatures

Anthony LuciaAsked:
Who is Participating?

Improve company productivity with a Business Account.Sign Up

Joe Winograd, Fellow&MVEConnect With a Mentor DeveloperCommented:
In the previous question, I referred you to the comprehensive white paper, Digital Signatures for PDF documents, by Bruno Lowagie, the CEO of iText Software:

In Section 1.3, "Encrypting a message using a public-key encryption", beginning on page 16, it says this:
Suppose that Bob wants to send Alice a private message3, but Bob doesn’t trust the channel used to transmit the message. If it falls in the wrong hands, Bob wants to avoid that the message meant for Alice’s eyes only, can be read by anyone else.

Bob could use an algorithm to encrypt his message, and then Alice would need to use an algorithm to decrypt it. If the same key can be used for encryption as well as decryption (or if the key for decryption can be derived from the key used for encryption), Bob and Alice are using a symmetric key algorithm. The problem with such an algorithm is that Bob and Alice need to exchange that algorithm in a safe way first. Anybody with access to the key can decrypt your message.

To avoid this, Bob and Alice can choose an asymmetric key algorithm. In this case two different keys are used: one key to encrypt, the other one to decrypt the message. One key cannot be derived from the other. Now if Bob wants to send Alice a private message, Alice can send her public key to Bob. Anybody can use this key to encrypt messages meant for Alice. When Bob sends Alice such an encrypted message, Alice will use her private key to decrypt it. Suppose that Chuck intercepts the message, he won’t be able to read it as long as he doesn’t have access to Alice’s private key.
I believe this answers your new question well. Regards, Joe
Giovanni HewardConnect With a Mentor Commented:
With asymmetric encryption it's import to realize that clear text (data) encrypted with one key (public or private) is decrypted with the opposing key.  So, if I wanted to transmit a hash to verify my cipertext wasn't changed during transit, I would use my private key to do so.  Why?  Because you have access to my public key, which allows you to decrypted the message, access the hash, generate your own hash, and compare the two values.  Make sense?
Giovanni HewardCommented:
Here is a look at how message integrity controls and digital signatures fit into the overall process of transmitting information to ensure confidentiality, integrity, non-repudiation, and assurance of delivery. Now they actually have confidentiality, integrity, proof of origin, and proof of receipt.

Cryptography Summary

    Alice wants to send a message to Bob and provide confidentiality, integrity, proof of origin and proof of receipt.


    To protect the secrecy of her message contents, she uses a symmetric cipher to encrypt it. For that she uses a symmetric key. This produces a ciphertext message.


    To protect the accuracy of the message, she uses a hashing algorithm that condenses the arbitrary-length message to a fixed-size message digest value.


    To prove the message actually came from her, Alice signs the message by encrypting the hash value with her private key. The sum of the message digest encrypted with Alice's private key results in a digital signature.


    This digital signature is then appended it to the bottom of the symmetrically encrypted message. Now in order for Bob to read, prove the origin, and check the accuracy of the message, he must reverse all of the encryption done above.


    To read the message, Bob needs a copy of the symmetric key. Alice encrypts it using asymmetric encryption and encrypts the symmetric key with Bob's public key, producing a ciphertext key.


    Bob decrypts the ciphertext key with his private key to give him his copy of the symmetric key.


    Bob uses the symmetric key to decrypt the message with that key and read it.


    Bob decrypts Alice's digital signature using Alice's public key. Once the decryption process is complete, he is left with the message digest.


    But, he has yet to prove the integrity of the message or the proof of origin. He must prove the message digest value is correct. To do this, Bob must rehash the message that he has received and decrypted.


    If the message digest that he generates from the message matches the message digest that he decrypted from Alice's digital signature, then he has proof of integrity and proof of origin.


    To prove that he received the actual message Alice sent, Bob re-encrypts the message digest with his private key, which will result in his digital signature.


    Bob sends his digital signature back to Alice.


    Alice decrypts Bob's digital signature using his public key to produce the message digest.


    She compares the message digest she just received to the message digest she originally generated. If these two message digests match, then she has proven that her message was received by Bob (proof of receipt) in its correct format (proof of integrity).
Joe Winograd, Fellow&MVEDeveloperCommented:
Nice diagram! Please provide a link to the web page for it. Thanks, Joe

Another nice diagram is this:

cryptographic techniquesIt is from another excellent paper, An Overview of Cryptography, by Gary Kessler:

Regards, Joe
Rich RumbleConnect With a Mentor Security SamuraiCommented:
I also broke it down to basics in my article:

PGP, GPG aka Public Key Cryptography:

Public Key Cryptography is a hard concept to grasp at first. But you use it everyday on the internet, httpS, ssh, sftp and many VPN solutions use Public Key Cryptography (ssl/tls) to secure the transmission of data (data in motion, mind you).
The basics are, you create a key-pair and someone you know creates a key-pair. You can password protect the private key, or you don't have to, it is recommended that you do have a password protecting the private key. So you have your Public and Private keys and I have mine. We can tell/show/give anyone our public keys we want. We must however protect our private keys from others. I can take your public key, encrypt, sign or seal my file using your public key, and when I send it to you, only you can decrypt it with your private key (and password) The password has nothing to do with how the keys were made by the way, the password is only there to protect the private key from being used by others if they are stolen or copied. You can change the password that protects your private key if you want, it won't make any difference, the private key remains the same.
EFS uses Public Key Cryptography, as do many other applications. Public Key Cryptography helps eliminate password sharing, but it doesn't scale well past two parties. PGP has a method, much like S/MIME, that allows multiple recipients to receive one version of an encrypted email, but it's not the standard way in which Public Key Cryptography works.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.