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