Using GPG to Sign and Encrypt Files

Using GPG to Sign and Encrypt Files

We will now cover using the GPG command line to carry out the basic operations of encrypting and signing files. We will then discuss how various e-mail clients integrate these operations into sending and receiving e-mail messages and how they may be integrated into e-mail packages that do not automatically support them.

To see the full set of command line options, execute

 gpg --help 

The program has many more options than we will present here. We are going to present the bare basic commands to sign, encrypt, decrypt, and verify signatures on plain-text messages. In other words, the basics to integrate GPG into e-mail. We will then show how some existing e-mail clients already support GPG and how some can be made to do so.

Signing Files

One of the most powerful uses of GPG doesn't actually hide your message at all. Digital signatures assure the recipient of a message of two things:

·                 The identity of the sender

·                 The integrity of the message

Let's construct an example that can have obvious consequences. Suppose our Leroy has been suspected of some sort of white- collar crime. He sends an e-mail to a good friend of his that says:

 I did NOT commit the crime! 

Now suppose the actual criminal has access to the mail servers. He has put a program on the mail server to deflect any mail from our Leroy to his own mailbox, where he can modify the message at will and send it on to someone else, still appearing to come from Leroy. Suppose he changes it to read:

 I did commit the crime! 

The ease with which such changes can be made is part of why e-mail is not that good a medium for legal purposes. Leroy can protect himself, however. Let's show how with files.

Suppose we have the original message in a file called legal.statement in Leroy's home directory ( /home/bubba ). He can digitally sign the file in a form suitable for e-mail with the following command:

 [bubba@mars bubba]$ gpg --clearsign legal.statement 

 You need a passphrase to unlock the secret key for 

 user: "Leroy Macmillian <[e-mail]>" 

 1024-bit DSA key, ID 0E8FAB64, created 2000-07-04 

 Enter passphrase: 

After he enters his passphrase, he will be back at his Linux prompt. But there is a new file out there called legal.statement.asc, and it looks like this:

 [bubba@mars bubba]$ cat legal.statement.asc 

 -----BEGIN PGP SIGNED MESSAGE----- 

 Hash: SHA1 

 I did NOT commit the crime! 

 -----BEGIN PGP SIGNATURE----- 

 Version: GnuPG v1.0.1 (GNU/Linux) 

 Comment: For info see http://www.gnupg.org 

 iD8DBQE5Y0qlix6AMQ6Pq2QRApSDAKDz/RLuUE3a7lxmgTzqZmtvbPdEHACdHFR1 

 NWedbupPVklTCFOUIVaJzsU= 

 =NPHm 

 -----END PGP SIGNATURE----- 

As you can see, the original content of the message is still in there and still readable, but it is surrounded by a bunch of junk. That junk can be thought of as a GPG "envelope." Notice it actually says "PGP" in the message. Since GPG is designed to be a drop-in replacement for PGP, it has to follow the behavior of PGP exactly, right down to the structure of the "envelope." If it were changed to read "GPG," it might break other programs.

So how does this gibberish protect Leroy? Well, first let's see what happens when Leroy sends this file to me (remember, we'll get to e-mail later. Right now it is files).

As it happens, Leroy and I correspond a lot. I already have his public key and I've already marked that I trust it. So when I pass his original, unmodified message through GPG, I get:

 mars:26:~$ gpg legal.statement.asc 

 gpg: Signature made Wed 05 Jul 2000 09:48:05 AM CDT using DSA key ID 0E8FAB64 

 gpg: Good signature from "Leroy Macmillian <[e-mail]>" 

 mars:27:~$ ls legal* 

 legal.statement legal.statement.asc 

He sent me legal.statement.asc and then I ran GPG on it. This produced the file legal.statement, which is the original message without the envelope. It also gave me a message. The "Good signature" message tells me that the message I received was signed with the private key that goes with Leroy's public key, and it tells me that the message I got was the one he signed with that key. So long as Leroy has kept his passphrase totally secret, we both know that he sent me a message telling me he did not commit the crime.

Now suppose our evil white-collar criminal, twirling his moustache and cackling, intercepted Leroy's message and changed it to look like this:

 mars:30:~$ cat legal.statement.asc 

 -----BEGIN PGP SIGNED MESSAGE----- 

 Hash: SHA1 

 I did commit the crime! 

 -----BEGIN PGP SIGNATURE----- 

 Version: GnuPG v1.0.1 (GNU/Linux) 

 Comment: For info see http://www.gnupg.org 

 iD8DBQE5Y0qlix6AMQ6Pq2QRApSDAKDz/RLuUE3a7lxmgTzqZmtvbPdEHACdHFR1 

 NWedbupPVklTCFOUIVaJzsU= 

 =NPHm 

 -----END PGP SIGNATURE----- 

