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:
- It can only possibly have been sent by Alice;
- 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:
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.
no subject
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.
no subject
no subject
http://lists.gnupg.org/pipermail/gnupg-devel/2006-November/023364.html
But it is definetly on the FTP, and some of the mirrors.
no subject