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