Boy, that surprises me! I know Leroy and I don't think he'd do something like that. And if he did, I don't think he'd send me e-mail about it. He's smarter than that. I'd better check the signature.

 mars:31:~$ gpg legal.statement.asc 

 gpg: Signature made Wed 05 Jul 2000 09:48:05 AM CDT using DSA key ID 0E8FAB64 

 gpg: BAD signature from "Leroy Macmillian <[e-mail]>" 

 mars:32:~$ ls -la legal* 

 -rw-rw-r-- 1 mschwarz mschwarz 25 Jul 5 10:10 legal.statement 

 -rw-rw-r-- 1 mschwarz mschwarz 303 Jul 5 10:09 legal.statement.asc 

Whoa! "BAD signature" tells me this message was originally signed with the private key of my good friend Leroy but that the message text has been tampered with, because the signature doesn't match the file. Someone is out to frame my good friend!

Nothing prevents moustache twirler from creating a fake key with the same name and e-mail address as those of my friend, but it would not match the public key I have on my keyring from Leroy. If our villain tried to substitute a fake signature, this is what GPG would have told me:

 mars:39:~$ cat legal.statement.asc 

 -----BEGIN PGP SIGNED MESSAGE----- 

 Hash: SHA1 

 I did commit the crime! 

 -----BEGIN PGP SIGNATURE----- 

 Version: GnuPG v1.0.1 (GNU/Linux) 

 Comment: For info see http://www.gnupg.org 

 iD8DBQE5Y1L1oHgCFwxAlJgRAlaVAJ4hHP8aV03F46hx1LxQkIeDU1pOwgCglXc+ 

 ksM5rPYWtetrPHG7/EhcTD0= 

 =vODa 

 -----END PGP SIGNATURE----- 

 mars:40:~$ gpg legal.statement.asc 

 gpg: Signature made Wed 05 Jul 2000 10:23:33 AM CDT using DSA key ID 0C409498 

 gpg: Can't check signature: public key not found 

As you can see, I find I can't validate this message at all because I don't have the public key that goes with the private key that was used to sign this message. Suppose, however, I had received a message that appeared to come from Leroy many months ago, telling me that he had generated a second key for emergencies and here was the public key? Suppose I had accepted that key into my keyring? Suppose, instead of that message coming from Leroy, it had come from the moustache twirler? I would have had a "Good signature" on that fake message!

The integrity of keys is the absolute foundation of any crypto system. You don't care who gets your public key, but you do care very much who is giving you public keys and whether they are really from the people they claim to be.

My preferred method of exchanging public keys is face-to-face on floppy diskettes. Failing that, GPG has key-signing and trust levels. You can sign other people's keys with your private key. This allows people who trust your key to trust this other key, because they know your key and they trust that you would not sign a key you didn't trust. So long as you sign only keys that you actually know came from whom they claim to come from, this system works. Note that you can sign a key and still not trust the key owner. This is a good thing. You sign it because you know for a fact that it is "Leroy's" key, but you don't trust it because you know Leroy is dumb as a stump and would sign a key sent to him in a spam e-mail message by a stranger he'd never met.

We won't cover the details of key signing and trust here. This book introduces you to the tools, shows you the basics, and sends you on your way to learn for yourself, but issues of key management, key signing, and trust are critical to the integrity of your system.

When someone sends you a public key over an untrusted medium, you have to regard it with suspicion. Verify that key! Certainly do not sign or mark at a higher trust level any key you haven't validated .

Encrypting and Signing Files

We have shown how you can validate files and foil forgers with GPG using signatures. Now what about protecting your file or message from prying eyes?

First off, I have to make a confession. I've told you that GPG uses a so-called "public-key cipher" to encrypt messages and that the older " symmetric-key " system is not used. That was a lie. I wanted to emphasize the fact that the public “private key pair is critical to both functions. Public “private keys are so large, however, that they are impracticable for messages of any significant size. Performing the encryption algorithm with more than 1024-bit keys on messages many kilobytes long or longer can take many minutes on even the fastest of machines.

