Secure Communication with Public-Key Encryption

3-rotor Enigma Machine[This is a guest post by Konrad M. Lawson, a graduate student studying modern East Asian history and founder of Konrad has contributed several recent posts on managing photos from archives.--@jbj]

Encryption is not just for spies and gangsters. Anyone who is active online already benefits from it in a host of transactions with banks, web retailers and during most account logins. It is essential for the protection of our personal and financial data. In the realm of email communications, however, there are many occasions when an extra layer of protection is needed to protect a party or the information they send, especially when we are living in or communicate with people who are in states that with very limited civil liberties: the professor who is getting updates from a student doing sensitive research in an authoritarian country, the researcher who is receiving advice from a friendly state archivist on what unclassified-but-maybe-they-shoulda-been documents to request, a sociologist who is studying the formation and development of dissident networks, or anyone who has friends that might be at risk if they spread their views and information they have.

Unfortunately, much of the information online about email encryption and cryptography is unnecessarily detailed and complex. Most people just want to know, “How do I exchange email with person X without anyone else reading it?” They may not be interested in prime factorization, rainbow tables, and cryptographic salts. On the other hand, in order to effectively use any of the popular systems for secure email exchange there are still some basic concepts that need to be understood.

The leading method for exchanging secure email messages with a large number of people is called public-key, or asymmetric encryption. My own experience suggests that it can be somewhat confusing to new users, a problem compounded by the often highly technical explanations found in software manuals and on websites. The following is a custom version of my favorite way for explaining how public-key encryption works:

Professor More receives a letter from his friend in Italy, Professor Erasmus. “What’s up Tom? I wanted to get your thoughts on a draft syllabus I put together for a course entitled, ‘Can Folly Speak? Corruption and Superstition in Early Modern Europe’” Unfortunately, as Prof. Erasmus adds in his letter, the course outline might lead to some misunderstandings, so he wants only his friend to see it.

What to do? He could lock the document in a box, and somehow send the key to Prof. More, but what happens if someone intercepts and copies that key along the way? The two come up with an ingenious solution: Prof. More and Prof. Erasmus send each other an open padlock, but keep the key. Prof. Erasmus places his syllabus in a box, locks it with Prof. More’s padlock and sends it to him. Prof. More then opens the box, locked with his own padlock, using the key he kept. When he is ready to send back his comments, Prof. More places the document into the box, but this time locks it with the open padlock that Prof. Erasmus sent him. Prof. Erasmus receives the returned box and opens it with his own key. No one who intercepts the box or the exchanged locks ever gets a chance to steal a key since they never leave the possession of the owner.

This little story reveals two of the most basic concepts behind public-key encryption:

  1. Whenever a message is sent it is encrypted with the recipient’s lock, not one’s own.
  2. The system only works if Prof. Erasmus is sure that the padlock he was originally sent and uses to lock the box indeed came from Prof. More and wasn’t, for example, intercepted and craftily switched out with another lock belonging to crazy grad student Ulrich, who is always trying to twist his words to suit his own radical agenda.

Keeping the story above in mind, let us see how it parallels elements in the world of public-key encryption and email:

Using his encryption software Prof. More creates two connected ‘encryption keys.’ He keeps one private, and reveals it to no one. This ‘private key’ corresponds to the key in our story, and exists as a small file on his iUtopia computer. The other ‘public key,’ which, somewhat confusingly, corresponds to the open padlock in our story, only has the ability to encrypt a message, that is, to lock a box, such that only Prof. More’s ‘private key’ can unlock it. Prof. More wants all of his friends to have this ‘public key’ so they can send him encrypted email whenever they like. Also, to prevent Ulrich from fooling Prof. Erasmus by giving him another ‘public key’ and claiming that it is from Prof. More, instead of merely emailing his friends copies of this ‘public key’ Prof. More also puts a copy of the key on his homepage (as I do) and registers it with one or more open depositories of public keys called key servers. For every person Prof. More wishes to communicate securely with, he will need a copy of their public key in order to encrypt his messages to them.

I have not addressed another important but somewhat less confusing level of authentication used called ‘digital signatures’ that prevents Ulrich from posing as Prof. Erasmus when he sends an encrypted message to Prof. More, or discussed expiration and revocation of keys which constitutes another aspect of email security. I do hope the posting has made clear the often confusing role of public and private encryption keys that is the heart of a lot of email encryption today. In a separate posting I want to shift to a discussion of the specific software options out there that will allow you to create and manage keys, and integrate encryption into your email workflow.

How about you? Do you use public-key encryption? How have you persuaded others to do so? Let us know in comments!

Image by Flickr user ell brown / Creative Commons licensed.

Return to Top