The five-minute primer on secure email

[unixronin]

I found myself with reason to give a quick primer on public-key cryptography and using it in email to a group of people I work with and have a need to have authenticated communications with, some of whom are not familiar with crypto concepts.  Since I have no idea whether there are those among my readership (or readers of readers) who don't know anything about public-key crypto and secure email, I have reproduced my primer here.

---

The five-minute primer on public-key crypto:

Classical, or two-way, cryptography uses what is known as a shared-key metaphor.  In this, you create a single encryption key which both the sender and the intended recipients share.  The encryption algorithm is reversible, such that applying it once to a cleartext using a given key creates an encrypted ciphertext, and applying it again to the ciphertext using the same key yields the original cleartext.  This single key MUST be kept a secret between all people who will use it, as anyone who has the key can use it to either decrypt intercepted messages, or to forge false encrypted messages.

Public-key, or one-way, cryptography uses a non-reversible algorithm using two distinct keys: a secret key known only to the sender, and a public key which can be distributed freely to the entire world.  A cleartext encrypted using the public key can only be decrypted using the matching secret key.  It is also possible to use the secret key to encrypt a message; it can then be decrypted unly using the matching public key.

This opens up several new possibilities not present in conventional shared-key encryption.  The most notable are the following:

• Alice can use Bob's freely-available public key to encrypt a message and send it to Bob; only Bob can read that message.  Alice and Bob need never have met in person.

• If Alice makes a digest of the message cleartext and encrypts that digest using her own secret key, then attaches the encrypted digest to the cleartext before encrypting it and sending it, Bob can later retrieve Alice's public key, decrypt the digest, and compare it to a digest that he creates of the message as he received it.  If the encrypted digest can be decrypted using Alice's public key to yield a correct digest of the message, then assuming Alice's secret key has not been compromised, Bob knows two things about the message:

  1.   It can only possibly have been sent by Alice;
  2.   It cannot have been tampered with between the time Alice sent it and when Bob received it.

  Again, Alice and Bob need never have met in person to do this. This is the mechanism of a digital signature.

• Finally, since public-key algorithms are slow but strong, the normal way in which public-key tools operate when encrypting a message is to first create a random single-use session key and encrypt the cleartext using that key and a fast-but-strong two-way algorithm such as Blowfish or Rijndael.  This small session key is then encrypted using the recipient's public key and attached to the message.  This technique makes it possible to add additional recipients simply by adding additional copies of the session key encrypted using other recipients' public keys.  The result is a message which can be decrypted by ANY of those addressees, and ONLY by those addressees, without compromising any of the addressees' keys either to each other or to the world at large.  Only a few bytes are added to the message for each additional recipient, instead of having to separately encrypt copies of the entire message for each recipient.

Pointers to a few public-key tools:

There is a free, open-source public-key crypto package, GnuPG, which fully supports the OpenPGP specification.  It is available from http://www.gnupg.org for most Unix-like operating systems, all current versions of Windows, and Mac OS/X. The current version is v1.4.5.

babylon5:alaric:/minbar/src:12 $ gpg --version
gpg (GnuPG) 1.4.5
Copyright (C) 2006 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.

Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA
Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

If building GnuPG for Unix from source, I recommend use of the following configuration options:

--enable-m-guard --enable-tiger --enable-new-tiger

These days, I believe GnuPG defaults to creating 1024-bit keys unless you specify otherwise.  I personally prefer to create 2048-bit keys to try to keep ahead of the continuing increase in processing power.

There is a precompiled Windows binary build of GnuPG available here.  This is a command-line tool with a GUI installer.

Standalone GUI frontends for GnuPG can be found here:

• GPGShell:  http://www.jumaros.de/rsoft/gpgshell.html

• WinPT:  http://www.winpt.org/

Note:

"Many people have commented that WinPT *should* be the official Win32 GnuPG frontend. Unfortunately, it looks like the WinPT site is currently experiencing difficulties."

GPG for Mac can be found here:  http://macgpg.sourceforge.net/

