In an earlier post, I promised to explain how hashes relate to digital signatures. Let’s begin with a thought experiment: suppose you have a document you want to protect. Specifically, you want to let others (“recipients”) know that you wrote the document and that it has not been changed by anyone since you wrote it. We can do the latter with the hash. (Remember that it can be used to detect even the smallest change in a document.) How do we communicate the deliver the document and the hash to the recipients?
If we send them together – such as in the same file – an attacker could modify the document and the hash. In that case, the recipients would be deceived into believing the modified document was the original. That would be bad!
We could send the hash in a separate file. In fact, we usually do that if the document is a binary file such as a spreadsheet, picture, or audio file. It can be a bit unwieldy when the document is a text file such as an email. (Even an HTML email is actually text.)
In the case of text, we tend to encrypt the hash and send or store it along with the document. But we have to choose the encryption wisely: if we use symmetric encryption (where the encryption and decryption keys are the same, often called “shared secret”), we’d have to share the “secret” with anyone who might want to read the file. That could include the attacker who could then modify the document, re-generate the hash, and then re-encrypt it. In that case, the benefit would be lost.
We need to use “public key encryption”. Without going into the details as we do in Learning Tree’s introduction to cybersecurity, public-key uses two keys instead of one. One key – called the private key – is used for encrypting the hash. The person doing the encryption (the document writer in our example) keeps the key private. The other (public) key must be known by anyone who wants to verify the hash. The keys are generated by software at the same time and one cannot be figured out from the other. We usually convert the encrypted hash to text that looks like gibberish (called Base 64) and attach it to the document.
Here is a tool you can use this tool to demonstrate it for yourself: https://8gwifi.org/RSAFunctionality?rsasignverifyfunctions=rsasignverifyfunctions&keysize=4096. That page also provides some of the deep details and links to code to generate and verify signatures for those who are programmers.
There are a few details to consider: not all digital signatures are of the same type. Some compute the hash differently and some use different public-key encryption methods. Two of the most common digital signature algorithms are DSA and RSA. Those who want to verify the signature clearly need to use the same algorithm as the signer.
Deploying digital signatures is not fundamentally difficult. Most commercial email tools can be configured to sign outgoing emails and verify the signatures of incoming messages automatically. Signatures on software packages are validated automatically when the software is installed. In the cyber security introduction class, participants use simple tools to sign and verify text and binary files. One potential is how to manage the public and private keys, a topic we’ll visit another time.