How Digital Signatures Work

Figure 5-2 shows an overall picture of how a digital signature is applied to a message. In the upper left corner of this diagram, we take the original message and create a 160-bit message digest by applying the SHA-1 hash algorithm on the message. The message digest is then encrypted using the private key known only to the private key owner (i.e., the sender). Note that this is not a secretive encryption, since the sender is using his or her own private key, not the public key, to encrypt. This means that absolutely anyone can decrypt the message digest, using the associated public key, and retrieve the hash. In fact, as we will see next , this is exactly what the receiver will do with the signed message.

Figure 5-2. How digital signing works.

The result of this encryption is called the digital signature. No other party can create this particular digital signature, even if that party has access to the original message, since he or she does not know the private key that was used. By the same argument, nobody could change this message or make up a different message and sign it with this private key.

In the upper right corner of the diagram, the signed message is formed by concatenating the original message with the unique digital signature and the public key that is associated with the private key that produced that signature. This entire signed message is then sent to the desired recipient. This diagram also shows that the public key should be made available to the public in an effective way. For improved trust, using a recognized certificate authority (CA) is a good way to do this.

The other side of this story is shown in Figure 5-3, which shows how a digitally signed message is verified by the receiving party. The receiver is interested in determining whether the signed message came from the authentic sender or from someone else pretending to be that sender. The receiver is also interested in whether the message might have been altered in any way by an unauthorized party between the time the message was signed by the legitimate sender and the time it was received.

Figure 5-3. How a digital signature is verified.

In the top left corner of the diagram, the received signed message is broken into its three components : the original message, the public key, and the digital signature. For comparison against the hash of the original message, it is necessary to compute the hash of the received message. If the message digest has not changed, then you can be very confident that the message itself has not changed. On the other hand, if the message digest has changed, then you can be quite certain that the received message has been corrupted or tampered with.

Now that the hash of the received message has been found, the hash of the original message must be obtained. In the upper right corner of the diagram, we have the digital signature that was encrypted with the private key of the sender. The receiver then has to decrypt this digital signature using the associated public key to obtain the original hash. The receiver therefore takes the provided public key and checks that it is valid, which is generally done ”at least the first time ”using the services of a trusted third-party CA. If the public key checks out okay, then it is used to decrypt the original message digest, which is then compared against the message digest calculated on the received message. If these hashes match, then the message has been authenticated and has not been tampered with. Assuming that the sender has been successful in keeping the private key secret, this also can be used to hold the signer responsible for signing the message (i.e., nonrepudiation).

The Digital Signature Standard (DSS), defined in document FIPS PUB 186-2, ^[11] defines three signature algorithms: Digital Signature Algorithm (DSA), RSA (as specified in ANSI X9.31), and Elliptic Curve DSA. Since Elliptic Curve DSA is the only one of these algorithms that is not currently supported directly by the .NET Security class library, we only consider the DSA and RSA cases here.

^[11] See http://csrc.nist.gov/ publications /fips/fips186-2/fips186-2-change1.pdf for details.