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