Secure Email

Outlook Express, or Mozilla, or Netscape e.g. make it easy to acquire a digital certificate, and then use it to sign your email, and also encrypt your email. Very useful if you want to maintain some privacy in your communications. Nobody, absolutely nobody, not even the NSA, can decrypt communications using these key pairs. It truly is a neat technology and very private. Basically, an "asymmetric key pair" is used to encrypt communications. In this scheme, the "public" key is published for all the world to see. The "private" key is ..never.. revealed anyplace, and is kept strictly private by the person who owns it. If a person encrypts a communication using your public key, then only you can decrypt it, using your private key. Likewise, if a person encrypts a message using his private key, then anybody can decrypt it using that person's public key. What is the use of that? Well, the use is that we are guaranteed to know that the message was from that person, thus it is called a digital signature.

[In practice the use of these algorithms tends to be processor intensive, so in fact, a "hash" is taken of the data, and then the has is signed.]

It is the same technology that is used in SSL-enabled websites, i.e. when you see the "https" and the padlock on your browser. The web site is sending its digital certificate to you, and you (your browser) is verifying that it is indeed that website that is talking to you. It does this by using the public key of the website to decrypt the message. Since the message was encrypted using the private key of the public/private key pair, you know that the message is indeed from that website if the public key is able to decrypt the message. You then exchange an encryption key (that is where the 128 bit encryption comes into play) which is used for encrypting all further communications. This is because the public/private encryption keys are very processor intensive, and there are better ways (read ..faster.. ways) to do the encryption/decryption.

It is also the same technology used in Microsoft's "authenticode" scheme. Whenever you get any software from Microsoft, you also get a digital certificate, which you can use to verify that the software did indeed come from Microsoft. You are asked whether you trust the source or not. Any time you get a new driver, it is supposed to be signed so that you can verify its authenticity. The whole ActiveX trust paradigm is built around developers digitally signing their Active X code that they download. You can actually check these digital certificates by clicking on the padlock in the browser.

Basically, you first obtain a "digital certificate" from a "certificate authority" like Verisign (there are others). This will cost you about $15 per year. A digital certificate is a public/private key pair used in encrypting communications. After you obtain the digital certificate, OE will put two buttons on your toolbar, "sign" and "encrypt." When you push the "sign" button, you are adding a "digital signature" to your email. The person who receives your email can verify that it is from you and you alone by using your public key to decrypt the signature. The public key is "published" on public authorities, much like your phone number is published. The email client and the browser knows where to find your public key.

To encrypt the email you send, you need to also push the "encrypt" button. So there are two problems solved by this technology. The email recipient can verify that the email was indeed from you, and the communications can be encrypted from prying eyes.

There are other ways to obtain these key pairs, and various ways to use them. Linux has a lot of built in tools to generate and use these keys. There is even an open source version of this stuff - PGP.

Tim Richardson has a nice explanation of secure email practices at his website.

Some concepts worth memorizing:

1) Digital signature: This is text that is "signed" with your private key. In fact, it may be a hash of your data, and then the hash is signed with your private key. The hash is easy to do, and produces a smaller, maybe 80 or 120 or 160 byte result, which is easy to sign with the private key. The "message" is then the original text, followed by the hash. In this case the actual message text may not be encoded.

2) Digital Envelope: This is text which is "signed" with the public key of the person to whom you are sending the text. In this manner, that person is the only one who can "open the envelope" by using his private key to decode the message. Again there are various techniques to encode the actual data.

3) Digital Certificate: This is generally some useful information, such as your name, address, email address, and your public key. This stuff is then signed with the private key of a "certificate authority." You can then present this certificate to anybody you want, who can then verify it by using the public key of the certificate authority to verify your identity. There are many public "certificate authorities" to whom you can pay money, and who will give you various types of certificates. The best types are those where you have to prove your identity by appearing in person and present various forms of ID.

4) Self signed certificates: There are many cases where you just want to use the public/private key techniques in a private or public setting in situations totally under your control. You don't need to worry about a public certificate authority. You can then "self sign" the certificate, in effect pretending to be a certificate authority yourself.

5) Hash: When you take a "hash" on some data, this is a way of reducing a block of data/text, whatever to a fixed size, and which almost is guaranteed to be a unique value from any other. Now I know this sounds fishy, but in practice it works. The chances of there being a "collision," where two different pieces of data will produce the same exact hash is extremely remote. So the technique is very useable. Data is often reduced to a "hash" - which represents a "fingerprint" of the data, and then the hash is signed with the private or public key as the case may be. Neat concept.

6) One time pad: This is the historical way of encrypting information. It requires a guaranteed random string of digits which you combine with each digit in turn which is to be encrypted. The "one time pad" must then be used to decode the message. As long as the one time pad is guaranteed random, there is no way to break the encryption. There were many ways of generating random sequences of digits, pulling letters (1-28) out of a hat and writing them down, e.g.

7) pseudorandom: This is a completely random sequence of digits, but it is generated by a computer algorithm, and can therefore be duplicated exactly. This is combined with a completely random smaller "salt" to guarantee its complete randomness. The RC4 algorithm generates a pseudorandom sequence, or "key."

Update July 2004: www.CACert.org is trying to form an "open source," i.e. free Certification Authority. This might be worth supporting. I have applied for a certificate, but have yet to receive it. I think they may be swamped by all the applications. Search for information on them thru www.slashdot.org .

Update Spring 2006: Steve Gibson and Leo LaPorte are doing a fantastic ipod series on all things techie. Some of the discussions are on security considerations. Go here.

TCP/IP STUFF

WIRELESS STUFF

PC STUFF

ADSL/CABLE MODEM STUFF