![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to pgpdoc1.txt CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [PGP] / pgp|
Return to pgpdoc1.txt CVS log | Up to [PGP] / pgp |
1.1 root 1: Phil's Pretty Good Software
2: Presents
3:
4: ===
5: PGP
6: ===
7:
8: Pretty Good Privacy
9: Public Key Encryption for the Masses
10:
11:
12: --------------------------
13: PGP User's Guide
14: Volume I: Essential Topics
15: --------------------------
16: by Philip Zimmermann
17: Revised 1 Sep 92
18:
19:
20: PGP Version 2.0 - 1 Sep 92
21: Software Written by
22: Philip Zimmermann
23: with
24: Hal Finney, Branko Lankester, and Peter Gutmann
25:
26:
27:
28:
29: Synopsis: PGP uses public-key encryption to protect E-mail and data
30: files. Communicate securely with people you've never met, with no
31: secure channels needed for prior exchange of keys. PGP is well
32: featured and fast, with sophisticated key management, digital
33: signatures, data compression, and good ergonomic design.
34:
35:
36: Software and documentation (c) Copyright 1990-1992 Philip Zimmermann.
37: For information on PGP licensing, distribution, copyrights, patents,
38: trademarks, liability limitations, and export controls, see the
39: "Legal Issues" section in the "PGP User's Guide, Volume II: Special
40: Topics".
41:
42:
43: Contents
44: ========
45:
46: Quick Overview
47: Why Do You Need PGP?
48: How it Works
49: Installing PGP
50: How to Use PGP
51: To See a Usage Summary
52: Encrypting a Message
53: Signing a Message
54: Signing and then Encrypting
55: Using Just Conventional Encryption
56: Decrypting and Checking Signatures
57: Managing Keys
58: RSA Key Generation
59: Adding a Key to Your Key Ring
60: Removing a Key from Your Key Ring
61: Extracting (copying) a Key from Your Key Ring
62: Viewing the Contents of Your Key Ring
63: How to Protect Public Keys from Tampering
64: How Does PGP Keep Track of Which Keys are Valid?
65: How to Protect Secret Keys from Disclosure
66: Revoking a Public Key
67: Advanced Topics
68: Sending Ciphertext Through E-mail Channels: Radix-64 Format
69: Environmental Variable for Path Name
70: Setting Configuration Parameters: CONFIG.TXT
71: Vulnerabilities
72: Trusting Snake Oil
73: PGP Quick Reference
74: Legal Issues
75: Acknowledgments
76: About the Author
77:
78:
79: Quick Overview
80: =============
81:
82: Pretty Good(tm) Privacy (PGP), from Phil's Pretty Good Software, is a
83: high security cryptographic software application for MSDOS, Unix,
84: VAX/VMS, and other computers. PGP allows people to exchange files or
85: messages with privacy, authentication, and convenience. Privacy
86: means that only those intended to receive a message can read it.
87: Authentication means that messages that appear to be from a
88: particular person can only have originated from that person.
89: Convenience means that privacy and authentication are provided
90: without the hassles of managing keys associated with conventional
91: cryptographic software. No secure channels are needed to exchange
92: keys between users, which makes PGP much easier to use. This is
93: because PGP is based on a powerful new technology called "public key"
94: cryptography.
95:
96: PGP combines the convenience of the Rivest-Shamir-Adleman (RSA)
97: public key cryptosystem with the speed of conventional cryptography,
98: message digests for digital signatures, data compression before
99: encryption, good ergonomic design, and sophisticated key management.
100: And PGP performs the public-key functions faster than most other
101: software implementations. PGP is public key cryptography for the
102: masses.
103:
104: PGP does not provide any built-in modem communications capability.
105: You must use a separate software product for that.
106:
107: This document, "Volume I: Essential Topics", only explains the
108: essential concepts for using PGP, and should be read by all PGP
109: users. "Volume II: Special Topics" covers the advanced features of
110: PGP and other special topics, and may be read by more serious PGP
111: users. Neither volume explains the underlying technology details of
112: cryptographic algorithms and data structures.
113:
114:
115: Why Do You Need PGP?
116: ====================
117:
118: It's personal. It's private. And it's no one's business but yours.
119: You may be planning a political campaign, discussing your taxes, or
120: having an illicit affair. Or you may be doing something that you
121: feel shouldn't be illegal, but is. Whatever it is, you don't want
122: your private electronic mail (E-mail) or confidential documents read
123: by anyone else. There's nothing wrong with asserting your privacy.
124: Privacy is as apple-pie as the Constitution.
125:
126: Perhaps you think your E-mail is legitimate enough that encryption is
127: unwarranted. If you really are a law-abiding citizen with nothing to
128: hide, then why don't you always send your paper mail on postcards?
129: Why not submit to drug testing on demand? Why require a warrant for
130: police searches of your house? Are you trying to hide something?
131: You must be a subversive or a drug dealer if you hide your mail
132: inside envelopes. Or maybe a paranoid nut. Do law-abiding citizens
133: have any need to encrypt their E-mail?
134:
135: What if everyone believed that law-abiding citizens should use
136: postcards for their mail? If some brave soul tried to assert his
137: privacy by using an envelope for his mail, it would draw suspicion.
138: Perhaps the authorities would open his mail to see what he's hiding.
139: Fortunately, we don't live in that kind of world, because everyone
140: protects most of their mail with envelopes. So no one draws suspicion
141: by asserting their privacy with an envelope. There's safety in
142: numbers. Analogously, it would be nice if everyone routinely used
143: encryption for all their E-mail, innocent or not, so that no one drew
144: suspicion by asserting their E-mail privacy with encryption. Think
145: of it as a form of solidarity.
146:
147: Today, if the Government wants to violate the privacy of ordinary
148: citizens, it has to expend a certain amount of expense and labor to
149: intercept and steam open and read paper mail, and listen to and
150: possibly transcribe spoken telephone conversation. This kind of
151: labor- intensive monitoring is not practical on a large scale. This
152: is only done in important cases when it seems worthwhile.
153:
154: More and more of our private communications are being routed through
155: electronic channels. Electronic mail will gradually replace
156: conventional paper mail. E-mail messages are just too easy to
157: intercept and scan for interesting keywords. This can be done
158: easily, routinely, automatically, and undetectably on a grand scale.
159: International cablegrams are already scanned this way on a large
160: scale by the NSA.
161:
162: We are moving toward a future when the nation will be crisscrossed
163: with high capacity fiber optic data networks linking together all our
164: increasingly ubiquitous personal computers. E-mail will be the norm
165: for everyone, not the novelty it is today. Perhaps the Government
166: will protect our E-mail with Government-designed encryption
167: algorithms. Probably most people will trust that. But perhaps some
168: people will prefer their own protective measures.
169:
170: Senate Bill 266, a 1991 omnibus anti-crime bill, had an unsettling
171: measure buried in it. If this non binding resolution had become real
172: law, it would have forced manufacturers of secure communications
173: equipment to insert special "trap doors" in their products, so that
174: the Government can read anyone's encrypted messages. It reads: "It
175: is the sense of Congress that providers of electronic communications
176: services and manufacturers of electronic communications service
177: equipment shall insure that communications systems permit the
178: Government to obtain the plain text contents of voice, data, and
179: other communications when appropriately authorized by law." This
180: measure was defeated after rigorous protest from civil libertarians
181: and industry groups. But the Government has since introduced other
182: legislation to work toward similar objectives.
183:
184: If privacy is outlawed, only outlaws will have privacy. Intelligence
185: agencies have access to good cryptographic technology. So do the big
186: arms and drug traffickers. So do defense contractors, oil companies,
187: and other corporate giants. But ordinary people and grassroots
188: political organizations mostly have not had access to affordable
189: "military grade" public-key cryptographic technology. Until now.
190:
191: PGP enables people to take their privacy into their own hands.
192: There's a growing social need for it. That's why I wrote it.
193:
194:
195: How it Works
196: ============
197:
198: It would help if you were already familiar with the concept of
199: cryptography in general and public key cryptography in particular.
200: Nonetheless, here are a few introductory remarks about public key
201: cryptography.
202:
203: First, some terminology. Suppose I want to send you a message, but I
204: don't want anyone but you to be able to read it. I can "encrypt", or
205: "encipher" the message, which means I scramble it up in a hopelessly
206: complicated way, rendering it unreadable to anyone except you, the
207: intended recipient of the message. I supply a cryptographic "key" to
208: encrypt the message, and you have to use the same key to decipher or
209: "decrypt" it. At least that's how it works in conventional
210: "single-key" cryptosystems.
211:
212: In conventional cryptosystems, such as the US Federal Data Encryption
213: Standard (DES), a single key is used for both encryption and
214: decryption. This means that a key must be initially transmitted via
215: secure channels so that both parties can know it before encrypted
216: messages can be sent over insecure channels. This may be
217: inconvenient. If you have a secure channel for exchanging keys, then
218: why do you need cryptography in the first place?
219:
220: In public key cryptosystems, everyone has two related complementary
221: keys, a publicly revealed key and a secret key. Each key unlocks the
222: code that the other key makes. Knowing the public key does not help
223: you deduce the corresponding secret key. The public key can be
224: published and widely disseminated across a communications network.
225: This protocol provides privacy without the need for the same kind of
226: secure channels that a conventional cryptosystem requires.
227:
228: Anyone can use a recipient's public key to encrypt a message to that
229: person, and that recipient uses her own corresponding secret key to
230: decrypt that message. No one but the recipient can decrypt it,
231: because no one else has access to that secret key. Not even the
232: person who encrypted the message can decrypt it.
233:
234: Message authentication is also provided. The sender's own secret key
235: can be used to encrypt a message, thereby "signing" it. This creates
236: a digital signature of a message, which the recipient (or anyone
237: else) can check by using the sender's public key to decrypt it. This
238: proves that the sender was the true originator of the message, and
239: that the message has not been subsequently altered by anyone else,
240: because the sender alone possesses the secret key that made that
241: signature. Forgery of a signed message is infeasible, and the sender
242: cannot later disavow his signature.
243:
244: These two processes can be combined to provide both privacy and
245: authentication by first signing a message with your own secret key,
246: then encrypting the signed message with the recipient's public key.
247: The recipient reverses these steps by first decrypting the message
248: with her own secret key, then checking the enclosed signature with
249: your public key. These steps are done automatically by the
250: recipient's software.
251:
252: Because the public key encryption algorithm is much slower than
253: conventional single-key encryption, encryption is better accomplished
254: by using a high-quality fast conventional single-key encryption
255: algorithm to encipher the message. This original unenciphered
256: message is called "plaintext". In a process invisible to the user, a
257: temporary random key, created just for this one "session", is used to
258: conventionally encipher the plaintext file. Then the recipient's
259: public key is used to encipher this temporary random conventional
260: key. This public-key-enciphered conventional "session" key is sent
261: along with the enciphered text (called "ciphertext") to the
262: recipient. The recipient uses her own secret key to recover this
263: temporary session key, and then uses that key to run the fast
264: conventional single-key algorithm to decipher the large ciphertext
265: message.
266:
267: Public keys are kept in individual "key certificates" that include
268: the key owner's user ID (which is that person's name), a timestamp of
269: when the key pair was generated, and the actual key material. Public
270: key certificates contain the public key material, while secret key
271: certificates contain the secret key material. Each secret key is
272: also encrypted with its own password, in case it gets stolen. A key
273: file, or "key ring" contains one or more of these key certificates.
274: Public key rings contain public key certificates, and secret key
275: rings contain secret key certificates.
276:
277: The keys are also internally referenced by a "key ID", which is an
278: "abbreviation" of the public key (the least significant 64 bits of
279: the large public key). When this key ID is displayed, only the lower
280: 24 bits are shown for further brevity. While many keys may share the
281: same user ID, for all practical purposes no two keys share the same
282: key ID.
283:
284: PGP uses "message digests" to form signatures. A message digest is a
285: 128-bit cryptographically strong one-way hash function of the
286: message. It is somewhat analogous to a "checksum" or CRC error
287: checking code, in that it compactly "represents" the message and is
288: used to detect changes in the message. Unlike a CRC, however, it is
289: computationally infeasible for an attacker to devise a substitute
290: message that would produce an identical message digest. The message
291: digest gets encrypted by the secret key to form a signature.
292:
293: Documents are signed by prefixing them with signature certificates,
294: which contain the key ID of the key that was used to sign it, a
295: secret-key-signed message digest of the document, and a timestamp of
296: when the signature was made. The key ID is used by the receiver to
297: look up the sender's public key to check the signature. The
298: receiver's software automatically looks up the sender's public key
299: and user ID in the receiver's public key ring.
300:
301: Encrypted files are prefixed by the key ID of the public key used to
302: encrypt them. The receiver uses this key ID message prefix to look
303: up the secret key needed to decrypt the message. The receiver's
304: software automatically looks up the necessary secret decryption key
305: in the receiver's secret key ring.
306:
307: These two types of key rings are the principal method of storing and
308: managing public and secret keys. Rather than keep individual keys in
309: separate key files, they are collected in key rings to facilitate the
310: automatic lookup of keys either by key ID or by user ID. Each user
311: keeps his own pair of key rings. An individual public key is
312: temporarily kept in a separate file long enough to send to your
313: friend who will then add it to her key ring.
314:
315:
316:
317: Installing PGP
318: ==============
319:
320: If you already have PGP version 1.0 for MSDOS, you should first
321: rename the old executable file pgp1.exe. This is so that you can run
322: your new version of PGP by typing "pgp" without conflicting with the
323: old version. You can still run the old version of PGP by typing
324: "pgp1".
325:
326: To install PGP on your MSDOS system, you just have to copy it into a
327: suitable directory on your hard disk (like C:\PGP), and use the
328: shareware PKUNZIP utility to decompress it from the compressed
329: archive PGP release file, called PGP20.ZIP. For best results, you
330: will also modify your AUTOEXEC.BAT file, as described elsewhere in
331: this manual, but you can do that later, after you've played with PGP
332: a bit and read more of this manual.
333:
334: Installing on Unix and VAX/VMS is generally similar to installing on
335: MSDOS, but you may have to compile the source code first. A Unix
336: makefile is provided with the source release for this purpose.
337:
338: For further details on installation, see the separate PGP
339: Installation Guide, in the file SETUP.DOC included with this
340: release. It fully describes how to set up the PGP directory and your
341: AUTOEXEC.BAT file and how to use PKUNZIP to install it.
342:
343:
344:
345: How to Use PGP
346: ==============
347:
348:
349: To See a Usage Summary
350: ----------------------
351:
352: To see a quick command usage summary for PGP, just type:
353:
354: pgp -h
355:
356:
357:
358: Encrypting a Message
359: --------------------
360:
361: To encrypt a plaintext file with the recipient's public key, type:
362:
363: pgp -e textfile her_userid
364:
365: This command produces a ciphertext file called textfile.pgp. A
366: specific example is:
367:
368: pgp -e letter.txt Alice
369: or:
370: pgp -e letter.txt "Alice S"
371:
372: The first example searches your public key ring file "pubring.pgp"
373: for any public key certificates that contain the string "Alice"
374: anywhere in the user ID field. The second example would find any
375: user IDs that contain "Alice S". You can't use spaces in the string
376: on the command line unless you enclose the whole string in quotes.
377: The search is not case-sensitive. If it finds a matching public key,
378: it uses it to encrypt the plaintext file "letter.txt", producing a
379: ciphertext file called "letter.pgp".
380:
381: PGP attempts to compress the plaintext before encrypting it, thereby
382: greatly enhancing resistance to cryptanalysis. Thus the ciphertext
383: file will likely be smaller than the plaintext file.
384:
385: If you want to send this encrypted message through E-mail channels,
386: convert it into printable ASCII "radix-64" format by adding the -a
387: option, as described later.
388:
389:
390:
391: Signing a Message
392: -----------------
393:
394: To sign a plaintext file with your secret key, type:
395:
396: pgp -s textfile [-u your_userid]
397:
398: Note that [brackets] denote an optional field, so don't actually type
399: real brackets.
400:
401: This command produces a signed file called textfile.pgp. A specific
402: example is:
403:
404: pgp -s letter.txt -u Bob
405:
406: This searches your secret key ring file "secring.pgp" for any secret
407: key certificates that contain the string "Bob" anywhere in the user
408: ID field. The search is not case-sensitive. If it finds a matching
409: secret key, it uses it to sign the plaintext file "letter.txt",
410: producing a signature file called "letter.pgp".
411:
412: If you leave off the user ID field, the first key on your secret
413: keyring is used as the default secret key for your signature.
414:
415:
416:
417: Signing and then Encrypting
418: ---------------------------
419:
420: To sign a plaintext file with your secret key, and then encrypt it
421: with the recipient's public key:
422:
423: pgp -es textfile her_userid [-u your_userid]
424:
425: Note that [brackets] denote an optional field, so don't actually type
426: real brackets.
427:
428: This example produces a nested ciphertext file called textfile.pgp.
429: Your secret key to create the signature is automatically looked up in
430: your secret key ring via your_userid. Her public encryption key is
431: automatically looked up in your public keyring via her_userid. If
432: you leave off her user ID field from the command line, you will be
433: prompted for it.
434:
435: If you leave off your own user ID field, the first key on your secret
436: keyring is be used as the default secret key for your signature.
437:
438: Note that PGP attempts to compress the plaintext before encrypting
439: it.
440:
441: If you want to send this encrypted message through E-mail channels,
442: convert it into printable ASCII "radix-64" format by adding the -a
443: option, as described later.
444:
445:
446:
447: Using Just Conventional Encryption
448: ----------------------------------
449:
450: Sometimes you just need to encrypt a file the old-fashioned way, with
451: conventional single-key cryptography. This approach is useful for
452: protecting archive files that will be stored but will not be sent to
453: anyone else. Since the same person that encrypted the file will also
454: decrypt the file, public key cryptography is not really necessary.
455:
456: To encrypt a plaintext file with just conventional cryptography,
457: type:
458:
459: pgp -c textfile
460:
461: This example encrypts the plaintext file called textfile, producing a
462: ciphertext file called textfile.pgp, without using public key
463: cryptography, key rings, user IDs, or any of that stuff. It prompts
464: you for a pass phrase to use as a conventional key to encipher the
465: file. This pass phrase need not be (and, indeed, SHOULD not be) the
466: same pass phrase that you use to protect your own secret key. Note
467: that PGP attempts to compress the plaintext before encrypting it.
468:
469: PGP will not encrypt the same plaintext the same way twice, even if
470: you used the same pass phrase every time.
471:
472:
473:
474: Decrypting and Checking Signatures
475: ----------------------------------
476:
477: To decrypt an encrypted file, or to check the signature integrity of a
478: signed file:
479:
480: pgp ciphertextfile [-o plaintextfile]
481:
482: Note that [brackets] denote an optional field, so don't actually type
483: real brackets.
484:
485: The ciphertext file name is assumed to have a default extension of
486: ".pgp". The optional plaintext output file name specifies where to
487: put processed plaintext output. If no name is specified, the
488: ciphertext filename is used, with no extension. If a signature is
489: nested inside of an encrypted file, it is automatically decrypted and
490: the signature integrity is checked. The full user ID of the signer
491: is displayed.
492:
493: Note that the "unwrapping" of the ciphertext file is completely
494: automatic, regardless of whether the ciphertext file is just signed,
495: just encrypted, or both. PGP uses the key ID prefix in the
496: ciphertext file to automatically find the appropriate secret
497: decryption key on your secret key ring. If there is a nested
498: signature, PGP then uses the key ID prefix in the nested signature to
499: automatically find the appropriate public key on your public key ring
500: to check the signature. If all the right keys are already present on
501: your key rings, no user intervention is required, except that you
502: will be prompted for your password for your secret key if necessary.
503: If the ciphertext file was conventionally encrypted without public
504: key cryptography, PGP recognizes this and prompts you for the pass
505: phrase to conventionally decrypt it.
506:
507:
508: Managing Keys
509: =============
510:
511: Since the time of Julius Caesar, key management has always been the
512: hardest part of cryptography. One of the principal distinguishing
513: features of PGP is its sophisticated key management.
514:
515:
516:
517: RSA Key Generation
518: ------------------
519:
520: To generate your own unique public/secret key pair of a specified
521: size, type:
522:
523: pgp -kg
524:
525: PGP shows you a menu of recommended key sizes (casual grade,
526: commercial grade, or military grade) and prompts you for what size
527: key you want, up to around a thousand bits. The bigger the key, the
528: more security you get, but you pay a price in speed.
529:
530: It also asks for a user ID, which means your name. It's a good idea
531: to use your full name as your user ID, because then there is less
532: risk of other people using the wrong public key to encrypt messages
533: to you. Spaces and punctuation are allowed in the user ID. It would
534: help if you put your E-mail address in <angle brackets> after your
535: name, like so:
536:
537: Robert M. Smith <[email protected]>
538:
539: If you don't have an E-mail address, use your phone number or some
540: other unique information that would help ensure that your user ID is
541: unique.
542:
543: PGP also asks for a "pass phrase" to protect your secret key in case
544: it falls into the wrong hands. Nobody can use your secret key file
545: without this pass phrase. The pass phrase is like a password, except
546: that it can be a whole phrase or sentence with many words, spaces,
547: punctuation, or anything else you want in it. Don't lose this pass
548: phrase-- there's no way to recover it if you do lose it. This pass
549: phrase will be needed later every time you use your secret key. The
550: pass phrase is case-sensitive, and should not be too short or easy to
551: guess. It is never displayed on the screen. Don't leave it written
552: down anywhere where someone else can see it, and don't store it on
553: your computer. If you don't want a pass phrase (You fool!), just
554: press return (or enter) at the pass phrase prompt.
555:
556: The public/secret key pair is derived from large truly random numbers
557: derived from measuring the intervals between your keystrokes with a
558: fast timer.
559:
560: Note that RSA key generation is a VERY lengthy process. It may take
561: a few seconds for a small key on a fast processor, or quite a few
562: minutes for a large key on an old IBM PC/XT.
563:
564: The generated key pair will be placed on your public and secret key
565: rings. You can later use the -kx command option to extract (copy)
566: your new public key from your public key ring and place it in a
567: separate public key file suitable for distribution to your friends.
568: The public key file can be sent to your friends for inclusion in
569: their public key rings. Naturally, you keep your secret key file to
570: yourself, and you should include it on your secret key ring. Each
571: secret key on a key ring is individually protected with its own pass
572: phrase.
573:
574: Never give your secret key to anyone else. For the same reason, don't
575: make key pairs for your friends. Everyone should make their own key
576: pair. Always keep physical control of your secret key, and don't risk
577: exposing it by storing it on a remote timesharing computer. Keep it
578: on your own personal computer.
579:
580:
581:
582: Adding a Key to Your Key Ring
583: -----------------------------
584:
585: To add a public or secret key file's contents to your public or
586: secret key ring (note that [brackets] denote an optional field):
587:
588: pgp -ka keyfile [keyring]
589:
590: The keyfile extension defaults to ".pgp". The optional keyring file
591: name defaults to "pubring.pgp" or "secring.pgp", depending on whether
592: the keyfile contains a public or a secret key. You may specify a
593: different key ring file name, with the extension defaulting to
594: ".pgp".
595:
596: If the key is already on your keyring, PGP will not add it again. All
597: of the keys in the keyfile are added to the keyring, except for
598: duplicates. If the key being added has attached signatures
599: certifying it, the signatures are added with the key. If the key is
600: already on your keyring, PGP just merges in any new certifying
601: signatures for that key that you don't already have on your keyring.
602:
603:
604:
605: Removing a Key from Your Key Ring
606: ---------------------------------
607:
608: To remove a key from your public key ring:
609:
610: pgp -kr userid [keyring]
611:
612: This searches for the specified user ID in your keyring, and removes
613: it if it finds a match. Remember that any fragment of the user ID
614: will suffice for a match. The optional keyring file name is assumed
615: to be literally "pubring.pgp". It can be omitted, or you can specify
616: "secring.pgp" if you want to remove a secret key. You may specify a
617: different key ring file name. The default key ring extension is
618: ".pgp".
619:
620:
621:
622: Extracting (copying) a Key from Your Key Ring
623: ---------------------------------------------
624:
625: To extract (copy) a key from your public or secret key ring:
626:
627: pgp -kx userid keyfile [keyring]
628:
629: This non-destructively copies the key specified by the user ID from
630: your public or secret key ring to the specified key file. This is
631: particularly useful if you want to give a copy of your public key to
632: someone else.
633:
634: If the key has any certifying signatures attached to it on your key
635: ring, they are copied off along with the key.
636:
637: If you want the extracted key represented in printable ASCII
638: characters suitable for email purposes, use the -kxa options.
639:
640:
641:
642: Viewing the Contents of Your Key Ring
643: -------------------------------------
644:
645: To view the contents of your public key ring:
646:
647: pgp -kv[v] [userid] [keyring]
648:
649: This lists any keys in the key ring that match the specified user ID
650: substring. If you omit the user ID, all of the keys in the key ring
651: are listed. The optional keyring file name is assumed to be
652: "pubring.pgp". It can be omitted, or you can specify "secring.pgp"
653: if you want to list secret keys. If you want to specify a different
654: key ring file name, you can. The default key ring extension is
655: ".pgp".
656:
657: To see all the certifying signatures attached to each key, use the
658: -kvv option:
659:
660: pgp -kvv [userid] [keyring]
661:
662: If you want to specify a particular key ring file name, but want to
663: see all the keys in it, try this alternative approach:
664:
665: pgp keyfile
666:
667: With no command options specified, PGP lists all the keys in
668: keyfile.pgp, and also attempts to add them to your key ring if they
669: are not already on your key ring.
670:
671:
672:
673: How to Protect Public Keys from Tampering
674: -----------------------------------------
675:
676: In a public key cryptosystem, you don't have to protect public keys
677: from exposure. In fact, it's better if they are widely disseminated.
678: But it is important to protect public keys from tampering, to make
679: sure that a public key really belongs to whom it appears to belong to.
680: This may be the most important vulnerability of a public-key
681: cryptosystem. Let's first look at a potential disaster, then at how
682: to safely avoid it with PGP.
683:
684: Suppose you wanted to send a private message to Alice. You download
685: Alice's public key certificate from an electronic bulletin board
686: system (BBS). You encrypt your letter to Alice with this public key
687: and send it to her through the BBS's E-mail facility.
688:
689: Unfortunately, unbeknownst to you or Alice, another user named
690: Charlie has infiltrated the BBS and generated a public key of his own
691: with Alice's user ID attached to it. He covertly substitutes his
692: bogus key in place of Alice's real public key. You unwittingly use
693: this bogus key belonging to Charlie instead of Alice's public key.
694: All looks normal because this bogus key has Alice's user ID. Now
695: Charlie can decipher the message intended for Alice because he has
696: the matching secret key. He may even re-encrypt the deciphered
697: message with Alice's real public key and send it on to her so that no
698: one suspects any wrongdoing. Furthermore, he can even make
699: apparently good signatures from Alice with this secret key because
700: everyone will use the bogus public key to check Alice's signatures.
701:
702: The only way to prevent this disaster is to prevent anyone from
703: tampering with public keys. If you got Alice's public key directly
704: from Alice, this is no problem. But that may be difficult if Alice
705: is a thousand miles away, or is currently unreachable.
706:
707: Perhaps you could get Alice's public key from a mutual trusted friend
708: David who knows he has a good copy of Alice's public key. David
709: could sign Alice's public key, vouching for the integrity of Alice's
710: public key. David would create this signature with his own secret
711: key.
712:
713: This would create a signed public key certificate, and would show
714: that Alice's key had not been tampered with. This requires you have a
715: known good copy of David's public key to check his signature. Perhaps
716: David could provide Alice with a signed copy of your public key also.
717: David is thus serving as an "introducer" between you and Alice.
718:
719: This signed public key certificate for Alice could be uploaded by
720: David or Alice to the BBS, and you could download it later. You
721: could then check the signature via David's public key and thus be
722: assured that this is really Alice's public key. No impostor can fool
723: you into accepting his own bogus key as Alice's because no one else
724: can forge signatures made by David.
725:
726: A widely trusted person could even specialize in providing this
727: service of "introducing" users to each other by providing signatures
728: for their public key certificates. This trusted person could be
729: regarded as a "key server", or as a "Certifying Authority". Any
730: public key certificates bearing the key server's signature could be
731: trusted as truly belonging to whom they appear to belong to. All
732: users who wanted to participate would need a known good copy of just
733: the key server's public key, so that the key server's signatures
734: could be verified.
735:
736: A trusted centralized key server or Certifying Authority is
737: especially appropriate for large impersonal centrally-controlled
738: corporate or government institutions. Some institutional
739: environments use hierarchies of Certifying Authorities.
740:
741: For more decentralized grassroots "guerrilla style" environments,
742: allowing all users to act as a trusted introducers for their friends
743: would probably work better than a centralized key server. PGP tends
744: to emphasize this organic decentralized non-institutional approach.
745: It better reflects the natural way humans interact on a personal
746: social level, and allows people to better choose who they can trust
747: for key management.
748:
749: This whole business of protecting public keys from tampering is the
750: single most difficult problem in practical public key applications.
751: It is the "Achilles heel" of public key cryptography, and a lot of
752: software complexity is tied up in solving this one problem.
753:
754: You should use a public key only after you are sure that it is a good
755: public key that has not been tampered with, and actually belongs to
756: the person it claims to. You can be sure of this if you got this
757: public key certificate directly from its owner, or if it bears the
758: signature of someone else that you trust, from whom you already have
759: a good public key. Also, the user ID should have the full name of
760: the key's owner, not just her first name.
761:
762: No matter how tempted you are-- and you will be tempted-- never,
763: NEVER give in to expediency and trust a public key you downloaded
764: from a bulletin board, unless it is signed by someone you trust.
765: That uncertified public key could have been tampered with by anyone,
766: maybe even by the system administrator of the bulletin board.
767:
768: If you are asked to sign someone else's public key certificate, make
769: certain that it really belongs to that person named in the user ID of
770: that public key certificate. This is because your signature on her
771: public key certificate is a promise by you that this public key
772: really belongs to her. Other people who trust you will accept her
773: public key because it bears your signature. It may be ill-advised to
774: rely on hearsay-- don't sign her public key unless you have
775: independent firsthand knowledge that it really belongs to her.
776: Preferably, you should sign it only if you got it directly from her.
777:
778: Bear in mind that your signature on a public key certificate does not
779: vouch for the integrity of that person, but only vouches for the
780: integrity (the ownership) of that person's public key. You aren't
781: risking your credibility by signing the public key of a sociopath, if
782: you were completely confident that the key really belonged to him.
783: Other people would accept that key as belonging to him because you
784: signed it (assuming they trust you), but they wouldn't trust that
785: key's owner. Trusting a key is not the same as trusting the key's
786: owner.
787:
788: Trust is not necessarily transferable; I have a friend who I trust
789: not to lie. He's a gullible person who trusts the President not to
790: lie. That doesn't mean I trust the President not to lie. This is
791: just common sense. If I trust Alice's signature on a key, and Alice
792: trusts Charlie's signature on a key, that does not imply that I have
793: to trust Charlie's signature on a key.
794:
795: It would be a good idea to keep your own public key on hand with a
796: collection of certifying signatures attached from a variety of
797: "introducers", in the hopes that most people will trust at least one
798: of the introducers who vouch for your own public key's validity.
799: You could post your key with its attached collection of certifying
800: signatures on various electronic bulletin boards. If you sign
801: someone else's public key, return it to them with your signature so
802: that they can add it to their own collection of credentials for their
803: own public key.
804:
805: PGP keeps track of which keys on your public keyring are properly
806: certified with signatures from introducers that you trust. All you
807: have to do is tell PGP which people you trust as introducers, and
808: certify their keys yourself with your own ultimately trusted key.
809: PGP can take it from there, automatically validating any other keys
810: that have been signed by your designated introducers. And of course
811: you may directly sign more keys yourself. More on this later.
812:
813: Make sure no one else can tamper with your own public key ring.
814: Checking a new signed public key certificate must ultimately depend
815: on the integrity of the trusted public keys that are already on your
816: own public key ring. Maintain physical control of your public key
817: ring, preferably on your own personal computer rather than on a
818: remote timesharing system, just as you would do for your secret key.
819: This is to protect it from tampering, not from disclosure. Keep a
820: trusted backup copy of your public key ring and your secret key ring
821: on write-protected media.
822:
823: Since your own trusted public key is used as a final authority to
824: directly or indirectly certify all the other keys on your keyring, it
825: is the most important key to protect from tampering. To detect any
826: tampering of your own ultimately-trusted public key, PGP can be set
827: up to automatically compare your public key against a backup copy on
828: write-protected media. For details, see the description of the "-kc"
829: keyring check command in the Special Topics volume.
830:
831: PGP generally assumes you will maintain physical security over your
832: system and your key rings, as well as your copy of PGP itself. If an
833: intruder can tamper with your disk, then in theory he can tamper with
834: PGP itself, rendering moot the safeguards PGP may have to detect
835: tampering with keys.
836:
837: One somewhat complicated way to protect your own whole public key ring
838: from tampering is to sign the whole ring with your own secret key.
839: You could do this by making a detached signature certificate of the
840: public key ring, by signing the ring with the "-sb" options (see the
841: section called "Separating Signatures from Messages" in the PGP
842: User's Guide, Special Topics volume). Unfortunately, you would still
843: have to keep a separate trusted copy of your own public key around to
844: check the signature you made. You couldn't rely on your own public
845: key stored on your public key ring to check the signature you made
846: for the whole ring, because that is part of what you're trying to
847: check.
848:
849:
850:
851: How Does PGP Keep Track of Which Keys are Valid?
852: ------------------------------------------------
853:
854: Before you read this section, be sure to read the above section on
855: "How to Protect Public Keys from Tampering".
856:
857: PGP keeps track of which keys on your public keyring are properly
858: certified with signatures from introducers that you trust. All you
859: have to do is tell PGP which people you trust as introducers, and
860: certify their keys yourself with your own ultimately trusted key.
861: PGP can take it from there, automatically validating any other keys
862: that have been signed by your designated introducers. And of course
863: you may directly sign more keys yourself.
864:
865: There are two entirely separate criteria PGP uses to judge a public
866: key's usefulness:
867:
868: 1) Does the key actually belong to whom it appears to belong?
869: In other words, has it been certified with a trusted signature?
870: 2) Does it belong to someone we can trust to certify other keys?
871:
872: PGP can calculate the answer to the first question. To answer the
873: second question, PGP must be explicitly told by you, the user. When
874: you supply the answer to question 2, PGP can then calculate the
875: answer to question 1 for other keys signed by the introducer you
876: designated as trusted.
877:
878: Keys that have been certified by a trusted introducer are deemed
879: valid by PGP. The keys belonging to trusted introducers must
880: themselves be certified either by you or by other trusted
881: introducers.
882:
883: PGP also allows for the possibility of you having several shades of
884: trust for people to act as introducers. Your trust for a key's owner
885: to act as an introducer does not just reflect your estimation of
886: their personal integrity-- it should also reflect how competent you
887: think they are at understanding key management and using good
888: judgement in signing keys. You can designate a person to PGP as
889: unknown, untrusted, marginally trusted, or completely trusted to
890: certify other public keys. This trust information is stored on your
891: keyring with their key, but when you tell PGP to copy a key off your
892: keyring, PGP will not copy the trust information along with the key,
893: because your private opinions on trust are regarded as confidential.
894:
895: When PGP is calculating the validity of a public key, it examines the
896: trust level of all the attached certifying signatures. It computes a
897: weighted score of validity-- two marginally trusted signatures are
898: deemed as credible as one fully trusted signature. PGP's skepticism
899: is adjustable-- for example, you may tune PGP to require two fully
900: trusted signatures or three marginally trusted signatures to judge a
901: key as valid.
902:
903: Your own key is "axiomatically" valid to PGP, needing no introducer's
904: signature to prove its validity. PGP knows which public keys are
905: yours, by looking for the corresponding secret keys on the secret
906: keyring. PGP also assumes you ultimately trust yourself to certify
907: other keys.
908:
909: As time goes on, you will accumulate keys from other people that you
910: may want to designate as trusted introducers. Everyone else will
911: each choose their own trusted introducers. And everyone will
912: gradually accumulate and distribute with their key a collection of
913: certifying signatures from other people, with the expectation that
914: anyone receiving it will trust at least one or two of the signatures.
915: This will cause the emergence of a decentralized fault-tolerant web
916: of confidence for all public keys.
917:
918: This unique grass-roots approach contrasts sharply with Government
919: standard public key management schemes, such as Internet Privacy
920: Enhanced Mail (PEM), which are based on centralized control and
921: mandatory centralized trust. The standard schemes rely on a
922: hierarchy of Certifying Authorities who dictate who you must trust.
923: PGP's decentralized probabilistic method for determining public key
924: legitimacy is the centerpiece of its key management architecture.
925: PGP lets you alone choose who you trust, putting you at the top of
926: your own private certification pyramid. PGP is for people who prefer
927: to pack their own parachutes.
928:
929:
930:
931: How to Protect Secret Keys from Disclosure
932: ------------------------------------------
933:
934: Protect your own secret key and your pass phrase carefully. Really,
935: really carefully. If your secret key is ever compromised, you'd
936: better get the word out quickly to all interested parties (good luck)
937: before someone else uses it to make signatures in your name. For
938: example, they could use it to sign bogus public key certificates,
939: which could create problems for many people, especially if your
940: signature is widely trusted. And of course, a compromise of your own
941: secret key could expose all messages sent to you.
942:
943: To protect your secret key, you can start by always keeping physical
944: control of your secret key. Keeping it on your personal computer at
945: home is OK, or keep it in your notebook computer that you can carry
946: with you. If you must use an office computer that you don't always
947: have physical control of, then keep your public and secret key rings
948: on a write-protected removable floppy disk, and don't leave it behind
949: when you leave the office. It wouldn't be a good idea to allow your
950: secret key to reside on a remote timesharing computer, such as a
951: remote dial-in Unix system. Someone could eavesdrop on your modem
952: line and capture your pass phrase, and then obtain your actual secret
953: key from the remote system. You should only use your secret key on a
954: machine that you have physical control over.
955:
956: Don't store your pass phrase anywhere on the computer that has your
957: secret key file. Storing both the secret key and the pass phrase on
958: the same computer is as dangerous as keeping your PIN in the same
959: wallet as your Automatic Teller Machine bank card. You don't want
960: somebody to get their hands on your disk containing both the pass
961: phrase and the secret key file. It would be most secure if you just
962: memorize your pass phrase and don't store it anywhere but your brain.
963: If you feel you must write down your pass phrase, keep it well
964: protected, perhaps even more well protected than the secret key file.
965:
966: And keep backup copies of your secret key ring-- remember, you have
967: the only copy of your secret key, and losing it will render useless
968: all the copies of your public key that you have spread throughout the
969: world.
970:
971: The decentralized non-institutional approach PGP uses to manage
972: public keys has its benefits, but unfortunately this also means we
973: can't rely on a single centralized list of which keys have been
974: compromised. This makes it a bit harder to contain the damage of a
975: secret key compromise. You just have to spread the word and hope
976: everyone hears about it.
977:
978: If the worst case happens-- your secret key and pass phrase are both
979: compromised (hopefully you will find this out somehow)-- you will
980: have to issue a "key compromise" certificate. This kind of
981: certificate is used to warn other people to stop using your public
982: key. You can use PGP to create such a certificate by using the "-kd"
983: command. Then you must somehow send this compromise certificate to
984: everyone else on the planet, or at least to all your friends and
985: their friends, et cetera. Their own PGP software will install this
986: key compromise certificate on their public keyrings and will
987: automatically prevent them from accidentally using your public key
988: ever again. You can then generate a new secret/public key pair and
989: publish the new public key. You could send out one package containing
990: both your new public key and the key compromise certificate for your
991: old key.
992:
993:
994:
995: Revoking a Public Key
996: ---------------------
997:
998: Suppose your secret key and your pass phrase are somehow both
999: compromised. You have to get the word out to the rest of the world,
1000: so that they will all stop using your public key. To do this, you
1001: will have to issue a "key compromise" certificate to revoke your
1002: public key.
1003:
1004: To generate a key compromise certificate, use the -kd command:
1005:
1006: pgp -kd your_userid
1007:
1008: You should widely disseminate this key compromise certificate as soon
1009: as possible. Other people who receive it can add it to their public
1010: keyrings, and their PGP software then automatically prevents them
1011: from accidentally using your old public key ever again. You can then
1012: generate a new secret/public key pair and publish the new public key.
1013:
1014: You may choose to revoke your key for some other reason than the
1015: compromise of a secret key. If so, you may still use the same
1016: mechanism to revoke it.
1017:
1018:
1019:
1020: Advanced Topics
1021: ===============
1022:
1023: Most of the "Advanced Topics" are covered in the "PGP User's Guide,
1024: Volume II: Special Topics". But here are a few topics that bear
1025: mentioning here.
1026:
1027:
1028: Sending Ciphertext Through E-mail Channels: Radix-64 Format
1029: -----------------------------------------------------------
1030:
1031: Many electronic mail systems only allow messages made of ASCII text,
1032: not the 8-bit raw binary data that ciphertext is made of. To get
1033: around this problem, PGP supports ASCII radix-64 format for
1034: ciphertext messages, similar to the Internet Privacy-Enhanced Mail
1035: (PEM) format. This special format represents binary data by using
1036: only printable ASCII characters, so it is useful for transmitting
1037: binary encrypted data through 7-bit channels or for sending binary
1038: encrypted data as normal E-mail text. This format acts as a form of
1039: "transport armor", protecting it against corruption as it travels
1040: through intersystem gateways on Internet. It also appends a CRC to
1041: detect transmission errors.
1042:
1043: Radix-64 format converts the plaintext by expanding groups of 3
1044: binary 8-bit bytes into 4 printable ASCII characters, so the file
1045: grows by about 33%. But this expansion isn't so bad when you
1046: consider that the file probably was compressed more than that by PGP
1047: before it was encrypted.
1048:
1049: To produce a ciphertext file in ASCII radix-64 format, just add the
1050: "a" option when encrypting or signing a message, like so:
1051:
1052: pgp -esa message.txt her_userid
1053:
1054: This example produces a ciphertext file called "message.asc" that
1055: contains data in a PEM-like ASCII radix-64 format. This file can be
1056: easily uploaded into a text editor through 7-bit channels for
1057: transmission as normal E-mail on Internet or any other E-mail
1058: network.
1059:
1060: Decrypting the radix-64 transport-armored message is no different than
1061: a normal decrypt. For example:
1062:
1063: pgp message
1064:
1065: PGP automatically looks for the ASCII file "message.asc" before it
1066: looks for the binary file "message.pgp". It recognizes that the file
1067: is in radix-64 format and converts it back to binary before
1068: processing as it normally does, producing as a by-product a ".pgp"
1069: ciphertext file in binary form. The final output file is in normal
1070: plaintext form, just as it was in the original file "message.txt".
1071:
1072: Most Internet E-mail facilities prohibit sending messages that are
1073: more than 50000 bytes long. Longer messages must be broken into
1074: smaller chunks that can be mailed separately. If your encrypted
1075: message is very large, and you requested radix-64 format, PGP
1076: automatically breaks it up into chunks that are each small enough to
1077: send via E-mail. The chunks are put into files named with extensions
1078: ".as1", ".as2", ".as3", etc. The recipient must concatenate these
1079: separate files back together in their proper order into one big file
1080: before decrypting it. While decrypting, PGP ignores any extraneous
1081: text in mail headers that are not enclosed in the radix-64 message
1082: blocks.
1083:
1084: If you want to send a public key to someone else in radix-64 format,
1085: just add the -a option while extracting the key from your keyring.
1086:
1087: If you forgot to use the -a option when you made a ciphertext file or
1088: extracted a key, you may still directly convert the binary file into
1089: radix-64 format by simply using the -a option alone, without any
1090: encryption specified. PGP converts it to a ".asc" file.
1091:
1092:
1093:
1094: Environmental Variable for Path Name
1095: ------------------------------------
1096:
1097: PGP uses several special files for its purposes, such as your
1098: standard key ring files "pubring.pgp" and "secring.pgp", the random
1099: number seed file "randseed.bin", the PGP configuration file
1100: "config.txt", and the foreign language string translation file
1101: "language.txt". These special files can be kept in any directory, by
1102: setting the environmental variable "PGPPATH" to the desired pathname.
1103: For example, on MSDOS, the shell command:
1104:
1105: SET PGPPATH=C:\PGP
1106:
1107: makes PGP assume that your public key ring filename is
1108: "C:\PGP\pubring.pgp". Assuming, of course, that this directory
1109: exists. Use your favorite text editor to modify your MSDOS
1110: AUTOEXEC.BAT file to automatically set up this variable whenever you
1111: start up your system. If PGPPATH remains undefined, these special
1112: files are assumed to be in the current directory.
1113:
1114:
1115:
1116: Setting Configuration Parameters: CONFIG.TXT
1117: --------------------------------------------
1118:
1119: PGP has a number of user-settable parameters that can be defined in a
1120: special configuration text file called "config.txt", in the directory
1121: pointed to by the shell environmental variable PGPPATH. Having a
1122: configuration file enables the user to define various flags and
1123: parameters for PGP without the burden of having to always define
1124: these parameters in the PGP command line.
1125:
1126: With these configuration parameters, for example, you can control
1127: where PGP stores its temporary scratch files, or you can select what
1128: foreign language PGP will use to display its diagnostics messages and
1129: user prompts, or you can adjust PGP's level of skepticism in
1130: determining a key's validity based on the number of certifying
1131: signatures it has.
1132:
1133: For more details on setting these configuration parameters, see the
1134: appropriate section of the PGP User's Guide, Special Topics volume.
1135:
1136:
1137:
1138: Vulnerabilities
1139: ---------------
1140:
1141: No data security system is impenetrable. PGP can be circumvented in
1142: a variety of ways. Potential vulnerabilities you should be aware of
1143: include compromising your pass phrase or secret key, public key
1144: tampering, files that you deleted but are still somewhere on the
1145: disk, viruses and Trojan horses, breaches in your physical security,
1146: electromagnetic emissions, exposure on multi-user systems, traffic
1147: analysis, and perhaps even direct cryptanalysis.
1148:
1149: For a detailed discussion of these issues, see the "Vulnerabilities"
1150: section in the PGP User's Guide, Special Topics volume.
1151:
1152:
1153: Trusting Snake Oil
1154: ==================
1155:
1156: When examining a cryptographic software package, the question always
1157: remains, why should you trust this product? Even if you examined the
1158: source code yourself, not everyone has the cryptographic experience
1159: to judge the security. Even if you are an experienced cryptographer,
1160: subtle weaknesses in the algorithms could still elude you.
1161:
1162: When I was in college in the early seventies, I devised what I
1163: believed was a brilliant encryption scheme. A simple pseudorandom
1164: number stream was added to the plaintext stream to create
1165: ciphertext. This would seemingly thwart any frequency analysis of
1166: the ciphertext, and would be uncrackable even to the most resourceful
1167: Government intelligence agencies. I felt so smug about my
1168: achievement. So cock-sure.
1169:
1170: Years later, I discovered this same scheme in several introductory
1171: cryptography texts and tutorial papers. How nice. Other
1172: cryptographers had thought of the same scheme. Unfortunately, the
1173: scheme was presented as a simple homework assignment on how to use
1174: elementary cryptanalytic techniques to trivially crack it. So much
1175: for my brilliant scheme.
1176:
1177: From this humbling experience I learned how easy it is to fall into a
1178: false sense of security when devising an encryption algorithm. Most
1179: people don't realize how fiendishly difficult it is to devise an
1180: encryption algorithm that can withstand a prolonged and determined
1181: attack by a resourceful opponent. Many mainstream software engineers
1182: have developed equally naive encryption schemes (often even the very
1183: same encryption scheme), and some of them have been incorporated into
1184: commercial encryption software packages and sold for good money to
1185: thousands of unsuspecting users.
1186:
1187: This is like selling automotive seat belts that look good and feel
1188: good, but snap open in even the slowest crash test. Depending on
1189: them may be worse than not wearing seat belts at all. No one
1190: suspects they are bad until a real crash. Depending on weak
1191: cryptographic software may cause you to unknowingly place sensitive
1192: information at risk. You might not otherwise have done so if you had
1193: no cryptographic software at all. Perhaps you may never even
1194: discover your data has been compromised.
1195:
1196: Sometimes commercial packages use the Federal Data Encryption
1197: Standard (DES), a good conventional algorithm recommended by the
1198: Government for commercial use (but not for classified information,
1199: oddly enough-- hmmm). There are several "modes of operation" the
1200: DES can use, some of them better than others. The Government
1201: specifically recommends not using the weakest simplest mode for
1202: messages, the Electronic Codebook (ECB) mode. But they do recommend
1203: the stronger and more complex Cipher Feedback (CFB) or Cipher Block
1204: Chaining (CBC) modes.
1205:
1206: Unfortunately, most of the commercial encryption packages I've looked
1207: at use ECB mode. When I've talked to the authors of a number of
1208: these implementations, they say they've never heard of CBC or CFB
1209: modes, and didn't know anything about the weaknesses of ECB mode.
1210: The very fact that they haven't even learned enough cryptography to
1211: know these elementary concepts is not reassuring. These same
1212: software packages often include a second faster encryption algorithm
1213: that can be used instead of the slower DES. The author of the
1214: package often thinks his proprietary faster algorithm is as secure as
1215: the DES, but after questioning him I usually discover that it's just
1216: a variation of my own brilliant scheme from college days. Or maybe
1217: he won't even reveal how his proprietary encryption scheme works, but
1218: assures me it's a brilliant scheme and I should trust it. I'm sure
1219: he believes that his algorithm is brilliant, but how can I know that
1220: without seeing it?
1221:
1222: In all fairness I must point out that in most cases these products do
1223: not come from companies that specialize in cryptographic technology.
1224:
1225: There is a company called AccessData (87 East 600 South, Orem, Utah
1226: 84058, phone 1-800-658-5199) that sells a package for $185 that
1227: cracks the built-in encryption schemes used by WordPerfect, Lotus
1228: 1-2-3, MS Excel, Symphony, Quattro Pro, Paradox, and MS Word 2.0. It
1229: doesn't simply guess passwords-- it does real cryptanalysis. Some
1230: people buy it when they forget their password for their own files.
1231: Law enforcement agencies buy it too, so they can read files they
1232: seize. I talked to Eric Thompson, the author, and he said his
1233: program only takes a split second to crack them, but he put in some
1234: delay loops to slow it down so it doesn't look so easy to the
1235: customer. He also told me that the password encryption feature of
1236: PKZIP files can be easily broken, and that his law enforcement
1237: customers already have that service regularly provided to them from
1238: another vendor.
1239:
1240: In some ways, cryptography is like pharmaceuticals. Its integrity
1241: may be absolutely crucial. Bad penicillin looks the same as good
1242: penicillin. You can tell if your spreadsheet software is wrong, but
1243: how do you tell if your cryptography package is weak? The ciphertext
1244: produced by a weak encryption algorithm looks as good as ciphertext
1245: produced by a strong encryption algorithm. There's a lot of snake
1246: oil out there. A lot of quack cures. Unlike the patent medicine
1247: hucksters of old, these software implementors usually don't even know
1248: their stuff is snake oil. They may be good software engineers, but
1249: they usually haven't even read any of the academic literature in
1250: cryptography. But they think they can write good cryptographic
1251: software. And why not? After all, it seems intuitively easy to do
1252: so. And their software seems to work okay.
1253:
1254: Anyone who thinks they have devised an unbreakable encryption scheme
1255: either is an incredibly rare genius or is naive and inexperienced.
1256:
1257: I remember a conversation with Brian Snow, a highly placed senior
1258: cryptographer with the NSA. He said he would never trust an
1259: encryption algorithm designed by someone who had not "earned their
1260: bones" by first spending a lot of time cracking codes. That did make
1261: a lot of sense. I observed that practically no one in the commercial
1262: world of cryptography qualified under this criterion. "Yes", he said
1263: with a self assured smile, "And that makes our job at NSA so much
1264: easier." A chilling thought. I didn't qualify either.
1265:
1266: The Government has peddled snake oil too. After World War II, the US
1267: sold German Enigma ciphering machines to third world governments.
1268: But they didn't tell them that the Allies cracked the Enigma code
1269: during the war, a fact that remained classified for many years. Even
1270: today many Unix systems worldwide use the Enigma cipher for file
1271: encryption, in part because the Government has created legal
1272: obstacles against using better algorithms. They even tried to
1273: prevent the initial publication of the RSA algorithm in 1977. And
1274: they have squashed essentially all commercial efforts to develop
1275: effective secure telephones for the general public.
1276:
1277: The principle job of the US Government's National Security Agency is
1278: to gather intelligence, principally by covertly tapping into people's
1279: private communications (see James Bamford's book, "The Puzzle
1280: Palace"). The NSA has amassed considerable skill and resources for
1281: cracking codes. When people can't get good cryptography to protect
1282: themselves, it makes NSA's job much easier. NSA also has the
1283: responsibility of approving and recommending encryption algorithms.
1284: Some critics charge that this is a conflict of interest, like putting
1285: the fox in charge of guarding the hen house. NSA has been pushing a
1286: conventional encryption algorithm that they designed, and they won't
1287: tell anybody how it works because that's classified. They want
1288: others to trust it and use it. But any cryptographer can tell you
1289: that a well-designed encryption algorithm does not have to be
1290: classified to remain secure. Only the keys should need protection.
1291: How does anyone else really know if NSA's classified algorithm is
1292: secure? It's not that hard for NSA to design an encryption algorithm
1293: that only they can crack, if no one else can review the algorithm.
1294: Are they deliberately selling snake oil?
1295:
1296: I'm not as certain about the security of PGP as I once was about my
1297: brilliant encryption software from college. If I were, that would be
1298: a bad sign. But I'm pretty sure that PGP does not contain any
1299: glaring weaknesses. The crypto algorithms were developed by people
1300: at high levels of civilian cryptographic academia, and have been
1301: individually subject to extensive peer review. Source code is
1302: available to facilitate peer review of PGP and to help dispel the
1303: fears of some users. It's reasonably well researched, and has been
1304: years in the making. And I don't work for the NSA. I hope it
1305: doesn't require too large a "leap of faith" to trust the security of
1306: PGP.
1307:
1308:
1309: PGP Quick Reference
1310: ===================
1311:
1312: Here's a quick summary of PGP commands.
1313:
1314:
1315: To encrypt a plaintext file with the recipient's public key:
1316: pgp -e textfile her_userid
1317:
1318: To sign a plaintext file with your secret key:
1319: pgp -s textfile [-u your_userid]
1320:
1321: To sign a plaintext file with your secret key, and then encrypt it
1322: with the recipient's public key:
1323: pgp -es textfile her_userid [-u your_userid]
1324:
1325: To encrypt a plaintext file with just conventional cryptography, type:
1326: pgp -c textfile
1327:
1328: To decrypt an encrypted file, or to check the signature integrity of a
1329: signed file:
1330: pgp ciphertextfile [-o plaintextfile]
1331:
1332: --- Key management commands:
1333:
1334: To generate your own unique public/secret key pair:
1335: pgp -kg
1336:
1337: To add a public or secret key file's contents to your public or
1338: secret key ring:
1339: pgp -ka keyfile [keyring]
1340:
1341: To extract (copy) a key from your public or secret key ring:
1342: pgp -kx userid keyfile [keyring]
1343: or: pgp -kxa userid keyfile [keyring]
1344:
1345: To view the contents of your public key ring:
1346: pgp -kv[v] [userid] [keyring]
1347:
1348: To view the contents and check the certifying signatures of your
1349: public key ring:
1350: pgp -kc [userid] [keyring]
1351:
1352: To edit the userid or pass phrase for your secret key:
1353: pgp -ke userid [keyring]
1354:
1355: To edit the trust parameters for a public key:
1356: pgp -ke userid [keyring]
1357:
1358: To remove a key or just a userid from your public key ring:
1359: pgp -kr userid [keyring]
1360:
1361: To sign and certify someone else's public key on your public key ring:
1362: pgp -ks her_userid [-u your_userid] [keyring]
1363:
1364: To remove selected signatures from a userid on a keyring:
1365: pgp -krs userid [keyring]
1366:
1367: --- Esoteric commands:
1368:
1369: To decrypt a message and leave the signature on it intact:
1370: pgp -d ciphertextfile
1371:
1372: To create a signature certificate that is detached from the document:
1373: pgp -sb textfile [-u your_userid]
1374:
1375: To detach a signature certificate from a signed message:
1376: pgp -b ciphertextfile
1377:
1378: --- Command options that can be used in combination with other
1379: command options (sometimes even spelling interesting words!):
1380:
1381: To produce a ciphertext file in ASCII radix-64 format, just add the
1382: -a option when encrypting or signing a message or extracting a key:
1383: pgp -sea textfile her_userid
1384: or: pgp -kxa userid keyfile [keyring]
1385:
1386: To wipe out the plaintext file after producing the ciphertext file,
1387: just add the -w (wipe) option when encrypting or signing a message:
1388: pgp -sew message.txt her_userid
1389:
1390: To specify that a plaintext file contains ASCII text, not binary, and
1391: should be converted to recipient's local text line conventions, add
1392: the -t (text) option to other options:
1393: pgp -seat message.txt her_userid
1394:
1395: To view the decrypted plaintext output on your screen (like the
1396: Unix-style "more" command), without writing it to a file, use
1397: the -m (more) option while decrypting:
1398: pgp -m ciphertextfile
1399:
1400: To specify that the recipient's decrypted plaintext will be shown
1401: ONLY on her screen and cannot be saved to disk, add the -m option:
1402: pgp -steam message.txt her_userid
1403:
1404: To recover the original plaintext filename while decrypting, add
1405: the -p option:
1406: pgp -p ciphertextfile
1407:
1408: To use a Unix-style filter mode, reading from standard input and
1409: writing to standard output, add the -f option:
1410: pgp -feast her_userid <inputfile >outputfile
1411:
1412:
1413:
1414: Legal Issues
1415: ============
1416:
1417: For detailed information on PGP licensing, distribution, copyrights,
1418: patents, trademarks, liability limitations, and export controls, see
1419: the "Legal Issues" section in the "PGP User's Guide, Volume II:
1420: Special Topics".
1421:
1422: PGP uses a public key algorithm claimed by U.S. patent #4,405,829.
1423: The exclusive rights to this patent are held by a California company
1424: called Public Key Partners, and you may be infringing this patent if
1425: you use PGP in the USA. This is explained in the Volume II manual.
1426:
1427: PGP is "guerrilla" freeware, and I don't mind if you distribute it
1428: widely. Just don't ask me to send you a copy. Instead, you can get
1429: it yourself from many BBS systems and a number of Internet FTP sites.
1430:
1431:
1432:
1433: Acknowledgments
1434: ================
1435:
1436: I'd like to thank the following people for their contributions to the
1437: creation of Pretty Good Privacy. Although I was the author of PGP
1438: version 1.0, major parts of later versions of PGP were implemented by
1439: an international collaborative effort involving a large number of
1440: contributors.
1441:
1442: Branko Lankester, Hal Finney and Peter Gutmann all contributed a
1443: huge amount of time in adding features for PGP 2.0, and ported it to
1444: Unix variants. Hal and Branko made Herculean efforts in implementing
1445: my new key management protocols.
1446:
1447: Hugh Kennedy ported it to VAX/VMS, Lutz Frank ported it to the Atari
1448: ST, and Cor Bosman ported it to the Commodore Amiga.
1449:
1450: Translation of PGP into foreign languages was done by Jean-loup
1451: Gailly in France, Armando Ramos in Spain, Felipe Rodriquez Svensson
1452: and Branko Lankester in The Netherlands, Miguel Angel Gallardo in
1453: Spain, Lutz Frank and Hugh Kennedy in Germany, David Vincenzetti in
1454: Italy, Harry Bush and Maris Gabalins in Latvia, Zygimantas Cepaitis
1455: in Lithuania, Peter Suchkow and Andrew Chernov in Russia, and
1456: Alexander Smishlajev in Esperantia. Peter Gutmann offered to
1457: translate it into New Zealand English, but we finally decided PGP
1458: could get by with US English.
1459:
1460: Jean-loup Gailly, Mark Adler, and Richard B. Wales published the ZIP
1461: compression code, and granted permission for inclusion into PGP. The
1462: MD5 routines were developed and placed in the public domain by Ron
1463: Rivest. The IDEA(tm) cipher was developed by Xuejia Lai and James L.
1464: Massey at ETH in Zurich, and is used in PGP with permission from
1465: Ascom-Tech AG.
1466:
1467: Charlie Merritt originally taught me how to do decent multiprecision
1468: arithmetic for public key cryptography, and Jimmy Upton contributed a
1469: faster multiply/modulo algorithm. Zhahai Stewart contributed a lot
1470: of useful ideas on PGP file formats and other stuff, including having
1471: more than one user ID for a key. I heard the idea of introducers
1472: from Whit Diffie. Kelly Goen did most of the work for the initial
1473: electronic publication of PGP 1.0.
1474:
1475:
1476:
1477: About the Author
1478: ================
1479:
1480: Philip Zimmermann is a software engineer consultant with 18 years
1481: experience, specializing in embedded real-time systems, cryptography,
1482: authentication, and data communications. Experience includes design
1483: and implementation of authentication systems for financial
1484: information networks, network data security, key management
1485: protocols, embedded real-time multitasking executives, operating
1486: systems, and local area networks.
1487:
1488: Custom versions of cryptography and authentication products and
1489: public key implementations such as the NIST DSS are available from
1490: Zimmermann, as well as custom product development services. His
1491: consulting firm's address is:
1492:
1493: Boulder Software Engineering
1494: 3021 Eleventh Street
1495: Boulder, Colorado 80304 USA
1496: Phone 303-541-0140 (voice or FAX) (10:00am - 7:00pm Mountain Time)
1497: Internet: [email protected]
1498:
1499:
1500:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.