Verifying a Message's Integrity and a Sender's Authenticity
through a Digital Signature

		currently selected role: not selected
Alice's Computer:		Internet:	Bob's computer:
private key*:	public key*:		public key*:	private key*:
use this key: hashvalue signature			use this key: c u at the park at five hashvalue   signature

How can I verify a Message's Integrity and a Sender's Authenticity through a Digital Signature?

By encrypting a message with Alice's public key, Bob can send Alice a message that only she will be able to decrypt. However, ANYONE can send such a message - there is no proof of the message's integrity (Was it changed on its way from sender to addressee?) or the sender's authenticity (Was it really sent by the person claiming to be the sender?). But asymmetric cryptography also holds a solution to this problem! A solution which at a first glance seems confusing, but keep working through this explanation and you will be rewarded by witnessing how a digital signature is created by the sender and verified by the receiver.

At the heart of a digital signature there is a "hash function" on which sender and addressee agree. This hash function generates a value for a text. Whenever the same text is used, the function will also return the same "hash value" for the text. But if a single letter is changer, omitted or added, the function will almost always produce a different result. You can actually watch the hash function work by observing how the value of the field "hash value" of this animation changes when typing the letters of a message. If I send this hash value in addition to the message, the addressee can verify the message's integrity by generating the hash value for the received message and comparing it to the received hash value.

However, if I only send the message and the hash value, anyone ready to change the message can also generate a hash value that fits the new message and replace the hash value provided by the sender. Moreover, still ANYONE could have written and sent the message in the first place. This is the moment where asymmetric cryptography comes in again: To show that it was Bob who wrote the message and generated the hash value, Bob encrypts the hash value with his private key. By encrypting a message's hash value with the sender's private key he of her generates a digital signature of his or her message. Now anyone can verify the signature by decrypting it using Bob's public key. If this reveals the correct hash value for the message, Bob is the only possible sender since he is the only one to have the private key that fits Bob's public key - magic, isn't it?!

Hold on: encryption using a private key, decryption with a public key - that's the exact opposite of what we just learned about asymmetric cryptography! Yes, that's correct. The key to understanding the difference in the keys used is to understand the different intentions: If I want to achieve privacy, I use the addressee's public key so he or she will be the only one able to decrypt and read the message. If I want to show that a message was created by me, I sign it by encrypting its hash value with my private key. In practice, these two concepts are often combined: I can first encrypt a message and then sign the encrypted message. Now anyone can find out about the encrypted message's hash value - but that doesn't give away the message as such.

A remaining prerequisite for the system to work is that users guard their private keys well. When the keys are used in a software application, the private key itself is often encrypted using a password that the user has to provide each time he or she uses the key. You think that's complicated? Well, security never comes for free!

Task:

In the role of Bob, send a signed message to Alice using the form above; then switch to the role of Alice and verify the message's integrity and the sender's authenticity:

1. Encrypt the message with Alice's public key.
   (See instructions on Achieving Privacy through Asymmetric Cryptography.)
2. Copy the hash value of the encrypted message as the signature by clicking the "V"-button of Bob's computer.
3. Now encrypt the hash value with Bob's private key: Klick the safe-symbol () enclosing Bob's private key and click the button "use key on hash value" below the signature text field of Bob's computer.
4. Send the message and the signature to Alice (button "<<").

1. As Alice, check the message's integrity and the sender's authenticity by decrypting the received signature using Bob's public key: Click the website symbol () enclosing Bob's public key and then click the button "use key on hash value" below the signature field of Alice's computer! Does the hash value of the encrypted message match the decrypted hash value? Then this exact message can only have been produced with Bob's private key. Given that Bob protects his private key well from being stolen, this exact message can only have been written and sent by Bob.
2. Decrypt the actual message using Alice's private key.
   (See instructions on Achieving Privacy through Asymmetric Cryptography.)
   

Notice: This animation only supports the encryption of lower case letters, full stop and comma. Numbers should be spelled out such as "five" for "5"!

* The keys you find in the text fields upon loading the animation are only a proposal. There are other possible pairs of keys, such as these. If you would like to use a differen pair of keys simply edit the numbers in the text fields surrounded by the symbols for the private and public key accordingly.

(c) 2010 Andreas Gramm