Integrating this into mail depends what mail you're using. If you use Mozilla or Thunderbird, you can use the Enigmail plugin, which includes a GUI interface within the application.  The current version of enigmail is v0.94.1.

There is also a EudoraGPG plugin for using GnuPG with Eudora.

Finally, this page at the National Center for Supercomputing Applications contains information on using GnuPG with various mail clients including Mozilla Thunderbird, Eudora, and Microsoft Outlook.

Trust:

This post specifically does not address the issue of key trust, as it is a fairly complex issue which is largely separate from the technical aspects of actually using public-key cryptography.

Comments

[robbat2.livejournal.com]

Firstly:
http://xkcd.com/c177.html

Secondly, GnuPG 2.0.0 was announced on the mailing lists yesterday, and I've packaged it for Gentoo already.

[unixronin.livejournal.com]

Huh. I didn't get the announcement, and it's not on the download page as of about three hours ago (or right now, for that matter). In fact, I can't see anything about it on the site except a news item saying that GPG 1.9.9.2 (which isn't available for download) is one of the last steps towards it.

[robbat2.livejournal.com]

The web is a little behind it seems.

http://lists.gnupg.org/pipermail/gnupg-devel/2006-November/023364.html

But it is definetly on the FTP, and some of the mirrors.

[unixronin.livejournal.com]

Thanks for the pointer. I see there's quite a few additional dependencies.

[sierra-nevada.livejournal.com]

While you specifically passed on discussing trust, it's important to note one thing about E-mail: generally, the messages exist in a context, which is why if one gets a message that appears to be from one's boss which orders something unreasonable or uncharacteristic (i.e. the context is violated), the order is typically double-checked rather than blindly followed.

This is why most forgeries don't work, and why we've been able to get away with having no strong authentication on the vast majority of E-mail for its entire existence.

[unixronin.livejournal.com]

That's very true, as far as it goes. However, it must be said that, not only can a message which appears to break context not necessarily be a forgery, but a forgery does not necessarily have to appear to break context. In fact, all of the most skillful and successful forgeries are believable exactly because they do not appear to break context -- the false information appears, on the surface, harmless and routine.

This is probably related to why phishing is so successful -- on the surface, it appears to be not fraud, but a bank or business trying to protect its customers from fraud. The startling thing to me is that, while people will immediately discard a phishing attempt from someone they know they don't do business with, they will so often accept it if it appears to come from a bank they do have an account with. I don't know whether it's a failure to generalize from "phishing scam purporting to be not-my bank" to "phishing scam purporting to be from my bank", some idea along the lines of "Gee, I've been getting so many scams lately, no wonder my bank is taking precautions", or simply "This appears to come from MY bank, it must be legitimate."



In this case, though, or in the context of the original reason why I wrote this up, the need is not one of detecting forgery so much as it is one of documenting in a verifiable manner, without exchanging physical documents, that a known group of people agreed upon a certain version of a specified document.

[sierra-nevada.livejournal.com]

A successful forgery doesn't (obviously) break context. The advantage the phishers have is that there is so little context these days with one's bank, or credit card company. The fun thing is that it takes so little additional context to smoke out the phishers: I give each vendor I do business with a different E-mail address, such that if a message purports to come from one of them, but does not use the correct recipient address, ipso facto the message is a forgery. In effect, a shared secret.

Now, I did this because I wanted to identify those miscreant vendors who were selling my information (and so that I could easily cut them off without changing my main E-mail address), but it happened to work extremely effectively against phishers, once those appeared. Lucky me for being just a little suspicious.

Is your situation a SOx compliance thing? It sure sounds like it.

[unixronin.livejournal.com]

I give each vendor I do business with a different E-mail address, such that if a message purports to come from one of them, but does not use the correct recipient address, ipso facto the message is a forgery. In effect, a shared secret.

That's an aspect of throwaway addresses that hadn't occurred to me before. I like it.

(Oops ... premature posting)

[unixronin.livejournal.com]

train of thought, where are you?

Oh yes. What I meant to add was that no, this actually has nothing to do with SOx, and I hope it never will.