These keys must be huge because it is known that (at some level) the keys are products of primes, and thus, only prime numbers need be tried when trying to break them. That means a great many numbers need not be tried when trying to "brute-force" attack these keys. (NB: I'm oversimplifying again. Remember that the keys are actually derived using relative primes and an algorithm. The principle still holds. A public key/private key pair can be attacked in more sophisticated ways than trying every possible value.)

Since the keys are so large and thus so slow, they are used to encrypt a much smaller symmetric session key that is used for only the one message. The encrypted session key is sent encrypted with the public key of the recipient. The recipient and only the recipient is able to decrypt the session key and thus is able to decrypt the message encrypted with that session key. Confused? Don't worry. It works. The session key is generally 128 bits long. Since it is not a public key and is generated in a truly random manner, all possible 128-bit values are equally likely, so, unlike public keys, every possible value must be attempted in a brute-force attack. A 128-bit key ought to be safe until the sun grows cold.

Now that you know about the symmetric session key, we will not mention it again, because in encryption, just as in signatures, it is the public key/private key pair you deal with at the command line.

Let's continue in the same vein as earlier. Let's assume Leroy really did commit white-collar crime. Let's say he has been stealing pens from the office supply cabinet and returning them to Office Depot to exchange for merchandise. Let's further suppose he recently returned 1,247,114 Sharpie permanent markers and used them to purchase a desk and Palm V organizer.

The pen police are hot on his trail. Leroy, figuring a risk shared is a risk doubled , decides to tell me all about it. At least he has the sense to send me his missive encrypted. Here's how things look at Leroy's account:

 [bubba@mars bubba]$ cat confession 

 I returned millions of pens I stole from TeraGigaMegaCorp and 

 returned them at Office Depot to exchange for a desk and 

 a Palm V organizer! What am I going to do? The pen police are on 

 to me! 

 Leroy 

 [bubba@mars bubba]$ 

He signs and encrypts it:

 [bubba@mars bubba]$ gpg --encrypt --sign --r mschwarz --armor confession 

 You need a passphrase to unlock the secret key for 

 user: "Leroy Macmillian <[e-mail]>" 

 1024-bit DSA key, ID 0C409498, created 2000-07-05 

 Enter passphrase: 

He enters his passphrase. His passphrase is not needed for encryption! It is needed for the signature. If he had not requested the signature, he would not be prompted for his passphrase. Now, he has imported my public key, but he never used it before and did not give it a level of trust. My key was also not signed by someone whose key he does trust. So he has to go through a few gyrations before he's done:

 Could not find a valid trust path to the key. Let's see whether we 

 can assign some missing owner trust values. 

 No path leading to one of our keys found. 

 2048g/EF74743B 2000-02-07 "Michael Alan Schwarz <[e-mail]>" 

 Fingerprint: 7226 3E60 BECE D054 4CF9 0486 B309 CF38 EF74 743B 

 It is NOT certain that the key belongs to its owner. 

 If you *really* know what you are doing, you may answer 

 the next question with yes 

 Use this key anyway? 

I gave him the key on a floppy, so he knows he can trust it.

 Use this key anyway? yes 

 [bubba@mars bubba]$ ls -la confession* 

 -rw-rw-r-- 1 bubba bubba 194 Jul 5 11:49 confession 

 -rw-rw-r-- 1 bubba bubba 1248 Jul 5 12:01 confession.asc 

 [bubba@mars bubba]$ 

Had he set my trust level, even if to "untrusted," he would not have had to answer that question. Note he now has two files. The first is his unencrypted confession (which, if he is smart, he will overwrite and delete). The second looks like this:

 [bubba@mars bubba]$ cat confession.asc 

 -----BEGIN PGP MESSAGE----- 

 Version: GnuPG v1.0.1 (GNU/Linux) 

 Comment: For info see http://www.gnupg.org 

 hQIOA7MJzzjvdHQ7EAf7BGj1YuxeMpz0LOzBUHMd6GL4PlIbIECzblbJefx2MOj1 

 oA80kQNNNOGLVRgnvB0qMSt6zaaUt5UMyhFUbH/6wS0JSMyzpfZabcKrF9/6KCcP 

 LhbOIScejBVWwRF6QML2g8jJBvj/GrRnLiroS/b+fZ83DtAH/CDxGkk3ilJC2tHl 

 5K38JePQiSwC7sXtb0WcCsiEik5M9dusAc7cpZAOPO0VRpMm006wAEh5RCyKFhZU 

 TlJUO5Bc+MDyVXmecOfiKBXMV59o/RFoqTvjqH8uRVJB3YzV8HBXMhyMMVead7UC 

 GV5jOnLsL0zZGKqgzdC1edcJaasJ9RXDYqk3echk0wf9E2vwjo4N1HGBDINYO3WK 

 OXYuxY9Q6NFPJw3cO46RWrWh795JpVPaOquJi7GXzy4vJUJAyhlcxnzNbwwyZq+V 

 5NZQNXfAotTwgHRZybrJm3sgrWQLGQMtUVSo7fTP/im6gPXj0HEC0ofJqKFt/5uq 

 xmrQ6VlMahuPEQxzwAPJKg/V5P/tawQhrb/MD5rJ4s1JmiE/kJ/96etG8HDr/bf6 

 +4PT7gOayLe3KFYuySAPr2hzqesqp5ZPu1A2wLeU6DmKldvMVWXpiWOygFUTTxNr 

 Z9hgSGez9vCdKOmjsaalE3a5BtsWDhpJSQjv8ZFLSaKlYdHRoyzJ5UjXhuF9e8y9 

 KsnAXXGVLqaodZLelztpM/65NznBf34/lXWHTea0j9ezBjXf5Mrel/zbrqGmF2Ub 

 zpXNxCmBTwnEoR4cZRpMg8s2ICrtzS7sL7WobFhOeUMsWfGICY6qJxlRsQOmcY8N 

 zIy2TNCBIEMwgnRR95YF2UZq8SgFE2am4Y0Pfxu25Kt6MQ+xFXxjD3KbZxu6Kzro 

 9VDhrkX/0L7HFDxaKj8ak7CSELI3OgXRFjyiouxx8+FkzJMovO5s+ckC1rwi6Xq7 

 65/UXJN07vpvU/J4Ti1wJiL2Q81zUZVK2r35oa+wVnJVLOzJo/Y8EIZy5FQWcylt 

 bp7uKHSq1owPSks7ZKLqz7c4jJk5NtE4Q2SvhXVmWfNPuH4x3xQRVMDMYL1jyp6u 

 Hw== 

 =Fzrl 

 -----END PGP MESSAGE----- 

 [bubba@mars bubba]$ 

No one but me can read that file. Even Leroy cannot read it. Only people listed as recipients (the "-r" in his encrypting GPG command line) may read the message. It is encrypted with each recipient's public key. Only the corresponding private key can decrypt the message. Yes, you are right if you have deduced that there are multiple copies of the message if it is sent to multiple recipients.

GPG compresses the message before it is encrypted, so often the encrypted message is smaller than the original, even when sent to more than one person. Our message is so short that compression buys us next to nothing.

Now, when I get the message, this is what I see:

 mars:106:~$ gpg confession.asc 

 You need a passphrase to unlock the secret key for 

 user: "Michael Alan Schwarz <[e-mail]>" 

 2048-bit ELG-E key, ID EF74743B, created 2000-02-07 (main key ID 2A43DBA2) 

 Enter passphrase: 

I have to enter my passphrase, not for the signature, but for the decryption. Do you begin to see? You must type a passphrase any time you need your private key. Your private key is stored encrypted so that even if your private-key file is somehow stolen, it is still difficult, if not impossible , to recover your private key.

Note that the security of your private key is only as strong as the strength of your passphrase. This is potentially the weakest link in the GPG chain. I know people who are so paranoid that their secret key is kept on a single floppy, symbolically linked to their .gnupg directory. They insert the floppy whenever they need it, and then unmount and file it when done. If they destroy the floppy, the key is gone for good and all the stuff encrypted with their public key is then encrypted forever (or until their key is brute-forced, whichever comes first). Barring a miraculous discovery of a simple means of factoring large numbers, forever will come first.

Getting back to our story, I enter my passphrase, and then

 gpg: Signature made Wed 05 Jul 2000 12:01:17 PM CDT using DSA key ID 0C409498 

 gpg: Good signature from "Leroy Macmillian <[e-mail]>" 

If I look, I now find a file called confession in addition to confession.asc, the one that I got from Leroy.

  mars:109:~$ ls -la confession*  

  -rw-rw-r-- 1 mschwarz mschwarz 194 Jul 5 12:14 confession  

  -rw-rw-r-- 1 mschwarz mschwarz 1248 Jul 5 12:07 confession.asc  

  mars:110:~$  

Here's what I find inside:

  mars:113:~$ cat confession  

  I returned millions of pens I stole from TeraGigaMegaCorp and  

  returned them at Office Depot to exchange for a desk and  

  a Palm V organizer! What am I going to do? The pen police are on  

  to me!  

  Leroy  

  mars:114:~$  

Poor Leroy. He took every precaution but he didn't realize that I want no part of a conspiracy charge. I forward the e-mail, signed and unencrypted, to T. Laurence Pencilpusher, head of the pen police. I've since deleted Leroy's key. So ends Leroy's sad story.

Encryption without Signature: A Codicil

Personally, I always sign or encrypt and sign messages. There may well, however, be situations where you would wish to encrypt a message and leave it unsigned. One situation would be Leroy's ill-fated message to me. He could have sent this to me and then claimed never to have done so if he had encrypted it and not signed it. Remember, all it takes to encrypt a message is the recipient's public key. Anyone might have that key. The signature proved that Leroy sent that message. If he hadn't signed it, he could have denied that he ever sent it, and it would be difficult for anyone to prove otherwise .

If, however, you find yourself thinking, "Hey! That's a good idea," I would reexamine the whole idea of sending your message in the first place. It's much easier to deny a message you don't send.