Pretty Good Personal Privacy

Do you ever get the feeling that someone's looking over your shoulder as you read your email? Do you ever worry when you click the Send button who might end up reading your message? Did you ever receive a message or file and wish that you could know for sure who really sent it? And what about the files on your PC; do you have any that you'd rather not have other people see?

If you don't worry about these kinds of things yet, the time has come for you to reconsider.

Because you use both your personal computer and the Internet much more now, for much more important or sensitive things.

It's not that the Internet is that much less secure that it used to be. It isn't. But there are a lot more people using it now, and some of them aren't good guys like us. Whether it's a "script kiddie" looking for his warped idea of fun or a really bad guy with genuinely sinister motives, there's lot more spoofing, snooping, and other bad things going on on the Internet these days.

Your personal computer, on the other hand, really is a lot less secure now than it used to be. It used to get a measure of security by being in your office or home, where the bad guys couldn't get to it. Now, with Web surfing and email, not to mention it just being connected to the Internet, perhaps even full time, the bad guys don't need physical access to a machine anymore to do bad things to it anymore.

And then there's email. Let's consider the case of Ted and Carol and an important email message that Carol received from Ted. If Ted says that he didn't send it, there would be no way for Carol to prove otherwise, even if she had a copy of the message. Or Ted could admit to sending Carol a message, but not the one that Carol says she received. Carol could have altered the message after she received it, and Ted couldn't prove that either. Or both Ted and Carol could both be telling the truth -- Ted didn't send it and Carol didn't fake it; the message could easily have been sent by someone else entirely! In security terms (not to mention the X-Files!) using unsecured email has provided both Ted and Carol with plausible denial.

So if you don't mind confusion or even deception, fine. But if you do, you should consider securing important messages and files. 

Securing data, whether it's the email that you send, the email that you receive, or the files you keep on your own personal computer, involves five things:

Privacy

-- scrambling data so it can't be seen by anyone except the person that it's intended for.

Integrity

-- ensuring that data hasn't been changed, either in transit or in storage.

Authenticity

-- being able to tell without a doubt who the source of the data is.

Timestamp

-- authoritative validation of the time when the data was prepared.

Nonrepudiation

-- proof against the false denial of either the source of the data or of its contents.       

In any cryptosystem, the encryption itself provides privacy. Ensuring integrity and proving authenticity and ownership are taken care of together, with a digital signature. The digital signature provides non-repudiation and therefore prevents plausible denial. They are also dated, but they don't provide a legally valid timestamp.

PGP/MIME and the two standardized data protection schemes that it inspired, OpenPGP and S/MIME, all offer all these data protection features. (See PGP, PGP/MIME, OpenPGP, and S/MIME: A Short History.)

Symmetric, or single key, encryption goes back to Roman times. In symmetric encryption, the same key is used for both encryption and decryption.

Let say that Sue has something she wants to give you that she doesn't want anyone else to be able to see. That's the plaintext. "Plaintext" means unencrypted; it doesn't have to be a "plain text file" -- one that you can actually read. You can encrypt any type of computer file, producing an encrypted ciphertext.

1. Sue selects a key, and then uses that key to encrypt the plaintext to produce the ciphertext.
   
   
2. Sue gives both the key and the ciphertext to you. (Not together, obviously, or anyone could intercept the delivery and use the key to decrypt the ciphertext.)
   
   
3. You use that same key to decrypt the ciphertext to regenerate the plaintext.

Symmetric key encryption can be very fast and strong (with a large enough key), but it also has two important problems: (1) getting the key securely from the person who does the encryption to the person who will decrypt the ciphertext, and (2) simple symmetric encryption doesn't provide the other aspects of data security, including authentication and integrity.

Figure 1. Symmetric Encryption

Click on the image to view it full size.

Asymmetric, or public key, encryption is a recent development. In symmetric encryption, a new key is used for each encryption, thus there's one key per encryption. In asymmetric encryption, there's two keys per person. Each person using public key cryptography, PKC, has a pair of related keys, called a key pair. The keys' "relation" to each other is simple. Anything that's encrypted with one of the keys must be decrypted with the other. This is public key cryptography's major innovation.

