![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to pgpdoc2.txt CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [PGP] / pgp|
Return to pgpdoc2.txt CVS log | Up to [PGP] / pgp |
1.1 root 1: Phil's Pretty Good Software
2: Presents
3:
4: ===
5: PGP
6: ===
7:
8: Pretty Good Privacy
9: Public Key Encryption for the Masses
10:
11:
12: -------------------------
13: PGP User's Guide
14: Volume II: Special Topics
15: -------------------------
16: by Philip Zimmermann
17: Revised 1 Sep 92
18:
19:
20: PGP Version 2.0 - 1 Sep 92
21: Software Written by
22: Philip Zimmermann
23: with
24: Hal Finney, Branko Lankester, and Peter Gutmann
25:
26:
27:
28:
29: Synopsis: PGP uses public-key encryption to protect E-mail and data
30: files. Communicate securely with people you've never met, with no
31: secure channels needed for prior exchange of keys. PGP is well
32: featured and fast, with sophisticated key management, digital
33: signatures, data compression, and good ergonomic design.
34:
35:
36: Software and documentation (c) Copyright 1990-1992 Philip Zimmermann.
37: For information on PGP licensing, distribution, copyrights, patents,
38: trademarks, liability limitations, and export controls, see the
39: "Legal Issues" section.
40:
41:
42: Contents
43: ========
44:
45: Quick Overview
46: Special Topics
47: Separating Signatures from Messages
48: Decrypting the Message and Leaving the Signature on it
49: Sending ASCII Text Files Across Different Machine Environments
50: Leaving No Traces of Plaintext on the Disk
51: Displaying Decrypted Plaintext on Your Screen
52: Making a Message For Her Eyes Only
53: Preserving the Original Plaintext Filename
54: Editing Your User ID or Pass Phrase
55: Editing the Trust Parameters for a Public Key
56: Checking If Everything is OK on Your Public Key Ring
57: Using PGP as a Unix-style Filter
58: PGP Returns Exit Status to the Shell
59: Environmental Variable for Pass Phrase
60: Setting Configuration Parameters: CONFIG.TXT
61: TMP - Directory Pathname for Temporary Files
62: LANGUAGE - Foreign Language Selector
63: MYNAME - Default User ID for Making Signatures
64: TEXTMODE - Assuming Plaintext is a Text File
65: CHARSET - Specifies Local Character Set for Text Files
66: ARMOR - Enable ASCII Armor Output
67: ARMORLINES - Size of ASCII Armor Multipart Files
68: KEEPBINARY - Keep Binary Ciphertext Files After Decrypting
69: VERBOSE - Enable Verbose Mode
70: COMPRESS - Enable Compression
71: BAKRING - Filename for Backup Secret Keyring
72: COMPLETES_NEEDED - Number of Completely Trusted Introducers Needed
73: MARGINALS_NEEDED - Number of Marginally Trusted Introducers Needed
74: CERT_DEPTH - How Deep May Introducers Be Nested
75: PAGER - Selects Shell Command to Display Plaintext Output
76: SHOWPASS - Echo Pass Phrase to User
77: TZFIX - Timezone Adjustment
78: Protecting Against Bogus Timestamps
79: A Peek Under the Hood
80: Random Numbers
81: PGP's Conventional Encryption Algorithm
82: Data Compression
83: Message Digests and Digital Signatures
84: Compatibility with Previous Versions of PGP
85: Vulnerabilities
86: Compromised Pass Phrase and Secret Key
87: Public Key Tampering
88: "Not Quite Deleted" Files
89: Viruses and Trojan Horses
90: Physical Security Breach
91: Tempest Attacks
92: Exposure on Multi-user Systems
93: Traffic Analysis
94: Cryptanalysis
95: Legal Issues
96: Trademarks, Copyrights, and Warranties
97: Patent Rights on the Algorithms
98: Licensing and Distribution
99: Export Controls
100: Recommended Readings
101: To Contact the Author
102:
103:
104: Quick Overview
105: =============
106:
107: Pretty Good(tm) Privacy (PGP), from Phil's Pretty Good Software, is a
108: high security cryptographic software application for MSDOS, Unix,
109: VAX/VMS, and other computers. PGP combines the convenience of the
110: Rivest-Shamir-Adleman (RSA) public key cryptosystem with the speed of
111: conventional cryptography, message digests for digital signatures,
112: data compression before encryption, good ergonomic design, and
113: sophisticated key management.
114:
115: This volume II of the PGP User's Guide covers advanced topics about
116: PGP that were not covered in the "PGP User's Guide, Volume I:
117: Essential Topics". You should first read the Essential Topics
118: volume, or this manual won't make much sense to you. Reading this
119: Special Topics volume is optional.
120:
121:
122:
123: Special Topics
124: ===============
125:
126: Separating Signatures from Messages
127: -----------------------------------
128:
129: Normally, signature certificates are physically attached to the text
130: they sign. This makes it convenient in simple cases to check
131: signatures. It is desirable in some circumstances to have signature
132: certificates stored separately from the messages they sign. It is
133: possible to generate signature certificates that are detached from
134: the text they sign. To do this, combine the 'b' (break) option with
135: the 's' (sign) option. For example:
136:
137: pgp -sb letter.txt
138:
139: This example produces an isolated signature certificate in a file
140: called "letter.sig". The contents of letter.txt are not appended to
141: the signature certificate.
142:
143: After creating the signature certificate file (letter.sig in the
144: above example), send it along with the original text file to the
145: recipient. The recipient must have both files to check the signature
146: integrity. When the recipient attempts to process the signature
147: file, PGP notices that there is no text in the same file with the
148: signature and prompts the user for the filename of the text. Only
149: then can PGP properly check the signature integrity. If the
150: recipient knows in advance that the signature is detached from the
151: text file, she can specify both filenames on the command line:
152:
153: pgp letter.sig letter.txt
154: or: pgp letter letter.txt
155:
156: PGP will not have to prompt for the text file name in this case.
157:
158: A detached signature certificate is useful if you want to keep the
159: signature certificate in a separate certificate log. A detached
160: signature of an executable program is also useful for detecting a
161: subsequent virus infection. It is also useful if more than one party
162: must sign a document such as a legal contract, without nesting
163: signatures. Each person's signature is independent.
164:
165: If you receive a ciphertext file that has the signature certificate
166: glued to the message, you can still pry the signature certificate
167: away from the message during the decryption. You can do this with
168: the -b option during decrypt, like so:
169:
170: pgp -b letter
171:
172: This decrypts the letter.pgp file and if there is a signature in it,
173: PGP checks the signature and detaches it from the rest of the
174: message, storing it in the file letter.sig.
175:
176:
177: Decrypting the Message and Leaving the Signature on it
178: ------------------------------------------------------
179:
180: Usually, you want PGP to completely unravel a ciphertext file,
181: decrypting it and checking the nested signature if there is one,
182: peeling away the layers until you are left with only the original
183: plaintext file.
184:
185: But sometimes you want to decrypt an encrypted file, and leave the
186: inner signature still attached, so that you are left with a decrypted
187: signed message. This may be useful if you want to send a copy of a
188: signed document to a third party, perhaps re-enciphering it. For
189: example, suppose you get a message signed by Charlie, encrypted to
190: you. You want to decrypt it, and, leaving Charlie's signature on it,
191: you want to send it to Alice, perhaps re-enciphering it with Alice's
192: public key. No problem. PGP can handle that.
193:
194: To simply decrypt a message and leave the signature on it intact,
195: type:
196:
197: pgp -d letter
198:
199: This decrypts letter.pgp, and if there is an inner signature, it is
200: left intact with the decrypted plaintext in the output file.
201:
202: Now you can archive it, or maybe re-encrypt it and send it to someone
203: else.
204:
205:
206:
207: Sending ASCII Text Files Across Different Machine Environments
208: --------------------------------------------------------------
209:
210: You may use PGP to encrypt any kind of plaintext file, binary 8-bit
211: data or ASCII text. Probably the most common usage of PGP will be for
212: E-mail, when the plaintext is ASCII text.
213:
214: ASCII text is sometimes represented differently on different
215: machines. For example, on an MSDOS system, all lines of ASCII text
216: are terminated with a carriage return followed by a linefeed. On a
217: Unix system, all lines end with just a linefeed. On a Macintosh, all
218: lines end with just a carriage return. This is a sad fact of life.
219:
220: Normal unencrypted ASCII text messages are often automatically
221: translated to some common "canonical" form when they are transmitted
222: from one machine to another. Canonical text has a carriage return
223: and a linefeed at the end of each line of text. For example, the
224: popular KERMIT communication protocol can convert text to canonical
225: form when transmitting it to another system. This gets converted
226: back to local text line terminators by the receiving KERMIT. This
227: makes it easy to share text files across different systems.
228:
229: But encrypted text cannot be automatically converted by a
230: communication protocol, because the plaintext is hidden by
231: encipherment. To remedy this inconvenience, PGP lets you specify
232: that the plaintext should be treated as ASCII text (not binary data)
233: and should be converted to canonical text form before it gets
234: encrypted. At the receiving end, the decrypted plaintext is
235: automatically converted back to whatever text form is appropriate for
236: the local environment.
237:
238: To make PGP assume the plaintext is text that should be converted to
239: canonical text before encryption, just add the "t" option when
240: encrypting or signing a message, like so:
241:
242: pgp -et message.txt her_userid
243:
244: This mode is automatically turned off if PGP detects that the
245: plaintext file contains what it thinks is non-text binary data.
246:
247: For PGP users that use non-English 8-bit character sets, when PGP
248: converts text to canonical form, it may convert data from the local
249: character set into the LATIN1 (ISO 8859-1 Latin Alphabet 1) character
250: set, depending on the setting of the CHARSET parameter in the PGP
251: configuration file. LATIN1 is a superset of ASCII, with extra
252: characters added for many European languages.
253:
254:
255:
256: Leaving No Traces of Plaintext on the Disk
257: ------------------------------------------
258:
259: After PGP makes a ciphertext file for you, you can have PGP
260: automatically overwrite the plaintext file and delete it, leaving no
261: trace of plaintext on the disk so that no one can recover it later
262: using a disk block scanning utility. This is useful if the plaintext
263: file contains sensitive information that you don't want to keep
264: around.
265:
266: To wipe out the plaintext file after producing the ciphertext file,
267: just add the "w" (wipe) option when encrypting or signing a message,
268: like so:
269:
270: pgp -esw message.txt her_userid
271:
272: This example creates the ciphertext file "message.pgp", and the
273: plaintext file "message.txt" is destroyed beyond recovery.
274:
275: Obviously, you should be careful with this option. Also note that
276: this will not wipe out any fragments of plaintext that your word
277: processor might have created on the disk while you were editing the
278: message before running PGP. Most word processors create backup
279: files, scratch files, or both. Also, it overwrites the file only
280: once, which is enough to thwart conventional disk recovery efforts,
281: but not enough to withstand a determined and sophisticated effort to
282: recover the faint magnetic traces of the data using special disk
283: recovery hardware.
284:
285:
286:
287: Displaying Decrypted Plaintext on Your Screen
288: ---------------------------------------------
289:
290: To view the decrypted plaintext output on your screen (like the
291: Unix-style "more" command), without writing it to a file, use the -m
292: (more) option while decrypting:
293:
294: pgp -m ciphertextfile
295:
296: This displays the decrypted plaintext display on your screen one
297: screenful at a time.
298:
299:
300:
301: Making a Message For Her Eyes Only
302: ----------------------------------
303:
304: To specify that the recipient's decrypted plaintext will be shown
305: ONLY on her screen and cannot be saved to disk, add the -m option:
306:
307: pgp -sem message.txt her_userid
308:
309: Later, when the recipient decrypts the ciphertext with her secret key
310: and pass phrase, the plaintext will be displayed on her screen but
311: will not be saved to disk. The text will be displayed as it would if
312: she used the Unix "more" command, one screenful at a time. If she
313: wants to read the message again, she will have to decrypt the
314: ciphertext again.
315:
316: This feature is the safest way for you to prevent your sensitive
317: message from being inadvertently left on the recipient's disk. This
318: feature was added at the request of a user who wanted to send
319: intimate messages to his lover, but was afraid she might accidentally
320: leave the decrypted messages on her husband's computer.
321:
322:
323:
324: Preserving the Original Plaintext Filename
325: ------------------------------------------
326:
327: Normally, PGP names the decrypted plaintext output file with a name
328: similar to the input ciphertext filename, but dropping the
329: extension. Or, you can override that convention by specifying an
330: output plaintext filename on the command line with the -o option.
331: For most E-mail, this is a reasonable way to name the plaintext file,
332: because you get to decide its name when you decipher it, and your
333: typical E-mail messages often come from useless original plaintext
334: filenames like "to_phil.txt".
335:
336: But when PGP encrypts a plaintext file, it always saves the original
337: filename and attaches it to the plaintext before it compresses and
338: encrypts the plaintext. Normally, this hidden original filename is
339: discarded by PGP when it decrypts, but you can tell PGP you want to
340: preserve the original plaintext filename and use it as the name of
341: the decrypted plaintext output file. This is useful if PGP is used
342: to on files whose names are important to preserve.
343:
344: To recover the original plaintext filename while decrypting, add
345: the -p option, like so:
346:
347: pgp -p ciphertextfile
348:
349: I usually don't use this option, because if I did, about half of my
350: incoming E-mail would decrypt to the same plaintext filenames of
351: "to_phil.txt" or "prz.txt".
352:
353:
354:
355: Editing Your User ID or Pass Phrase
356: -----------------------------------
357:
358: Sometimes you may need to change your pass phrase, perhaps because
359: someone looked over your shoulder while you typed it in.
360:
361: Or you may need to change your user ID, because you got married and
362: changed your name, or maybe you changed your E-mail address. Or
363: maybe you want to add a second or third user ID to your key, because
364: you may be known by more than one name or E-mail address or job
365: title. PGP lets you attach more than one user ID to your key, any
366: one of which may be used to look up your key on the key ring.
367:
368: To edit your userid or pass phrase for your secret key:
369:
370: pgp -ke userid [keyring]
371:
372: PGP prompts you for a new user ID or a new pass phrase.
373:
374:
375:
376: Editing the Trust Parameters for a Public Key
377: ---------------------------------------------
378:
379: Sometimes you need to alter the trust parameters for a public key on
380: your public key ring. For a discussion on what these trust
381: parameters mean, see the section "How Does PGP Keep Track of Which
382: Keys are Valid?" in the Essential Topics volume of the PGP User's
383: Guide.
384:
385: To edit the trust parameters for a public key:
386:
387: pgp -ke userid [keyring]
388:
389:
390:
391: Checking If Everything is OK on Your Public Key Ring
392: ----------------------------------------------------
393:
394: Normally, PGP automatically checks any new keys or signatures on your
395: public key ring and updates all the trust parameters and validity
396: scores. In theory, it keeps all the key validity status information
397: up to date as material is added to or deleted from your public key
398: ring. But perhaps you may want to explicitly force PGP to perform a
399: comprehensive analysis of your public key ring, checking all the
400: certifying signatures, checking the trust parameters, updating all
401: the validity scores, and checking your own ultimately-trusted key
402: against a backup copy on a write-protected floppy disk. It may be a
403: good idea to do this hygienic maintenance periodically to make sure
404: nothing is wrong with your public key ring. To force PGP to perform
405: a full analysis of your public key ring, use the -kc (key ring check)
406: command:
407:
408: pgp -kc
409:
410: You can also make PGP check all the signatures for just a single
411: selected public key by:
412:
413: pgp -kc userid [keyring]
414:
415: For further information on how the backup copy of your own key is
416: checked, see the description of the BAKRING parameter in the
417: configuration file section of this manual.
418:
419:
420:
421: Using PGP as a Unix-style Filter
422: --------------------------------
423:
424: Unix fans are accustomed to using Unix "pipes" to make two
425: applications work together. The output of one application can be
426: directly fed through a pipe to be read as input to another
427: application. For this to work, the applications must be capable of
428: reading the raw material from "standard input" and writing the
429: finished output to "standard output". PGP can operate in this mode.
430: If you don't understand what this means, then you probably don't need
431: this feature.
432:
433: To use a Unix-style filter mode, reading from standard input and
434: writing to standard output, add the -f option, like so:
435:
436: pgp -feast her_userid <inputfile >outputfile
437:
438: This feature makes it easier to make PGP work with electronic mail
439: applications.
440:
441: When using PGP in filter mode to decrypt a ciphertext file, you may
442: find it useful to use the PGPPASS environmental variable to hold the
443: pass phrase, so that you won't be prompted for it. The PGPPASS
444: feature is explained below.
445:
446:
447:
448: PGP Returns Exit Status to the Shell
449: ------------------------------------
450:
451: To facilitate running PGP in "batch" mode, such as from an MSDOS
452: ".bat" file or from a Unix shell script, PGP returns an error exit
453: status to the shell. An exit status code of zero means normal exit,
454: while a nonzero exit status indicates some kind of error occurred.
455: Different error exit conditions return different exit status codes to
456: the shell.
457:
458:
459:
460: Environmental Variable for Pass Phrase
461: --------------------------------------
462:
463: Normally, PGP prompts the user to type a pass phrase whenever PGP
464: needs a pass phrase to unlock a secret key. But it is possible to
465: store the pass phrase in an environmental variable from your
466: operating system's command shell. The environmental variable PGPPASS
467: can be used to hold the pass phrase that PGP will attempt to use
468: first. If the pass phrase stored in PGPPASS is incorrect, PGP
469: recovers by prompting the user for the correct pass phrase.
470:
471: For example, on MSDOS, the shell command:
472:
473: SET PGPPASS=zaphod beeblebrox for president
474:
475: would eliminate the prompt for the pass phrase if the pass phrase
476: were indeed "zaphod beeblebrox for president".
477:
478: This dangerous feature makes your life more convenient if you have to
479: regularly deal with a large number of incoming messages addressed to
480: your secret key, by eliminating the need for you to repeatedly type
481: in your pass phrase every time you run PGP.
482:
483: I added this feature because of popular demand. However, this is a
484: somewhat dangerous feature, because it keeps your precious pass
485: phrase stored somewhere other than just in your brain. Even worse,
486: if you are particularly reckless, it may even be stored on a disk on
487: the same computer as your secret key. It would be particularly
488: dangerous and stupid if you were to install this command in a batch
489: or script file, such as the MSDOS AUTOEXEC.BAT file. Someone could
490: come along on your lunch hour and steal both your secret key ring and
491: the file containing your pass phrase.
492:
493: I can't emphasize the importance of this risk enough. If you are
494: contemplating using this feature, be sure to read the sections
495: "Exposure on Multi-user Systems" and "How to Protect Secret Keys from
496: Disclosure" in this volume and in the Essential Topics volume of the
497: PGP User's Guide.
498:
499: If you must use this feature, the safest way to do it would be to
500: just manually type in the shell command to set PGPPASS every time you
501: boot your machine to start using PGP, and then erase it or turn off
502: your machine when you are done. And you should definitely never do
503: it in an environment where someone else may have access to your
504: machine. Someone could come along and simply ask your computer to
505: display the contents of PGPPASS.
506:
507:
508:
509: Setting Configuration Parameters: CONFIG.TXT
510: ============================================
511:
512: PGP has a number of user-settable parameters that can be defined in a
513: special configuration text file called "config.txt", in the directory
514: pointed to by the shell environmental variable PGPPATH. Having a
515: configuration file enables the user to define various flags and
516: parameters for PGP without the burden of having to always define
517: these parameters in the PGP command line.
518:
519: Configuration parameters may be assigned integer values, character
520: string values, or on/off values, depending on what kind of
521: configuration parameter it is. A sample configuration file is
522: provided with PGP, so you can see some examples.
523:
524: In the configuration file, blank lines are ignored, as is anything
525: following the '#' comment character. Keywords are not
526: case-sensitive.
527:
528: Here is a short sample fragment of a typical configuration file:
529:
530: # TMP is the directory for PGP scratch files, such as a RAM disk.
531: TMP = "e:\" # Can be overridden by environment variable TMP.
532: Armor = on # Use -a flag for ASCII armor whenever applicable.
533: # CERT_DEPTH is how deeply introducers may introduce introducers.
534: cert_depth = 3
535:
536: If some configuration parameters are not defined in the configuration
537: file, or if there is no configuration file, or if PGP can't find the
538: configuration file, the values for the configuration parameters
539: default to some reasonable value.
540:
541: The following is a summary of the various parameters than may be
542: defined in the configuration file.
543:
544:
545: TMP - Directory Pathname for Temporary Files
546: --------------------------------------------
547:
548: Default setting: TMP = ""
549:
550: The configuration parameter TMP specifies what directory to use for
551: PGP's temporary scratch files. The best place to put them is on a
552: RAM disk, if you have one. That speeds things up quite a bit, and
553: increases security somewhat. If TMP is undefined, the temporary
554: files go in the current directory. If the shell environmental
555: variable TMP is defined, PGP instead uses that to specify where the
556: temporary files should go.
557:
558:
559: LANGUAGE - Foreign Language Selector
560: ------------------------------------
561:
562: Default setting: LANGUAGE = "en"
563:
564: PGP displays various prompts, warning messages, and advisories to the
565: user on the screen. For example, messages such as "File not found.",
566: or "Please enter your pass phrase:". These messages are normally in
567: English. But it is possible to get PGP to display its messages to
568: the user in other languages, without having to modify the PGP
569: executable program.
570:
571: A number of people in various countries have translated all of PGP's
572: display messages, warnings, and prompts into their native languages.
573: These hundreds of translated message strings have been placed in a
574: special text file called "language.txt", distributed with the PGP
575: release. The messages are stored in this file in English, Spanish,
576: Dutch, German, French, Italian, Russian, Latvian, and Lithuanian.
577: Other languages may be added later.
578:
579: The configuration parameter LANGUAGE specifies what language to
580: display these messages in. LANGUAGE may be set to "en" for English,
581: "es" for Spanish, "de" for German, "nl" for Dutch, "fr" for French,
582: "it" for Italian, "ru" for Russian, "lt3" for Lithuanian, "lv" for
583: Latvian, "esp" for Esperanto. For example, if this line appeared in
584: the configuration file:
585:
586: LANGUAGE = "fr"
587:
588: PGP would select French as the language for its display messages.
589: The default setting is English.
590:
591: When PGP needs to display a message to the user, it looks in the
592: "language.txt" file for the equivalent message string in the selected
593: foreign language and displays that translated message to the user.
594: If PGP can't find the language string file, or if the selected
595: language is not in the file, or if that one phrase is not translated
596: into the selected language in the file, or if that phrase is missing
597: entirely from the file, PGP displays the message in English.
598:
599:
600: MYNAME - Default User ID for Making Signatures
601: ----------------------------------------------
602:
603: Default setting: MYNAME = ""
604:
605: The configuration parameter MYNAME specifies the default user ID to
606: use to select the secret key for making signatures. If MYNAME is not
607: defined, the most recent secret key you installed on your secret key
608: ring will be used. The user may also override this setting by
609: specifying a user ID on the PGP command line with the -u option.
610:
611:
612: TEXTMODE - Assuming Plaintext is a Text File
613: --------------------------------------------
614:
615: Default setting: TEXTMODE = off
616:
617: The configuration parameter TEXTMODE is equivalent to the -t command
618: line option. If enabled, it causes PGP to assume the plaintext is a
619: text file, not a binary file, and converts it to "canonical text"
620: before encrypting it. Canonical text has a carriage return and a
621: linefeed at the end of each line of text.
622:
623: This mode will be automatically turned off if PGP detects that the
624: plaintext file contains what it thinks is non-text binary data.
625:
626: For further details, see the section "Sending ASCII Text Files Across
627: Different Machine Environments".
628:
629:
630: CHARSET - Specifies Local Character Set for Text Files
631: ------------------------------------------------------
632:
633: Default setting: CHARSET = NOCONV
634:
635: Because PGP must process messages in many non-English languages with
636: non-ASCII character sets, you may have a need to tell PGP what local
637: character set your machine uses. This determines what character
638: conversions are performed when converting plaintext files to and from
639: canonical text format. This is only a concern if you are in a
640: non-English non-ASCII environment.
641:
642: The configuration parameter CHARSET selects the local character set.
643: The choices are NOCONV (no conversion), LATIN1 (ISO 8859-1 Latin
644: Alphabet 1), KOI8 (used by most Russian Unix systems), ALT-CODES
645: (used by Russian MSDOS systems), ASCII, and CP850 (used by most
646: western European languages on standard MSDOS PCs).
647:
648: LATIN1 is the internal representation used by PGP for canonical text,
649: so if you select LATIN1, no conversion is done. Note also that PGP
650: treats KOI8 as LATIN1, even though it is a completely different
651: character set (Russian), because trying to convert KOI8 to either
652: LATIN1 or CP850 would be futile anyway. This means that setting
653: CHARSET to NOCONV, LATIN1, or KOI8 are all equivalent to PGP.
654:
655: If you use MSDOS and expect to send or receive traffic in western
656: European languages, set CHARSET = "CP850". This will make PGP
657: convert incoming canonical text messages from LATIN1 to CP850 after
658: decryption. If you use the -t (textmode) option to convert to
659: canonical text, PGP will convert your CP850 text to LATIN1 before
660: encrypting it.
661:
662: For further details, see the section "Sending ASCII Text Files Across
663: Different Machine Environments".
664:
665:
666: ARMOR - Enable ASCII Armor Output
667: ---------------------------------
668:
669: Default setting: ARMOR = off
670:
671: The configuration parameter ARMOR is equivalent to the -a command
672: line option. If enabled, it causes PGP to emit ciphertext or keys in
673: ASCII Radix-64 format suitable for transporting through E-mail
674: channels. Output files are named with the ".asc" extension.
675:
676: If you tend to use PGP mostly for E-mail, it may be a good idea to
677: enable this parameter.
678:
679: For further details, see the section "Sending Ciphertext Through
680: E-mail Channels: Radix-64 Format" in the Essential Topics volume.
681:
682:
683: ARMORLINES - Size of ASCII Armor Multipart Files
684: ------------------------------------------------
685:
686: Default setting: ARMORLINES = 720
687:
688: When PGP creates a very large ".asc" radix-64 file for sending
689: ciphertext or keys through the E-mail, it breaks the file up into
690: separate chunks small enough to send through Internet mail
691: utilities. Normally, Internet mailers prohibit files larger than
692: about 50000 bytes, which means that if we restrict the number of
693: lines to about 720, we'll be well within the limit. The file chunks
694: are named with suffixes ".as1", ".as2", ".as3", ...
695:
696: The configuration parameter ARMORLINES specifies the maximum number
697: of lines to make each chunk in a multipart ".asc" file sequence. If
698: you set it to zero, PGP will not break up the file into chunks.
699:
700: For further details, see the section "Sending Ciphertext Through
701: E-mail Channels: Radix-64 Format" in the Essential Topics volume.
702:
703:
704: KEEPBINARY - Keep Binary Ciphertext Files After Decrypting
705: ----------------------------------------------------------
706:
707: Default setting: KEEPBINARY = on
708:
709: When PGP reads a ".asc" file, it recognizes that the file is in
710: radix-64 format and will convert it back to binary before processing
711: as it normally does, producing as a by-product a ".pgp" ciphertext
712: file in binary form. After further processing to decrypt the ".pgp"
713: file, the final output file will be in normal plaintext form.
714:
715: You may want to delete the binary ".pgp" intermediate file, or you
716: may want PGP to delete it for you automatically. You can still rerun
717: PGP on the original ".asc" file.
718:
719: The configuration parameter KEEPBINARY enables or disables keeping
720: the intermediate ".pgp" file during decryption.
721:
722: For further details, see the section "Sending Ciphertext Through
723: E-mail Channels: Radix-64 Format" in the Essential Topics volume.
724:
725:
726: VERBOSE - Enable Verbose Mode
727: -----------------------------
728:
729: Default setting: VERBOSE = off
730:
731: The configuration parameter VERBOSE enables "verbose" diagnostic
732: messages during PGP's operation, which is mainly useful for debugging
733: PGP. Otherwise, there is not much use for it.
734:
735:
736: COMPRESS - Enable Compression
737: -----------------------------
738:
739: Default setting: COMPRESS = on
740:
741: The configuration parameter COMPRESS enables or disables data
742: compression before encryption. It is used mainly for debugging PGP.
743: Normally, PGP attempts to compress the plaintext before it encrypts
744: it. Generally, you should leave this alone and let PGP attempt to
745: compress the plaintext.
746:
747:
748: COMPLETES_NEEDED - Number of Completely Trusted Introducers Needed
749: ------------------------------------------------------------------
750:
751: Default setting: COMPLETES_NEEDED = 1
752:
753: The configuration parameter COMPLETES_NEEDED specifies the minimum
754: number of completely trusted introducers required to fully certify a
755: public key on your public key ring. This gives you a way of tuning
756: PGP's skepticism.
757:
758: For further details, see the section "How Does PGP Keep Track of
759: Which Keys are Valid?" in the Essential Topics volume.
760:
761:
762: MARGINALS_NEEDED - Number of Marginally Trusted Introducers Needed
763: ------------------------------------------------------------------
764:
765: Default setting: MARGINALS_NEEDED = 2
766:
767: The configuration parameter MARGINALS_NEEDED specifies the minimum
768: number of marginally trusted introducers required to fully certify a
769: public key on your public key ring. This gives you a way of tuning
770: PGP's skepticism.
771:
772: For further details, see the section "How Does PGP Keep Track of
773: Which Keys are Valid?" in the Essential Topics volume.
774:
775:
776: CERT_DEPTH - How Deep May Introducers Be Nested
777: -----------------------------------------------
778:
779: Default setting: CERT_DEPTH = 4
780:
781: The configuration parameter CERT_DEPTH specifies how many levels deep
782: you may nest introducers to certify other introducers to certify
783: public keys on your public key ring. For example, If CERT_DEPTH is
784: set to 1, there may only be one layer of introducers below your own
785: ultimately-trusted key. If that were the case, you would be required
786: to directly certify the public keys of all trusted introducers on
787: your key ring. If you set CERT_DEPTH to 0, you could have no
788: introducers at all, and you would have to directly certify each and
789: every key on your public key ring in order to use it. The minimum
790: CERT_DEPTH is 0, the maximum is 8.
791:
792: For further details, see the section "How Does PGP Keep Track of
793: Which Keys are Valid?" in the Essential Topics volume.
794:
795:
796: BAKRING - Filename for Backup Secret Keyring
797: --------------------------------------------
798:
799: Default setting: BAKRING = ""
800:
801: All of the key certification that PGP does on your public key ring
802: ultimately depends on your own ultimately-trusted public key (or
803: keys). To detect any tampering of your public key ring, PGP must
804: check that your own key has not been tampered with. To do this, PGP
805: must compare your public key against a backup copy of your secret key
806: on some tamper-resistant media, such as a write-protected floppy
807: disk. A secret key contains all the information that your public key
808: has, plus some secret components. This means PGP can check your
809: public key against a backup copy of your secret key.
810:
811: The configuration parameter BAKRING specifies what pathname to use
812: for PGP's trusted backup copy of your secret key ring. On MSDOS, you
813: could set it to "a:\secring.pgp" to point it at a write-protected
814: backup copy of your secret key ring on your floppy drive. This check
815: is performed only when you execute the PGP -kc option to check your
816: whole public key ring.
817:
818: If BAKRING is not defined, PGP will not check your own key against
819: any backup copy.
820:
821: For further details, see the sections "How to Protect Public Keys
822: from Tampering" and "How Does PGP Keep Track of Which Keys are
823: Valid?" in the Essential Topics volume.
824:
825:
826: PAGER - Selects Shell Command to Display Plaintext Output
827: ---------------------------------------------------------
828:
829: Default setting: PAGER = ""
830:
831: PGP lets you view the decrypted plaintext output on your screen (like
832: the Unix-style "more" command), without writing it to a file, if you
833: use the -m (more) option while decrypting. This displays the
834: decrypted plaintext display on your screen one screenful at a time.
835:
836: If you prefer to use a fancier page display utility, rather than
837: PGP's built-in one, you can specify the name of a shell command that
838: PGP will invoke to display your plaintext output file. The
839: configuration parameter PAGER specifies the shell command to invoke
840: to display the file. For example:
841:
842: PAGER = "more"
843:
844: However, if the sender specified that this file is for your eyes
845: only, and may not be written to disk, PGP always uses its own
846: built-in display function.
847:
848: For further details, see the section "Displaying Decrypted Plaintext
849: on Your Screen".
850:
851:
852: SHOWPASS - Echo Pass Phrase to User
853: -----------------------------------
854:
855: Default setting: SHOWPASS = off
856:
857: Normally, PGP does not let you see your pass phrase as you type it
858: in. This makes it harder for someone to look over your shoulder
859: while you type and learn your pass phrase. But some typing-impaired
860: people have problems typing their pass phrase without seeing what
861: they are typing, and they may be typing in the privacy of their own
862: homes. So they asked if PGP can be configured to let them see what
863: they type when they type in their pass phrase.
864:
865: The configuration parameter SHOWPASS enables PGP to echo your typing
866: during pass phrase entry.
867:
868:
869: TZFIX - Timezone Adjustment
870: ---------------------------
871:
872: Default setting: TZFIX = 0
873:
874: PGP provides timestamps for keys and signature certificates in
875: Greenwich Mean Time (GMT), or Coordinated Universal Time (UTC), which
876: means the same thing for our purposes. When PGP asks the system for
877: the time of day, the system is supposed to provide it in GMT.
878:
879: But sometimes, because of improperly configured MSDOS systems, the
880: system time is returned in US Pacific Standard Time time plus 8
881: hours. Sounds weird, doesn't it? Perhaps because of some sort of US
882: west-coast jingoism, MSDOS presumes local time is US Pacific time,
883: and pre-corrects Pacific time to GMT. This adversely affects the
884: behavior of the internal MSDOS GMT time function that PGP calls.
885: However, if your MSDOS environmental variable TZ is already properly
886: defined for your timezone, this corrects the misconception MSDOS has
887: that the whole world lives on the US west coast.
888:
889: The configuration parameter TZFIX specifies the number of hours to
890: add to the system time function to get GMT, for GMT timestamps on
891: keys and signatures. If the MSDOS environmental variable TZ is
892: defined properly, you can leave TZFIX=0. Unix systems usually
893: shouldn't need to worry about setting TZFIX at all. But if you are
894: using some other obscure operating system that doesn't know about
895: GMT, you may have to use TZFIX to adjust the system time to GMT.
896:
897: On MSDOS systems that do not have TZ defined in the environment, you
898: should make TZFIX=0 for California, -1 for Colorado, -2 for Chicago,
899: -3 for New York, -8 for London, -9 for Amsterdam. In the summer,
900: TZFIX should be manually decremented from these values. What a mess.
901:
902: It would be much cleaner to set your MSDOS environmental variable TZ
903: in your AUTOEXEC.BAT file, and not use the TZFIX correction. Then
904: MSDOS gives you good GMT timestamps, and will handle daylight savings
905: time adjustments for you. Here are some sample lines to insert into
906: AUTOEXEC.BAT, depending on your time zone:
907:
908: For Colorado: SET TZ = MST7MDT
909: For Arizona: SET TZ = MST7
910: (Arizona never uses daylight savings time)
911: For Chicago: SET TZ = CST6CDT
912: For New York: SET TZ = EST5EDT
913: For London: SET TZ = GMT0BST
914: For Amsterdam: SET TZ = MET-1DST
915:
916:
917: Protecting Against Bogus Timestamps
918: ===================================
919:
920: A somewhat obscure vulnerability of PGP involves dishonest users
921: creating bogus timestamps on their own public key certificates and
922: signatures. You can skip over this section if you are a casual user
923: and aren't deeply into obscure public key protocols.
924:
925: There's nothing to stop a dishonest user from altering the date and
926: time setting of his own system's clock, and generating his own public
927: key certificates and signatures that appear to have been created at a
928: different time. He can make it appear that he signed something
929: earlier or later than he actually did, or that his public/secret key
930: pair was created earlier or later. This may have some legal or
931: financial benefit to him, for example by creating some kind of
932: loophole that might allow him to repudiate a signature.
933:
934: A remedy for this could involve some trustworthy Certifying Authority
935: or notary that would create notarized signatures with a trustworthy
936: timestamp. This might not necessarily require a centralized
937: authority. Perhaps any trusted introducer or disinterested party
938: could serve this function, the same way real notary publics do now.
939: A public key certificate could be signed by the notary, and the
940: trusted timestamp in the notary's signature would have some legal
941: significance. The notary could enter the signed certificate into a
942: special certificate log controlled by the notary. Anyone can read
943: this log.
944:
945: The notary could also sign other people's signatures, creating a
946: signature certificate of a signature certificate. This would serve
947: as a witness to the signature the same way real notaries do now with
948: paper. Again, the notary could enter the detached signature
949: certificate (without the actual whole document that was signed) into
950: a log controlled by the notary. The notary's signature would have a
951: trusted timestamp, which might have greater credibility than the
952: timestamp in the original signature. A signature becomes "legal" if
953: it is signed and logged by the notary.
954:
955: This problem of certifying signatures with notaries and trusted
956: timestamps warrants further discussion. This can of worms will not
957: be fully covered here now. There is a good treatment of this topic
958: in Denning's 1983 article in IEEE Computer (see references). There
959: is much more detail to be worked out in these various certifying
960: schemes. This will develop further as PGP usage increases and other
961: public key products develop their own certifying schemes.
962:
963:
964: A Peek Under the Hood
965: =====================
966:
967: Let's take a look at a few internal features of PGP.
968:
969:
970: Random Numbers
971: --------------
972:
973: PGP uses a cryptographically strong pseudorandom number generator for
974: creating temporary conventional session keys. The seed file for this
975: is called "randseed.bin". It too can be kept in whatever directory
976: is indicated by the PGPPATH environmental variable. If this random
977: seed file does not exist, it is automatically created and seeded with
978: truly random numbers derived from timing your keystroke latencies.
979:
980: This generator reseeds the disk file each time it is used by mixing
981: in new key material partially derived with the time of day and other
982: truly random sources. It uses the conventional encryption algorithm
983: as an engine for the random number generator. The seed file contains
984: both random seed material and random key material to key the
985: conventional encryption engine for the random generator.
986:
987: If you feel uneasy about trusting any algorithmically derived random
988: number source however strong, keep in mind that you already trust the
989: strength of the same conventional cipher to protect your messages.
990: If it's strong enough for that, then it should be strong enough to
991: use as a source of random numbers for temporary session keys. Note
992: that PGP still uses truly random numbers from physical sources
993: (mainly keyboard timings) to generate long-term public/secret key
994: pairs.
995:
996:
997:
998: PGP's Conventional Encryption Algorithm
999: ---------------------------------------
1000:
1001: As described earlier, PGP "bootstraps" into a conventional single-key
1002: encryption algorithm by using a public key algorithm to encipher the
1003: conventional session key and then switching to fast conventional
1004: cryptography. So let's talk about this conventional encryption
1005: algorithm. It isn't the DES.
1006:
1007: The Federal Data Encryption Standard (DES) is a good algorithm for
1008: most commercial applications. However, the Government does not trust
1009: the DES to protect its own classified data. Perhaps this is because
1010: the DES key length is 56 bits, short enough for a brute force attack
1011: with a special purpose machine built from massive numbers of DES
1012: chips. Also, Biham and Shamir have had some success recently on
1013: attacking the full 16-round DES.
1014:
1015: PGP does not use the DES as its conventional single-key algorithm to
1016: encrypt messages. Instead, PGP uses a different conventional
1017: single-key block encryption algorithm, called IDEA(tm). A future
1018: version of PGP may support the DES as an option, if enough users
1019: ask for it. But I suspect IDEA is better than DES.
1020:
1021: For the cryptographically curious, the IDEA cipher has a 64-bit block
1022: size for the plaintext and the ciphertext. It uses a key size of 128
1023: bits. It is based on the design concept of "mixing operations from
1024: different algebraic groups". It runs much faster in software than
1025: the DES. Like the DES, it can be used in cipher feedback (CFB) and
1026: cipher block chaining (CBC) modes. PGP uses it in 64-bit CFB mode.
1027:
1028: The IPES/IDEA block cipher was developed at ETH in Zurich by James L.
1029: Massey and Xuejia Lai, and published in 1990. This is not a
1030: "home-grown" algorithm. Its designers have a distinguished
1031: reputation in the cryptologic community. Early published papers on
1032: the algorithm called it IPES (Improved Proposed Encryption Standard),
1033: but they later changed the name to IDEA (International Data
1034: Encryption Algorithm). So far, IDEA has resisted attack much better
1035: than other ciphers such as FEAL, REDOC-II, LOKI, Snefru and Khafre.
1036: And preliminary evidence suggests that IDEA may be more resistant
1037: than the DES to Biham & Shamir's highly successful differential
1038: cryptanalysis attack. Biham and Shamir have been examining the IDEA
1039: cipher for weaknesses. Academic cryptanalyst groups in Belgium,
1040: England, and Germany are also attempting to attack it, as well as the
1041: military services from several European countries. As this new
1042: cipher continues to attract attack efforts from the most formidable
1043: quarters of the cryptanalytic world, confidence in IDEA is growing
1044: with the passage of time.
1045:
1046: A famous hockey player once said, "I try to skate to where I think
1047: the puck will be." A lot of people are starting to feel that the
1048: days are numbered for the DES. I'm skating toward IDEA.
1049:
1050: It is not ergonomically practical to use pure RSA with large keys to
1051: encrypt and decrypt long messages. Absolutely no one does it that way
1052: in the real world. But perhaps you are concerned that the whole
1053: package is weakened if we use a hybrid public-key and conventional
1054: scheme just to speed things up. After all, a chain is only as strong
1055: as its weakest link. Many people less experienced in cryptography
1056: mistakenly believe that RSA is intrinsically stronger than any
1057: conventional cipher. It's not. RSA can be made weak by using weak
1058: keys, and conventional ciphers can be made strong by choosing good
1059: algorithms. It's usually difficult to tell exactly how strong a good
1060: conventional cipher is, without actually cracking it. A really good
1061: conventional cipher might possibly be harder to crack than even a
1062: "military grade" RSA key. The attraction of public key cryptography
1063: is not because it is intrinsically stronger than a conventional
1064: cipher-- its appeal is because it helps you manage keys more
1065: conveniently.
1066:
1067:
1068:
1069: Data Compression
1070: ----------------
1071:
1072: PGP normally compresses the plaintext before encrypting it. It's too
1073: late to compress it after it has been encrypted; encrypted data is
1074: incompressible. Data compression saves modem transmission time and
1075: disk space and more importantly strengthens cryptographic security.
1076: Most cryptanalysis techniques exploit redundancies found in the
1077: plaintext to crack the cipher. Data compression reduces this
1078: redundancy in the plaintext, thereby greatly enhancing resistance to
1079: cryptanalysis. It takes extra time to compress the plaintext, but
1080: from a security point of view it seems worth it, at least in my
1081: cautious opinion.
1082:
1083: Files that are too short to compress or just don't compress well are
1084: not compressed by PGP.
1085:
1086: If you prefer, you can use PKZIP to compress the plaintext before
1087: encrypting it. PKZIP is a widely-available and effective MSDOS
1088: shareware compression utility from PKWare, Inc. Or you can use ZIP,
1089: a PKZIP-compatible freeware compression utility on Unix and other
1090: systems, available from Jean-Loup Gailly. There is some advantage in
1091: using PKZIP or ZIP in certain cases, because unlike PGP's built-in
1092: compression algorithm, PKZIP and ZIP have the nice feature of
1093: compressing multiple files into a single compressed file, which is
1094: reconstituted again into separate files when decompressed. PGP will
1095: not try to compress a plaintext file that has already been
1096: compressed. After decrypting, the recipient can decompress the
1097: plaintext with PKUNZIP. If the decrypted plaintext is a PKZIP
1098: compressed file, PGP automatically recognizes this and advises the
1099: recipient that the decrypted plaintext appears to be a PKZIP file.
1100:
1101: For the technically curious readers, the current version of PGP uses
1102: the freeware ZIP compression routines written by Jean-loup Gailly,
1103: Mark Adler, and Richard B. Wales. This ZIP software uses
1104: functionally-equivalent compression algorithms as those used by
1105: PKWare's new PKZIP 2.0. This ZIP compression software was selected
1106: for PGP mainly because of its free portable C source code
1107: availability, and because it has a really good compression ratio, and
1108: because it's fast.
1109:
1110:
1111:
1112: Message Digests and Digital Signatures
1113: --------------------------------------
1114:
1115: To create a digital signature, PGP encrypts with your secret key.
1116: But PGP doesn't actually encrypt your entire message with your secret
1117: key-- that would take too long. Instead, PGP encrypts a "message
1118: digest".
1119:
1120: The message digest is a compact (128 bit) "distillate" of your
1121: message, similar in concept to a checksum. You can also think of it
1122: as a "fingerprint" of the message. The message digest "represents"
1123: your message, such that if the message were altered in any way, a
1124: different message digest would be computed from it. This makes it
1125: possible to detect any changes made to the message by a forger. A
1126: message digest is computed using a cryptographically strong one-way
1127: hash function of the message. It would be computationally infeasible
1128: for an attacker to devise a substitute message that would produce an
1129: identical message digest. In that respect, a message digest is much
1130: better than a checksum, because it is easy to devise a different
1131: message that would produce the same checksum. But like a checksum,
1132: you can't derive the original message from its message digest.
1133:
1134: A message digest alone is not enough to authenticate a message. The
1135: message digest algorithm is publicly known, and does not require
1136: knowledge of any secret keys to calculate. If all we did was attach
1137: a message digest to a message, then a forger could alter a message
1138: and simply attach a new message digest calculated from the new
1139: altered message. To provide real authentication, the sender has to
1140: encrypt (sign) the message digest with his secret key.
1141:
1142: A message digest is calculated from the message by the sender. The
1143: sender's secret key is used to encrypt the message digest and an
1144: electronic timestamp, forming a digital signature, or signature
1145: certificate. The sender sends the digital signature along with the
1146: message. The receiver receives the message and the digital
1147: signature, and recovers the original message digest from the digital
1148: signature by decrypting it with the sender's public key. The
1149: receiver computes a new message digest from the message, and checks
1150: to see if it matches the one recovered from the digital signature. If
1151: it matches, then that proves the message was not altered, and it came
1152: from the sender who owns the public key used to check the signature.
1153:
1154: A potential forger would have to either produce an altered message
1155: that produces an identical message digest (which is infeasible), or
1156: he would have to create a new digital signature from a different
1157: message digest (also infeasible, without knowing the true sender's
1158: secret key).
1159:
1160: Digital signatures prove who sent the message, and that the message
1161: was not altered either by error or design. It also provides
1162: non-repudiation, which means the sender cannot easily disavow his
1163: signature on the message.
1164:
1165: Using message digests to form digital signatures has other advantages
1166: besides being faster than directly signing the entire actual message
1167: with the secret key. Using message digests allows signatures to be
1168: of a standard small fixed size, regardless of the size of the actual
1169: message. It also allows the software to check the message integrity
1170: automatically, in a manner similar to using checksums. And it allows
1171: signatures to be stored separately from messages, perhaps even in a
1172: public archive, without revealing sensitive information about the
1173: actual messages, because no one can derive any message content from a
1174: message digest.
1175:
1176: The message digest algorithm used here is the MD5 Message Digest
1177: Algorithm, placed in the public domain by RSA Data Security, Inc.
1178: MD5's designer, Ronald Rivest, writes this about MD5:
1179:
1180: "It is conjectured that the difficulty of coming up with two messages
1181: having the same message digest is on the order of 2^64 operations,
1182: and that the difficulty of coming up with any message having a given
1183: message digest is on the order of 2^128 operations. The MD5
1184: algorithm has been carefully scrutinized for weaknesses. It is,
1185: however, a relatively new algorithm and further security analysis is
1186: of course justified, as is the case with any new proposal of this
1187: sort. The level of security provided by MD5 should be sufficient for
1188: implementing very high security hybrid digital signature schemes
1189: based on MD5 and the RSA public-key cryptosystem."
1190:
1191:
1192:
1193: Compatibility with Previous Versions of PGP
1194: ===========================================
1195:
1196: I'm sorry, this version of PGP is not compatible with PGP version
1197: 1.0. If you have keys generated with version 1.0, you will have to
1198: generate new keys to use with this version. This version of PGP uses
1199: all new algorithms for conventional cryptography, compression, and
1200: message digests, as well as using a much better approach to key
1201: management. There were just too many changes to make it compatible
1202: with the old format messages, signatures, and keys. Perhaps we could
1203: have provided a special conversion utility to convert old keys into
1204: new keys, but we were all tired and wanted to get the new release out
1205: the door. Besides, converting the old keys into new keys would
1206: probably create more problems than it would solve, because we have
1207: changed to a new recommended uniform style for the user ID that
1208: includes the full name and E-mail address in a particular syntax.
1209:
1210: We made some effort to design the internal data structures of this
1211: version of PGP to be adaptable to future changes, so that hopefully
1212: you will not be required to discard and regenerate your keys in future
1213: versions.
1214:
1215:
1216: Vulnerabilities
1217: ===============
1218:
1219: No data security system is impenetrable. PGP can be circumvented in
1220: a variety of ways. In any data security system, you have to ask
1221: yourself if the information you are trying to protect is more
1222: valuable to your attacker than the cost of the attack. This should
1223: lead you to protecting yourself from the cheapest attacks, while not
1224: worrying about the more expensive attacks.
1225:
1226: Some of the discussion that follows may seem unduly paranoid, but
1227: such an attitude is appropriate for a reasonable discussion of
1228: vulnerability issues.
1229:
1230:
1231: Compromised Pass Phrase and Secret Key
1232: --------------------------------------
1233:
1234: Probably the simplest attack is if you leave your pass phrase for
1235: your secret key written down somewhere. If someone gets it and also
1236: gets your secret key file, they can read your messages and make
1237: signatures in your name.
1238:
1239: Don't use obvious passwords that can be easily guessed, such as the
1240: names of your kids or spouse. If you make your pass phrase a single
1241: word, it can be easily guessed by having a computer try all the words
1242: in the dictionary until it finds your password. That's why a pass
1243: phrase is so much better than a password. A more sophisticated
1244: attacker may have his computer scan a book of famous quotations to
1245: find your pass phrase. An easy to remember but hard to guess pass
1246: phrase can be easily constructed by some creatively nonsensical
1247: sayings or very obscure literary quotes.
1248:
1249: For further details, see the section "How to Protect Secret Keys from
1250: Disclosure" in the Essential Topics volume of the PGP User's Guide.
1251:
1252:
1253: Public Key Tampering
1254: --------------------
1255:
1256: A major vulnerability exists if public keys are tampered with. This
1257: may be the most crucially important vulnerability of a public key
1258: cryptosystem, in part because most novices don't immediately
1259: recognize it. The importance of this vulnerability, and appropriate
1260: hygienic countermeasures, are detailed in the section "How to Protect
1261: Public Keys from Tampering" in the Essential Topics volume.
1262:
1263: To summarize: When you use someone's public key, make certain it has
1264: not been tampered with. A new public key from someone else should be
1265: trusted only if you got it directly from its owner, or if it has been
1266: signed by someone you trust. Make sure no one else can tamper with
1267: your own public key ring. Maintain physical control of both your
1268: public key ring and your secret key ring, preferably on your own
1269: personal computer rather than on a remote timesharing system. Keep a
1270: backup copy of both key rings.
1271:
1272:
1273: "Not Quite Deleted" Files
1274: -------------------------
1275:
1276: Another potential security problem is caused by how most operating
1277: systems delete files. When you encrypt a file and then delete the
1278: original plaintext file, the operating system doesn't actually
1279: physically erase the data. It merely marks those disk blocks as
1280: deleted, allowing the space to be reused later. It's sort of like
1281: discarding sensitive paper documents in the paper recycling bin
1282: instead of the paper shredder. The disk blocks still contain the
1283: original sensitive data you wanted to erase, and will probably
1284: eventually be overwritten by new data at some point in the future.
1285: If an attacker reads these deleted disk blocks soon after they have
1286: been deallocated, he could recover your plaintext.
1287:
1288: In fact this could even happen accidentally, if for some reason
1289: something went wrong with the disk and some files were accidentally
1290: deleted or corrupted. A disk recovery program may be run to recover
1291: the damaged files, but this often means some previously deleted files
1292: are resurrected along with everything else. Your confidential files
1293: that you thought were gone forever could then reappear and be
1294: inspected by whomever is attempting to recover your damaged disk.
1295: Even while you are creating the original message with a word
1296: processor or text editor, the editor may be creating multiple
1297: temporary copies of your text on the disk, just because of its
1298: internal workings. These temporary copies of your text are deleted
1299: by the word processor when it's done, but these sensitive fragments
1300: are still on your disk somewhere.
1301:
1302: Let me tell you a true horror story. I had a friend, married with
1303: young children, who once had a brief and not very serious affair.
1304: She wrote a letter to her lover on her word processor, and deleted
1305: the letter after she sent it. Later, after the affair was over, the
1306: floppy disk got damaged somehow and she had to recover it because it
1307: contained other important documents. She asked her husband to
1308: salvage the disk, which seemed perfectly safe because she knew she
1309: had deleted the incriminating letter. Her husband ran a commercial
1310: disk recovery software package to salvage the files. It recovered
1311: the files alright, including the deleted letter. He read it, which
1312: set off a tragic chain of events.
1313:
1314: The only way to prevent the plaintext from reappearing is to somehow
1315: cause the deleted plaintext files to be overwritten. Unless you know
1316: for sure that all the deleted disk blocks will soon be reused, you
1317: must take positive steps to overwrite the plaintext file, and also
1318: any fragments of it on the disk left by your word processor. You can
1319: overwrite the original plaintext file after encryption by using the
1320: PGP -w (wipe) option. You can take care of any fragments of the
1321: plaintext left on the disk by using any of the disk utilities
1322: available that can overwrite all of the unused blocks on a disk. For
1323: example, the Norton Utilities for MSDOS can do this.
1324:
1325:
1326: Viruses and Trojan Horses
1327: -------------------------
1328:
1329: Another attack could involve a specially-tailored hostile computer
1330: virus or worm that might infect PGP or your operating system. This
1331: hypothetical virus could be designed to capture your pass phrase or
1332: secret key or deciphered messages, and covertly write the captured
1333: information to a file or send it through a network to the virus's
1334: owner. Or it might alter PGP's behavior so that signatures are not
1335: properly checked. This attack is cheaper than cryptanalytic attacks.
1336:
1337: Defending against this falls under the category of defending against
1338: viral infection generally. There are some moderately capable
1339: anti-viral products commercially available, and there are hygienic
1340: procedures to follow that can greatly reduce the chances of viral
1341: infection. A complete treatment of anti-viral and anti-worm
1342: countermeasures is beyond the scope of this document. PGP has no
1343: defenses against viruses, and assumes your own personal computer is a
1344: trustworthy execution environment. If such a virus or worm actually
1345: appeared, hopefully word would soon get around warning everyone.
1346:
1347: Another similar attack involves someone creating a clever imitation
1348: of PGP that behaves like PGP in most respects, but doesn't work the
1349: way it's supposed to. For example, it might be deliberately crippled
1350: to not check signatures properly, allowing bogus key certificates to
1351: be accepted. This "Trojan horse" version of PGP is not hard for an
1352: attacker to create, because PGP source code is widely available, so
1353: anyone could modify the source code and produce a lobotomized zombie
1354: imitation PGP that looks real but does the bidding of its diabolical
1355: master. This Trojan horse version of PGP could then be widely
1356: circulated, claiming to be from me. How insidious.
1357:
1358: You should make an effort to get your copy of PGP from a reliable
1359: source, whatever that means. Or perhaps from more than one
1360: independent source, and compare them with a file comparison utility.
1361:
1362: There are other ways to check PGP for tampering, using digital
1363: signatures. If someone you trust signs the executable version of
1364: PGP, vouching for the fact that it has not been infected or tampered
1365: with, you can be reasonably sure that you have a good copy. You
1366: could use an earlier trusted version of PGP to check the signature on
1367: a later suspect version of PGP. But this will not help at all if
1368: your operating system is infected, nor will it detect if your
1369: original copy of PGP.EXE has been maliciously altered in such a way
1370: as to compromise its own ability to check signatures. This test also
1371: assumes that you have a good trusted copy of the public key that you
1372: use to check the signature on the PGP executable.
1373:
1374:
1375: Physical Security Breach
1376: ------------------------
1377:
1378: A physical security breach may allow someone to physically acquire
1379: your plaintext files or printed messages. A determined opponent
1380: might accomplish this through burglary, trash-picking, unreasonable
1381: search and seizure, or bribery, blackmail or infiltration of your
1382: staff. Some of these attacks may be especially feasible against
1383: grassroots political organizations that depend on a largely volunteer
1384: staff. It has been widely reported in the press that the FBI's
1385: COINTELPRO program used burglary, infiltration, and illegal bugging
1386: against antiwar and civil rights groups. And look what happened at
1387: the Watergate Hotel.
1388:
1389: Don't be lulled into a false sense of security just because you have
1390: a cryptographic tool. Cryptographic techniques protect data only
1391: while it's encrypted-- direct physical security violations can still
1392: compromise plaintext data or written or spoken information.
1393:
1394: This kind of attack is cheaper than cryptanalytic attacks on PGP.
1395:
1396:
1397: Tempest Attacks
1398: ---------------
1399:
1400: Another kind of attack that has been used by well-equipped opponents
1401: involves the remote detection of the electromagnetic signals from
1402: your computer. This expensive and somewhat labor-intensive attack is
1403: probably still cheaper than direct cryptanalytic attacks. An
1404: appropriately instrumented van can park near your office and remotely
1405: pick up all of your keystrokes and messages displayed on your
1406: computer video screen. This would compromise all of your passwords,
1407: messages, etc. This attack can be thwarted by properly shielding all
1408: of your computer equipment and network cabling so that it does not
1409: emit these signals. This shielding technology is known as "Tempest",
1410: and is used by some Government agencies and defense contractors.
1411: There are hardware vendors who supply Tempest shielding commercially,
1412: although it may be subject to some kind of Government licensing. Now
1413: why do you suppose the Government would restrict access to Tempest
1414: shielding?
1415:
1416:
1417: Exposure on Multi-user Systems
1418: ------------------------------
1419:
1420: PGP was originally designed for a single-user MSDOS machine under
1421: your direct physical control. I run PGP at home on my own PC, and
1422: unless someone breaks into my house or monitors my electromagnetic
1423: emissions, they probably can't see my plaintext files or secret keys.
1424:
1425: But now PGP also runs on multi-user systems such as Unix and VAX/VMS.
1426: On multi-user systems, there are much greater risks of your plaintext
1427: or keys or passwords being exposed. The Unix system administrator or
1428: a clever intruder can read your plaintext files, or perhaps even use
1429: special software to covertly monitor your keystrokes or read what's
1430: on your screen. On a Unix system, any other user can read your
1431: environment information remotely by simply using the Unix "ps"
1432: command. Similar problems exist for MSDOS machines connected on a
1433: local area network. The actual security risk is dependent on your
1434: particular situation. Some multi-user systems may be safe because
1435: all the users are trusted, or because they have system security
1436: measures that are safe enough to withstand the attacks available to
1437: the intruders, or because there just aren't any sufficiently
1438: interested intruders. Some Unix systems are safe because they are
1439: only used by one user-- there are even some notebook computers
1440: running Unix. It would be unreasonable to simply exclude PGP from
1441: running on all Unix systems.
1442:
1443: PGP is not designed to protect your data while it is in plaintext
1444: form on a compromised system. Nor can it prevent an intruder from
1445: using sophisticated measures to read your secret key while it is
1446: being used. You will just have to recognize these risks on
1447: multi-user systems, and adjust your expectations and behavior
1448: accordingly. Perhaps your situation is such that you should consider
1449: only running PGP on an isolated single-user system under your direct
1450: physical control. That's what I do, and that's what I recommend.
1451:
1452:
1453: Traffic Analysis
1454: ----------------
1455:
1456: Even if the attacker cannot read the contents of your encrypted
1457: messages, he may be able to infer at least some useful information by
1458: observing where the messages come from and where they are going, the
1459: size of the messages, and the time of day the messages are sent.
1460: This is analogous to the attacker looking at your long distance phone
1461: bill to see who you called and when and for how long, even though the
1462: actual content of your calls is unknown to the attacker. This is
1463: called traffic analysis. PGP alone does not protect against traffic
1464: analysis. Solving this problem would require specialized
1465: communication protocols designed to reduce exposure to traffic
1466: analysis in your communication environment, possibly with some
1467: cryptographic assistance.
1468:
1469:
1470: Cryptanalysis
1471: -------------
1472:
1473: An expensive and formidable cryptanalytic attack could possibly be
1474: mounted by someone with vast supercomputer resources, such as a
1475: Government intelligence agency. They might crack your RSA key by
1476: using some new secret factoring breakthrough. Perhaps so, but it is
1477: noteworthy that the US Government trusts the RSA algorithm enough in
1478: some cases to use it to protect its own nuclear weapons, according to
1479: Ron Rivest. And civilian academia has been intensively attacking it
1480: without success since 1978.
1481:
1482: Perhaps the Government has some classified methods of cracking the
1483: IDEA(tm) conventional encryption algorithm used in PGP. This is
1484: every cryptographer's worst nightmare. There can be no absolute
1485: security guarantees in practical cryptographic implementations.
1486:
1487: Still, some optimism seems justified. The IDEA algorithm's designers
1488: are among the best cryptographers in Europe. It has had extensive
1489: security analysis and peer review from some of the best cryptanalysts
1490: in the unclassified world. It appears to have some design advantages
1491: over the DES in withstanding differential cryptanalysis, which has
1492: been used to crack the DES.
1493:
1494: Besides, even if this algorithm has some subtle unknown weaknesses,
1495: PGP compresses the plaintext before encryption, which should greatly
1496: reduce those weaknesses. The computational workload to crack it is
1497: likely to be much more expensive than the value of the message.
1498:
1499: If your situation justifies worrying about very formidable attacks of
1500: this caliber, then perhaps you should contact a data security
1501: consultant for some customized data security approaches tailored to
1502: your special needs. Boulder Software Engineering, whose address and
1503: phone are given at the end of this document, can provide such
1504: services.
1505:
1506:
1507: In summary, without good cryptographic protection of your data
1508: communications, it may have been practically effortless and perhaps
1509: even routine for an opponent to intercept your messages, especially
1510: those sent through a modem or E-mail system. If you use PGP and
1511: follow reasonable precautions, the attacker will have to expend far
1512: more effort and expense to violate your privacy.
1513:
1514: If you protect yourself against the simplest attacks, and you feel
1515: confident that your privacy is not going to be violated by a
1516: determined and highly resourceful attacker, then you'll probably be
1517: safe using PGP. PGP gives you Pretty Good Privacy.
1518:
1519:
1520: Legal Issues
1521: ============
1522:
1523:
1524: Trademarks, Copyrights, and Warranties
1525: --------------------------------------
1526:
1527: "Pretty Good Privacy", "Phil's Pretty Good Software", and the "Pretty
1528: Good" label for computer software and hardware products are all
1529: trademarks of Philip Zimmermann and Phil's Pretty Good Software. PGP
1530: is (c) Copyright Philip R. Zimmermann, 1990-1992. Philip Zimmermann
1531: also holds the copyright for the PGP User's Manual, as well as any
1532: foreign language translations of the manual or the software.
1533:
1534: The author assumes no liability for damages resulting from the use of
1535: this software, even if the damage results from defects in this
1536: software, and makes no representations concerning the merchantability
1537: of this software or its suitability for any specific purpose. It is
1538: provided "as is" without express or implied warranty of any kind.
1539:
1540:
1541: Patent Rights on the Algorithms
1542: -------------------------------
1543:
1544: When I first released PGP, I half-expected to encounter some form of
1545: legal harassment from the Government. Indeed, there has been legal
1546: harrassment, but it hasn't come from the Government-- it has come
1547: from a private corporation.
1548:
1549: The RSA public key cryptosystem was developed at MIT with Federal
1550: funding from grants from the National Science Foundation and the
1551: Navy. It is patented by MIT (U.S. patent #4,405,829, issued 20 Sep
1552: 1983). A company in California called Public Key Partners (PKP) holds
1553: the exclusive commercial license to sell and sub-license the RSA
1554: public key cryptosystem. The author of this software implementation
1555: of the RSA algorithm is providing this implementation for educational
1556: use only. Licensing this algorithm from PKP is the responsibility of
1557: you, the user, not Philip Zimmermann, the author of this software
1558: implementation. The author assumes no liability for any patent
1559: infringement that may result from the unlicensed use by the user of
1560: the underlying RSA algorithm used in this software. Foreign users
1561: should note that the RSA patent does not apply outside the US, and
1562: there is no RSA patent in any other country. Federal agencies may
1563: use it because the Government paid for the development of RSA.
1564:
1565: Unfortunately, PKP is not offering any licensing of their RSA patent
1566: to end users of PGP. This essentially makes PGP contraband in the
1567: USA. Jim Bidzos, president of PKP, threatened to take legal action
1568: against me unless I stop distributing PGP, until they can devise a
1569: licensing scheme for it. I agreed to this, since PGP is already in
1570: wide circulation and waiting a while for a licensing arrangement from
1571: PKP seemed reasonable. Mr. Bidzos assured me (he even used the word
1572: "promise") several times since the initial 5 June 91 release of PGP
1573: that they were working on a licensing scheme for PGP. Apparently, my
1574: release of PGP helped provide the impetus for them to offer some sort
1575: of a freeware-style license for noncommercial use of the RSA
1576: algorithm. However, in December 1991 Mr. Bidzos said he had no plans
1577: to ever license the RSA algorithm to PGP users, and denied ever
1578: implying that he would. Meanwhile, I have continued to refrain from
1579: distributing PGP, although I've recently updated the PGP User's
1580: Guide, and have provided a lot of design guidance for these new
1581: revisions of PGP.
1582:
1583: I wrote my PGP software from scratch, with my own implementation of
1584: the RSA algorithm. I didn't steal any software from PKP. Before
1585: publishing PGP, I got a formal written legal opinion from a patent
1586: attorney with extensive experience in software patents. I'm
1587: convinced that publishing PGP the way I did does not violate patent
1588: law. However, it is a well known axiom in the US legal system that
1589: regardless of the law, he with the most money and lawyers prevails,
1590: if not by actually winning then by crushing the little guy with legal
1591: expenses.
1592:
1593: Not only did PKP acquire the exclusive patent rights for the RSA
1594: cryptosystem, which was developed with your tax dollars, but they
1595: also somehow acquired the exclusive rights to three other patents
1596: covering rival public key schemes invented by others, also developed
1597: with your tax dollars. This essentially gives one company a legal
1598: lock in the USA on nearly all practical public key cryptosystems.
1599: They even appear to be claiming patent rights on the very concept of
1600: public key cryptography, regardless of what clever new original
1601: algorithms are independently invented by others. And you thought
1602: patent law was designed to encourage innovation! PKP does not
1603: actually develop any software-- they don't even have an engineering
1604: department-- they are essentially a litigation company.
1605:
1606: Public key cryptography is destined to become a crucial technology in
1607: the protection of our civil liberties and privacy in our increasingly
1608: connected society. Why should the Government try to limit access to
1609: this key technology, when a single monopoly can do it for them?
1610:
1611: It appears certain that there will be future releases of PGP,
1612: regardless of the outcome of licensing problems with Public Key
1613: Partners. If PKP does not license PGP, then future releases of PGP
1614: might not come from me. There are countless fans of PGP outside the
1615: US, and many of them are software engineers who want to improve PGP
1616: and promote it, regardless of what I do. The second release of PGP
1617: was a joint effort of an international team of software engineers,
1618: implementing enhancements to the original PGP with design guidance
1619: from me. It is being released by Peter Gutmann in New Zealand, out
1620: of reach of US patent law. It is being released only in Europe and
1621: New Zealand, but it may spontaneously spread to the USA without any
1622: help from me or the PGP development team.
1623:
1624: The IDEA(tm) conventional block cipher used by PGP is covered by a
1625: patent in Europe, held by ETH and a Swiss company called Ascom-Tech
1626: AG. The patent number is PCT/CH91/00117. International patents are
1627: pending. IDEA(tm) is a trademark of Ascom-Tech AG. There is no
1628: license fee required for noncommercial use. Commercial users may
1629: obtain licensing details from Dieter Profos, Ascom Tech AG, Solothurn
1630: Lab, Postfach 151, 4502 Solothurn, Switzerland, Tel +41 65 242885,
1631: Fax +41 65 235761.
1632:
1633: The ZIP compression routines in PGP come from freeware source code,
1634: with the author's permission. I'm not aware of any patents on the
1635: ZIP algorithm, but you're welcome to check into that question
1636: yourself. If there are any obscure patent claims that apply to ZIP,
1637: then sorry, you'll have to take care of the patent licensing, not me.
1638:
1639: All this patent stuff reminds me of a Peanuts cartoon I saw in the
1640: newspaper where Lucy showed Charlie Brown a fallen autumn leaf and
1641: said "This is the first leaf to fall this year." Charlie Brown said,
1642: "How do you know that? Leaves have been falling for weeks." Lucy
1643: replied, "I had this one notarized."
1644:
1645:
1646: Licensing and Distribution
1647: --------------------------
1648:
1649: In the USA PKP controls, through US patent law, the licensing of the
1650: RSA algorithm. But I have no objection to anyone freely using or
1651: distributing my PGP software, without payment of fees to me. You must
1652: keep the copyright notices on PGP and keep this documentation with
1653: it. However, if you live in the USA, this may not satisfy any legal
1654: obligations you may have to PKP for using the RSA algorithm as
1655: mentioned above.
1656:
1657: In fact, if you live in the USA, and you are not a Federal agency,
1658: you shouldn't actually run PGP on your computer, because Public Key
1659: Partners wants to forbid you from running my software. PGP is
1660: contraband.
1661:
1662: Of course, I can't give any assurances, but my guess is that it seems
1663: unlikely that PKP would waste their time pursuing PGP end users for
1664: patent infringement. There are just too many PGP users to go after.
1665: And why would they single you out? But I certainly wouldn't want to
1666: imply that you do anything improper-- if PKP were offering licenses,
1667: I would urge you to obtain one. But since they aren't, well, I guess
1668: you should just refrain from using PGP if you live in the USA.
1669:
1670: PGP is not shareware, it's freeware. Forbidden freeware. Published
1671: as a community service. If I sold PGP for money, then I would get
1672: sued by PKP for using their RSA algorithm. More importantly, giving
1673: PGP away for free will encourage far more people to use it, which
1674: hopefully will have a greater social impact. This could lead to
1675: widespread awareness and use of the RSA public key cryptosystem,
1676: which will probably make more money for PKP in the long run. If only
1677: they could see that.
1678:
1679: All the source code for PGP is available for free under the "Copyleft"
1680: General Public License from the Free Software Foundation (FSF). A
1681: copy of the FSF General Public License is included in the source
1682: release package of PGP.
1683:
1684: Regardless of and perhaps contrary to some provisions of the FSF
1685: General Public License, the following terms apply:
1686:
1687: 1) Written discussions of PGP in magazines or books may include
1688: fragments of PGP source code and documentation, without
1689: restrictions.
1690:
1691: 2) Although the FSF General Public License allows non-proprietary
1692: derivative products, it prohibits proprietary derivative products.
1693: Despite this, I may grant you a special license if you want to
1694: derive a proprietary commercial product from some of PGP's parts.
1695: There may or may not be a fee depending on what kind of a deal you
1696: plan to pursue with PKP. Retaining my copyright notice and
1697: attribution might suffice in some cases. Give me a call and we'll
1698: discuss it. I'm real easy to please.
1699:
1700: Feel free to disseminate the complete PGP release package as widely
1701: as possible. Give it to all your friends. If you have access to any
1702: electronic Bulletin Boards Systems, please upload the complete PGP
1703: executable object release package to as many BBS's as possible. You
1704: may disseminate the PGP source release package too, if you've got
1705: it. The PGP version 2.0 executable object release package for MSDOS
1706: contains the PGP executable software, documentation, sample key rings
1707: including my own public key, and signatures for the software and this
1708: manual, all in one PKZIP compressed file called PGP20.ZIP. The PGP
1709: source release package for MSDOS contains all the C source files in
1710: one PKZIP compressed file called PGP20SRC.ZIP.
1711:
1712: You may obtain free copies or updates to PGP from thousands of BBS's
1713: worldwide or from other public sources such as Internet FTP sites.
1714: Don't ask me for a copy directly from me, since I'd rather avoid
1715: further legal problems with PKP at this time. I might be able to
1716: tell you where you can get it, however.
1717:
1718: After all this work I have to admit I wouldn't mind getting some fan
1719: mail for PGP, to gauge its popularity. Let me know what you think
1720: about it and how many of your friends use it. Bug reports and
1721: suggestions for enhancing PGP are welcome, too. Perhaps a future PGP
1722: release will reflect your suggestions.
1723:
1724: This project has not been funded and the project has nearly eaten me
1725: alive. This means you can't count on a reply to your mail, unless
1726: you only need a short written reply and you include a stamped
1727: self-addressed envelope. But I do reply to E-mail. Please keep it in
1728: English, as my foreign language skills are weak. If you call and I'm
1729: not in, it's best to just try again later. I usually don't return
1730: long distance phone calls, unless you leave a message that I can call
1731: you collect. If you need any significant amount of my time, I am
1732: available on a paid consulting basis, and I do return those calls.
1733:
1734: The most inconvenient mail I get is for some well-intentioned person
1735: to send me a few dollars asking me for a copy of PGP. I can't send
1736: it to them because of the legal threats from PKP (or worse--
1737: sometimes these requests are from foreign countries, and I would be
1738: risking violating cryptographic export control laws). Even if there
1739: were no legal hassles involved in sending PGP to them, they usually
1740: don't send enough money to make it worth my time ($50 might be worth
1741: my time if I were actually selling this stuff). I'm just not set up
1742: as a low cost low volume mail order business. I can't just ignore
1743: the request and keep the money, because they probably regard the
1744: money as a fee for me to fulfill their request. If I return the
1745: money, I might have to get in my car and drive down to the post
1746: office and buy some postage stamps, because these requests rarely
1747: include a stamped self-addressed envelope. And I have to take the
1748: time to write a polite reply that I can't do it. If I postpone the
1749: reply and set the letter down on my desk, it might be buried within
1750: minutes and won't see the light of day again for months. Multiply
1751: these minor inconveniences by the number of requests I get, and you
1752: can see the problem. Isn't it enough that the software is free? It
1753: would be nicer if people could try to get PGP from any of the myriad
1754: other sources. If you don't have a modem, ask a friend to get it for
1755: you. If you can't find it yourself, I don't mind answering a quick
1756: phone call.
1757:
1758: If anyone wants to volunteer to improve PGP, please let me know. It
1759: could certainly use some more work. Some features were deferred to
1760: get it out the door. A number of PGP users have since donated their
1761: time to port PGP to Unix on Sun SPARCstations, to Ultrix, to VAX/VMS,
1762: to OS/2, to the Amiga, and to the Atari ST. Perhaps you can help
1763: port it to some new environments, such as the Apple Macintosh, MS
1764: Windows, X windows, or XVT. But please let me know if you plan to
1765: port PGP, to avoid duplication of effort, and to avoid starting with
1766: an obsolete version of the source code.
1767:
1768: Future versions of PGP may have to change the data formats for
1769: messages, signatures, keys and key rings, in order to provide
1770: important new features. This may cause backward compatibility
1771: problems with this version of PGP. Future releases may provide
1772: conversion utilities to convert old keys, but you may have to dispose
1773: of old messages created with the old PGP.
1774:
1775:
1776: Export Controls
1777: ---------------
1778:
1779: The Government has made it illegal in many cases to export good
1780: cryptographic technology, and that may include PGP. They regard this
1781: kind of software as munitions. This is determined by volatile State
1782: Department policies, not fixed laws. I will not export this software
1783: out of the US or Canada in cases when it is illegal to do so under US
1784: State Department policies, and I assume no responsibility for other
1785: people exporting it on their own.
1786:
1787: If you live outside the US or Canada, I advise you not to violate US
1788: State Department policies by getting PGP from a US source. Since
1789: thousands of domestic users got it after its initial publication, it
1790: somehow leaked out of the US and spread itself widely abroad, like
1791: dandelion seeds blowing in the wind. If PGP has already found its
1792: way into your country, then I don't think you're violating US export
1793: law if you pick it up from a source outside of the US. And there are
1794: no import restrictions on bringing cryptographic technology into the
1795: USA.
1796:
1797: Some foreign governments impose serious penalties on anyone inside
1798: their country using encrypted communications. In some countries they
1799: might even shoot you for that.
1800:
1801:
1802:
1803: Recommended Introductory Readings
1804: =================================
1805:
1806: 1) Dorothy Denning, "Cryptography and Data Security", Addison-Wesley,
1807: Reading, MA 1982
1808: 2) Dorothy Denning, "Protecting Public Keys and Signature Keys",
1809: IEEE Computer, Feb 1983
1810: 3) Martin E. Hellman, "The Mathematics of Public-Key Cryptography,"
1811: Scientific American, August 1979
1812: 4) Philip Zimmermann, "A Proposed Standard Format for RSA
1813: Cryptosystems", IEEE Computer, Sep 1986
1814:
1815: Other Readings
1816: ==============
1817:
1818: 5) Ronald Rivest, "The MD5 Message Digest Algorithm", MIT Laboratory
1819: for Computer Science, 1991
1820: 6) Xuejia Lai, "On the Design and Security of Block Ciphers",
1821: Institute for Signal and Information Processing, ETH-Zentrum,
1822: Zurich, Switzerland, 1992
1823: 7) Xuejia Lai, James L. Massey, Sean Murphy, "Markov Ciphers and
1824: Differential Cryptanalysis", Advances in Cryptology- EUROCRYPT'91
1825:
1826:
1827:
1828: To Contact the Author
1829: =====================
1830:
1831: Philip Zimmermann may be reached at:
1832:
1833: Boulder Software Engineering
1834: 3021 Eleventh Street
1835: Boulder, Colorado 80304 USA
1836: Phone 303-541-0140 (voice or FAX) (10:00am - 7:00pm Mountain Time)
1837: Internet: [email protected]
1838:
1839:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.