For comments about this file, email to:
paul@kinzelman.com
Last updated Nov 19, 2008
I wrote this file because of the difficulty I had in getting email encryption working. I wasn't able to find any documents which helped for understanding the big picture.
My intent is to make a document to describe the forest (or at least some of it) so that you can look for more detailed descriptions elsewhere of the parts that interest you.
If you would like to contribute writing to this file for areas I've not covered, I'd be happy to insert your writing in it.
Doctors and anybody else in the medical field who are required to abide by the HIPAA act for confidentiality might want to use encryption to exchange email with their patients or with health insurance companies.
Lawyers who are concerned about confidentiality of documents they exchange with their clients also should be interested in email encryption. If lawyers used encryption, they wouldn't have to append the common 'nastygram' at the bottom that if you're not the intended recipient and you received it in error, you're supposed to destroy the document.
Note that Authenticity depends on Integrity. You can't have assurance of Authenticity without also having assurance of Integrity.
A complex magic mathmatical process automagically generates two complementary keys; one is called public and the other is called private.
If you have the private key, you can deduce the public key. But if you have the public key, trying to deduce the private key is computationally infeasible (at least this year :-).
One person can then encrypt some data using one of the keys (either one), and send it over the public internet. A person receiving this encrypted data can determine the original data only if he has the other key. Anybody else who intercepts the encrypted data from the internet will not be able to determine the original data if they don't have the proper decrypting key.
The private key must be kept secure, but the public key should be made available to anyone in the world.
And both protections rely on one person having a private key known only to himself, and the other person having a public key (complementary to that private key) that is known to the world.
Note that this provides authenticity and integrity for the message, but does not provide secrecy. In other words, signing merely assures that the identity of the originator of the message is the person (or persons) who know the private key as well as assures the contents of the message (which anybody with the public key can read) has not been tampered with.
If I want to send a message to you so that you can be sure that it came from me, my email program would perform a Signing Operation on the message using my private key. Then anybody who knows my public key can use their email program to perform a Signature Verification operation on the message to verify that the message came from me. If nobody else has my private key, then nobody else could perform the Signing Operation properly to be Signature Verified successfully by you.
If I want to send a message to you that nobody else can read during its transmission, I would have to determine your public key either by you sending it to me or from a public database. My email program would then use your public key to perform a Public Key Operation on the body of the message and then send the message to you.
When you receive the message, your email program would perform a Private Key Operation on the body of the message. And because nobody else has your private key, nobody else can perform that Private Key Operation on the original message to be able to read the message.
Note that anybody can get your public key (you want everybody to have it), but anybody having only your public key cannot deduce your private key, and so they are unable to decode a message on which somebody else performed a Public Key Operation using your public key.
If you use Mozilla Thunderbird to access your email (your Email Client program), you will find the private keys in the file 'key3.db' and the public keys in 'cert8.db' in your profile.
The Firefox browser uses same name file names that Thunderbird uses, but the files are in your Firefox profile.
In both cases, you have to generate both the private and public keys locally. And in both cases you have to publicize your public key with whomever you want to exchange encrypted email.
If you're just starting to use secure email and choosing which way to go, S/MIME is probably the better option, unless for some reason you need to use PGP encryption. PGP doesn't seem to work on lines that are long and on web page addresses (which often are long).
And the biggest reason to use the S/MIME method is that S/MIME makes the whole process pretty painless and transparent once you have obtained your email certificate from a Certificate Authority.
If you want to use PGP, the easiest way in Thunderbird is to install an add-on called Enigmail and read the documentation. You can also read these very helpful instructions.
For more detail than you probably want, read the documentation from the Internet Mail Consortium (IMC).
You get a certificate by sending a Certificate Signing Request (CSR), which includes your public key, to a Certificate Authority. They create a Certificate for you, and send this new Certificate to you using their own certificate's Signing Protocol to certify your newly-created Certificate of identity. The Certificate they send you indicates that they believe that your information (email address) corresponds to your public key.
You can then use this certificate to assure other people of your information. Basically you're telling other people that you are who you say you are because the Certificate Authority believes that you are.
If you want to read more than you probably want to know about Certificate Authorities, here are the guidelines. Currently there are about 41 CA companies operating 114 CAs, but the ones I mention in this document are the most common for people who just want free email validation and encryption.
During the certificate creation process, you'll be asked to create a password, and you'll be asked to create a 'master password' in Thunderbird and Firefox. Make sure you keep these passwords in a reliable but secure place. If you lose these passwords, you will lose access to your keys, and possibly to all of your past encrypted emails.
If you want your name (in addition to your email address) associated with your public key (similar to a passport), the Certificate Authority needs to assure themselves that you are who you say you are. Some Certificate Authorities (Thawte and Verisign, for instance) have created a "Web of Trust" or WoT. Note that each Certificate Authority has its own Web of Trust.
Once you complete the process to be within the CA's WoT, you get another certificate, but this time it assures your name as well.
To join the WoT of Thawte, go to their web page, pull down Products, select "Web of Trust", and follow the directions. Basically you have to go to visit several notaries, in person, who look over your identity documents, and then report to the Thawte that you are who you say you are. Once you complete this process, you can then obtain the new identity validation certificate.
Note that this new certificate does not superceed the previous certificate you obtained for just your email address. If you delete the old certificate, you will be unable to read encrypted emails sent by anybody with your old public key, as well as you won't be able to decrypt any emails you have stored which require this old private key.
This key exchange happens transparently and reliably.
Note that if somebody updates or changes their key, they must update all their desired recipients with their new public key by sending a signed email.