This article is the first of two articles aimed at explaining how secure communications work and how GnuPG (the GNU Privacy Guard) can be used to secure our communication, verify the authenticity of a communication and other things. The first article aims at explaining the basics of encrypted communication while the second article aims at trying to help you secure yourself using the GNU Privacy Guard.
Consider Alice and Bob, two people who wish to communicate with each other securely and privately. Alice fires up her e-mail composer, writes what she wishes to write and hits the Send button. Bob opens his Inbox and reads the e-mail. This is how the problem of communication itself has been solved, by using e-mail.
Mallory wants to eavesdrop on the conversation. He simply writes a packet sniffer program, a program that keeps monitoring the information sent between Alice and Bob. With relatively little effort, he is able to see the message Alice sent to Bob. This is the problem we are trying to solve. We need to prevent Mallory from reading what Alice intends to be read only by Bob. How do we do it?
Let us clear one thing first. It is extremely hard to control what happens between all those wireless and wired transmissions that take place once Alice hits the Send button. So, you can hardly prevent Mallory from being able to capture the 'packets' of information running all over the world as a result of the Send button being clicked. What we wish to achieve is that Mallory will not be able to make sense of any information captured by him. In other words, we wish to encode our informaiton in such a way that Mallory cannot make sense of it BUT BUT BUT ... Bob, the intended recipient should be able to make sense. This is called encryption.
Let's see the simplest example of how communication can be encrypted. Consider the following message.
i love you
We now adopt a simple (and perhaps one of the oldest) schemes to encrypt this message. We shift each letter by 2 in the order it appears in the English alphabet. 'a' becomes 'c', 'e' becomes 'g' etc. And our message now transforms to:
k nqyg aqw
Note that since there are is no letter after 'z', we have rewound to 'a' in the case of 'y'. Now, that looks hard to read, isn't it? If Mallory were to capture this content, he would not be able to make sense of it. But so would Bob! For Bob to be able to make sense, Alice would have to tell Bob what kind of encryption was used and also mention the number '2' to indicate by how many places should Bob shift back each letter to recover the message. This '2' is known as the 'key' because it sort of unlocks the message.
How does Alice convey the key i.e. number '2' to Bob? One could argue that she would use an alternate secure connection to convey this but that is not the solution. Firstly, there is hardly anything such as a secure channel in the world of Internet but even otherwise if there was a secure channel which Mallory could not access, then she could send the message itself through that secure channel!
Because the key K that encrypts the message and the key K that decrypts the message are the same, this method of encryption is called symmetric encrytion. And we cannot use it, as explained above, for communication over a network or the Internet.
Let's now see another form of communication that takes us closer to solving the problem. Bob generates a pair of keys - Kpublic and Kprivate. The private key is kept secured, never exposed publicly to the world and depending on how diligent Bob is, highly guarded and secured. Here is the interesting thing, his public key is kept completely exposed. He sends it people via e-mail, even makes it available as a downloadable file on his web site and in fact even publishes it on a public server where people can search for it!
Alice therefore can easily discover Kpublic. She uses this to encrypt any message she wishes to send to Bob. Now, here is the ingenuity behind the encrytion algorithm being used by her. There is a special mathematical relation between Kpublic and Kprivate so that what is encrypted by one can only be decrypted by the other. Since the key that encrypts is not the key that decrypts, this form of encryption is called asymmetric encryption.
Since Alice encrypts using Kpublic, the only way her message can be decrypted is using Bob's Kprivate. And note that Bob has safeguarded this very carefully. If Mallory were to capture the message, since he does not have access to the private key of Bob, he will not be able to decrypt the message at all (unless Alice and Bob have used a weak algorithm to encrypt with known security holes).
Before we move on to the next article which goes into hands on, one last concept to explain is that of a digital signature. Let us consider another problem. Alice wants to publish something relatively publicly. She does this. Bob discovers this and downloads it. As he peruses the material, he grows a little suspicious. Did Alice really write this? It doesn't sound like her. How does Bob verify the content in front of him is indeed Alice's?
Enter checksums. Consider the following text.
Hello World! I am Alice. Find Mallory. Kill him not, keep him alive!
A checksum algorithm is one that converts a stream of bytes like above and transforms it into a collection of characters in an irreversible manner. For example, running the following command on a file containing above text gives the following output.
$ md5sum some.txt 727f0e11d7c4c8d2932048414332c611 some.txt
727f0e11d7c4c8d2932048414332c611 cannot be used to recover the content. This
is what we mean by checksums being irreversible. The second important property
of checksums is that the slightest change in the contents results in a
completely different checksum. Consider a subtly different version of the same
message by Alice.
Hello World! I am Alice. Find Mallory. Kill him, not keep him alive!
Notice the comma which changes the meaning of the message drastically. But let's see what it's checksum will be -
$ md5sum some.txt d768054291acb3084480eb3d3b3f5aa7 some.txt
d768054291acb3084480eb3d3b3f5aa7 looks nothing like 727f0e11d7c4c8d2932048414332c611!
And all that changed was a comma! Okay, what does this have to do with
signatures? Let's go back to the problem. How does Alice sign her work so that
people like Bob can be sure that she is indeed the author of this work and that
nobody has tampered with her work?
She creates a checksum of her work. She puts it at the end of it. Bob can now calculate the checksum and compare it with the checksum Alice has put at the end of the work. Meh! Mallory could recompute the checksum of his modifications to Alice's message and replace her checksum as well.
So, Alice takes it one step further. She computes the checksum and encrypts it using her private key. Since the public key is, well, public, Bob can easily decrypt it using her public key. Then he compares the checksums to ensure that Alice's message has not been modified. Now, suppose Mallory modified the message, he could indeed replace the checksum but since he does not have Alice's private key he will either not do so OR will use some other private key. But then Bob cannot use Alice's public key to decrypt the checksum. So, Bob immediately calls foul and refuses to believe what he is seeing and even warn Alice or any consumer of Alice's work.
The process of computing a checksum and encrypting with your private key is what we call 'digital signing'.
In the next article, I will explain how to use GnuPG to achieve all of the above in practice.