For simplicity, let's consider you and your friend Sue again. You use public key cryptography, so you have generated a key pair for yourself. You distribute one of these keys publicly; that's your public key. The other key you keep to yourself; that's your private key.

So, when Sue wants to encrypt something for you, she uses your public key to encrypt it, and you use your private key to decrypt it:

1. You give Sue a copy of your public key.
   
   
2. Sue uses your public key to encrypt the plaintext to produce a ciphertext for you.
   
   
3. She then gives (just) the ciphertext to you, and
   
   
4. You use your private key to decrypt the ciphertext to reproduce the plaintext.

Figure 2. Assymmetric or Public Key Encryption

In this figure, a sender -- let's say Sue -- is using your public key to produce a ciphertext for you. But the process also works backwards; you could encrypt a plaintext with your private key and send the resulting ciphertext to Sue. Decrypting the ciphertext with your public key proves that the ciphertext had to come from you. This provides authenticity, without privacy. Your public key is public, so anyone could decrypt this ciphertext, not just Sue. But public/private key pairs make digital signatures possible, which provide authentication and integrity without sacrificing privacy.

Click on the image to view it full size.

By having the encryption done with a publicly available key, symmetric encryption avoids asymmetric encryption's "How do I get the key used in the encryption to the person who'll be doing the decryption and get it there securely?" problem.

But PKC systems aren't off the hook with key distribution. Each public key must be, in some way, labeled authoritatively with its owner's name and there has to be some way of reliably getting the proper public keys to everyone who needs them. The labeling and distribution of public keys in public key systems is a primary function of a public key infrastructure, PKI. The PKIis an important part of any public key cryptosystem.

In public key cryptography, digital signatures are used to prove authenticity -- that Sue is actually the one who sent the original text -- and also prove the integrity of the signed text -- that it wasn't altered in transit or in storage.

1. Sue uses her private key to digitally sign the original text. Her PKC software:
   1. Calculates a message digest, a short, one-way summary of the original text, and
   2. Encrypts the message digest with Sue's private key.
   3. The calculated and encrypted message digest is the digital signature; it is attached to or stored with the original text, forming the signed text.
      
      
2. Sue sends the signed text to you.
   
   
3. You use Sue's public key to verify the signature. Your PKC software:
   1. Decrypts the digital signature, the message digest that was encrypted with the signer's private key; it uses Sue's public key to do this.
   2. Calculates a message summary from the text of the message as you received it, and
   3. Compares the two message digests.

If the message digest that Sue sent you and the one that you calculate match, it proves two things:

• That the original text hasn't been changed since it was signed, and
  
  
• That the message digest you received was really produced by Sue, whose private key was used to sign it. (Otherwise, her public key would not have successfully decrypted the message digest she sent.)

The digital signature also provides nonrepudiation -- the signer, in this case Sue, cannot deny being the source of the original text and the receiver, in this case you, can also prove that you didn't modify the text after you received it.

Figure 3. How Digital Signatures are Made

A message digest is a short summary of a message (or file) that is calculated from the message in a way that, if the message is altered at all, the altered message won't produce the same message digest as the original message. Message digests are one way only. The receiver has to be able to produce a message digest of the message as it was received, so the digesting algorithm -- a hash function -- must be public. But privacy would be compromised if you could reverse the digesting process to reproduce the message from the message digest.

Click on the image to view it full size.

So now we have asymmetric/public key encryption for privacy and digital signatures for authenticity and integrity. Aren't we done? Well, yes, we could be. But using asymmetric encryption for privacy is slow. Using symmetric -- single key -- encryption would be much faster. And it turns out that we can use symmetric encryption, because public key encryption's digital signatures give us a good answer to symmetric encryption's "how do I securely get the key used in the encryption to the person who doing the decryption?" problem.

So all practical public key cryptosystems are hybrid schemes. The plaintext is encrypted using a symmetric encryption system, with a large, randomly chosen session key, which is only used for that one specific encryption. Just the session key is encrypted with the receiver's public key. The symmetrically encrypted ciphertext and the session key that has been encrypted asymmetrically with the receiver's public key are sent to the receiver, together. The receiver uses his or her private key to decrypt session key and then uses the session key to decrypt the ciphertext to regenerate the original plaintext.

This hybrid scheme gives you the efficiency of symmetric, single-key, encryption while keeping the privacy (only your private key can decrypt the session key, which is needed to decrypt the ciphertext), convenience, and flexibility of public key encryption. It also solves the problem of what to do if you want to send an encrypted message to several people. Public key cryptosystems encrypt the session key once for each person, bundle the ciphertext and all the encrypted session keys together. That's at lot better than having to re-encrypt the entire message for each recipient.

Note that encryption -- privacy -- and digital signatures -- integrity and all manner of authenticity -- are independent features; you can encrypt without signing, sign without encrypting, or do both, depending on the level of security that you want for an individual message or file. The ACCC's security officer often sends messages that are signed, but not encrypted. That way anyone can read the message, and someone who uses PGP can also authenticate it.

Not surprisingly, using a public key cryptography system to secure your data brings up as many security questions as it solves, particularly with respect to key pair management.

What's to keep someone from coming in your office or breaking into your computer from the 'Net and stealing your private key? Your private key must be kept private. It's also rather big; too long, certainly, for you to remember and type every time you need it. So you have to keep it in a file on your personal computer. What's to keep someone from stealing it? Nothing, really. Which is why PKCsoftware like PGP Freeware associate private keys with password  --PGP Freeware calls it a passphrase --and won't do anything with your private key until you enter that passphrase.

This is a good thing. It means that physical access to your personal computer and/or to your private key isn't enough to decrypt PGP-encrypted files/email, even those stored on your personal computer. But it's a bad thing too. There is absolutely nothing that can be done if you forget your passphrase. Forget your passphrase, and you lose access to everything that's encrypted for you with PGP. Period.

What if someone does manage to steal your private key? They've stolen your signature. Worse, actually; handwriting analysis should be able to give you plausible denial for a forgery of your handwritten signature. No such luck with digital signatures.

What do you do if your private key is compromised? Your only option is to cancel your current key pair -- as of a certain date if you don't want to invalidate your previous digital signatures. After you create a new key pair, how do you tell everyone who has your old public key what's happened? You don't want anyone else to be allowed to cancel your keys, but if you've forgotten your password, how can you prove you're really you?

What about encryption and digital signatures in your professional life? What if a colleague encrypts important work-related files and then quits without leaving the key? What if he just forgets his password? One answer to work-related encryption is to have key escrows that allow supervisors to obtain copies of a subordinate's keys. That, of course, brings up even more questions!

Well, there aren't any yet. The security industry and international standards bodies are working on finding answers to these questions, and to many more. 

That's not to say that functional PKI packages aren't already available; they are. The problem is that, like PGP Freeware's PGP/MIME, they're not yet based on accepted international standards. But unlike PGP/MIME, switching from one public key server system to another isn't worth the considerable effort it will cost, on all of our parts.

So, how do we exchange public keys? Use PGP, Inc.'s or MIT's public key servers. Look on Web pages; many organizations and individuals put their public keys on their home pages. Or just ask for them, like we did for email addresses in the old days. Send someone an email message, ask if they use PGP, and ask for their public key.

You'll need PKC software and someone to exchange email with.

For PKC software, try PGP Freeware. It's freeware (duh!). That means it's free for the asking, for noncommercial use. The online version of this article has links to downloading and installation instructions. (It also has an additional article More Information on PGP and Data Security.)

Because of licensing problems and now defunct US security laws, downloading PGP Freeware is, shall we say, interesting. Installing and using it is easy, however, particularly with Eudora and the other common email packages that it supports. Irecommend you pick Diffie-Hellman/­ DSS key pair; 2048 is a good key pair size.

(By the way, PGP Freeware does a lot more than just secure email. It can encrypt and/or sign any file and folder on your computer and it comes with Wipe, a more secure delete that writes over deleted files so they can't be recovered by a disk utility program such as Norton Utilities. It also comes with PGPKeys, which keeps track of your private key and of your "keyring" of other people's public keys, and allows you to publish your public key on PGP, Inc.'s and MIT's public key servers and to search those servers for other people's public keys.)

As for someone to exchange encrypted or signed email with -- I'm game. Get my PGP public key from my Web page (where is it? see the box below), send me your public key, and I'll exchange some PGPed email with you.

Comments (and PGP email) are welcome;
please send them to Judith Grobe Sachs, judygs@uic.edu