![[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.1.4 root 1:
1.1.1.5 root 2:
1.1.1.4 root 3: Phil's Pretty Good Software
4: Presents
5:
6: =======
7: PGP(tm)
8: =======
9:
10: Pretty Good(tm) Privacy
11: Public Key Encryption for the Masses
12:
13:
14: -------------------------
1.1.1.5 root 15: PGP(tm) User's Guide
16: Volume II: Special Topics
1.1.1.4 root 17: -------------------------
1.1.1.5 root 18: by Philip Zimmermann
1.1.1.6 ! root 19: Revised 11 October 94
1.1.1.4 root 20:
21:
1.1.1.6 ! root 22: PGP Version 2.6.2 - 11 Oct 94
1.1.1.5 root 23: Software by
24: Philip Zimmermann, and many others.
1.1.1.4 root 25:
26:
27:
28:
29: Synopsis: PGP(tm) uses public-key encryption to protect E-mail and
30: data files. Communicate securely with people you've never met, with
31: no secure channels needed for prior exchange of keys. PGP is well
32: featured and fast, with sophisticated key management, digital
33: signatures, data compression, and good ergonomic design.
34:
35:
36: Software and documentation (c) Copyright 1990-1994 Philip Zimmermann.
37: All rights reserved. For information on PGP licensing, distribution,
38: copyrights, patents, trademarks, liability limitations, and export
39: controls, see the "Legal Issues" section. Distributed by the
40: Massachusetts Institute of Technology.
41:
42:
43: Contents
44: ========
45:
46: Quick Overview
47: Special Topics
48: Selecting Keys via Key ID
49: Separating Signatures from Messages
50: Decrypting the Message and Leaving the Signature on it
51: Sending ASCII Text Files Across Different Machine Environments
1.1.1.6 ! root 52: Using PGP as a Better Uuencode
1.1.1.4 root 53: Leaving No Traces of Plaintext on the Disk
54: Displaying Decrypted Plaintext on Your Screen
55: Making a Message For Her Eyes Only
56: Preserving the Original Plaintext Filename
57: Editing Your User ID or Pass Phrase
58: Editing the Trust Parameters for a Public Key
59: Checking If Everything is OK on Your Public Key Ring
60: Verifying a Public Key Over the Phone
61: Handling Large Public Keyrings
62: Using PGP as a Unix-style Filter
63: Suppressing Unnecessary Questions: BATCHMODE
64: Force "Yes" Answer to Confirmation Questions: FORCE
65: PGP Returns Exit Status to the Shell
66: Environmental Variable for Pass Phrase
1.1.1.6 ! root 67: Setting Parameters in the PGP Configuration File
1.1.1.4 root 68: TMP - Directory Pathname for Temporary Files
69: LANGUAGE - Foreign Language Selector
70: MYNAME - Default User ID for Making Signatures
71: TEXTMODE - Assuming Plaintext is a Text File
72: CHARSET - Specifies Local Character Set for Text Files
73: ARMOR - Enable ASCII Armor Output
74: ARMORLINES - Size of ASCII Armor Multipart Files
75: KEEPBINARY - Keep Binary Ciphertext Files After Decrypting
76: COMPRESS - Enable Compression
77: COMPLETES_NEEDED - Number of Completely Trusted Introducers Needed
78: MARGINALS_NEEDED - Number of Marginally Trusted Introducers Needed
79: CERT_DEPTH - How Deep May Introducers Be Nested
80: BAKRING - Filename for Backup Secret Keyring
81: PUBRING - Filename for Your Public Keyring
82: SECRING - Filename for Your Secret Keyring
83: RANDSEED - Filename for Random Number Seed
84: PAGER - Selects Shell Command to Display Plaintext Output
85: SHOWPASS - Echo Pass Phrase to User
86: TZFIX - Timezone Adjustment
87: CLEARSIG - Enable Signed Messages to be Encapsulated as Clear Text
88: VERBOSE - Quiet, Normal, or Verbose Messages
89: INTERACTIVE - Ask for Confirmation for Key Adds
90: NOMANUAL - Let PGP Generate Keys Without the Manual
91: A Peek Under the Hood
92: Random Numbers
93: PGP's Conventional Encryption Algorithm
94: Data Compression
95: Message Digests and Digital Signatures
1.1.1.5 root 96: Compatibility with Previous and Future Versions of PGP
1.1.1.4 root 97: Vulnerabilities
98: Compromised Pass Phrase and Secret Key
99: Public Key Tampering
100: "Not Quite Deleted" Files
101: Viruses and Trojan Horses
102: Physical Security Breach
103: Tempest Attacks
104: Exposure on Multi-user Systems
105: Traffic Analysis
1.1.1.5 root 106: Protecting Against Bogus Timestamps
1.1.1.4 root 107: Cryptanalysis
108: Legal Issues
109: Trademarks, Copyrights, and Warranties
110: Patent Rights on the Algorithms
1.1.1.5 root 111: Freeware Status and Restrictions
112: Restrictions on Commercial Use of PGP
113: Other Licensing Restrictions
114: Distribution
1.1.1.4 root 115: Export Controls
116: Philip Zimmermann's Legal Situation
1.1.1.5 root 117: Other Sources of Information on PGP
1.1.1.4 root 118: Where to Get a Commercial Version of PGP
119: Reporting PGP Bugs
1.1.1.5 root 120: Fan Mail, Updates, and News
121: Computer-Related Political Groups
122: Recommended Readings
123: To Contact the Author
1.1.1.4 root 124: Appendix A: Where to Get PGP
125:
126:
127: Quick Overview
128: ==============
129:
130: Pretty Good(tm) Privacy (PGP), from Phil's Pretty Good Software, is a
131: high security cryptographic software application for MSDOS, Unix,
132: VAX/VMS, and other computers. PGP combines the convenience of the
133: Rivest-Shamir-Adleman (RSA) public key cryptosystem with the speed of
134: conventional cryptography, message digests for digital signatures,
135: data compression before encryption, good ergonomic design, and
136: sophisticated key management.
137:
138: This volume II of the PGP User's Guide covers advanced topics about
139: PGP that were not covered in the "PGP User's Guide, Volume I:
140: Essential Topics". You should first read the Essential Topics
141: volume, or this manual won't make much sense to you. Reading this
142: Special Topics volume is optional, except for the legal issues
143: section, which everyone should read.
144:
145:
146:
147: Special Topics
148: ===============
149:
150:
151: Selecting Keys via Key ID
152: -------------------------
153:
154: In all commands that let the user type a user ID or fragment of a
155: user ID to select a key, the hexadecimal key ID may be used instead.
156: Just use the key ID, with a prefix of "0x", in place of the user ID.
157: For example:
158:
159: pgp -kv 0x67F7
160:
161: This would display all keys that had 67F7 as part of their key IDs.
162:
163: This feature is particularly useful if you have two different keys
164: from the same person, with the same user ID. You can unambiguously
165: pick which key you want by specifying the key ID.
166:
167:
168: Separating Signatures from Messages
169: -----------------------------------
170:
171: Normally, signature certificates are physically attached to the text
172: they sign. This makes it convenient in simple cases to check
173: signatures. It is desirable in some circumstances to have signature
174: certificates stored separately from the messages they sign. It is
175: possible to generate signature certificates that are detached from
176: the text they sign. To do this, combine the 'b' (break) option with
177: the 's' (sign) option. For example:
178:
179: pgp -sb letter.txt
180:
181: This example produces an isolated signature certificate in a file
182: called "letter.sig". The contents of letter.txt are not appended to
183: the signature certificate.
184:
185: After creating the signature certificate file (letter.sig in the
186: above example), send it along with the original text file to the
187: recipient. The recipient must have both files to check the signature
188: integrity. When the recipient attempts to process the signature
189: file, PGP notices that there is no text in the same file with the
190: signature and prompts the user for the filename of the text. Only
191: then can PGP properly check the signature integrity. If the
192: recipient knows in advance that the signature is detached from the
193: text file, she can specify both filenames on the command line:
194:
195: pgp letter.sig letter.txt
196: or: pgp letter letter.txt
197:
198: PGP will not have to prompt for the text file name in this case.
199:
200: A detached signature certificate is useful if you want to keep the
201: signature certificate in a separate certificate log. A detached
202: signature of an executable program is also useful for detecting a
203: subsequent virus infection. It is also useful if more than one party
204: must sign a document such as a legal contract, without nesting
205: signatures. Each person's signature is independent.
206:
207: If you receive a ciphertext file that has the signature certificate
208: glued to the message, you can still pry the signature certificate
209: away from the message during the decryption. You can do this with
210: the -b option during decrypt, like so:
211:
212: pgp -b letter
213:
214: This decrypts the letter.pgp file and if there is a signature in it,
215: PGP checks the signature and detaches it from the rest of the
216: message, storing it in the file letter.sig.
217:
218:
219: Decrypting the Message and Leaving the Signature on it
220: ------------------------------------------------------
221:
222: Usually, you want PGP to completely unravel a ciphertext file,
223: decrypting it and checking the nested signature if there is one,
224: peeling away the layers until you are left with only the original
225: plaintext file.
226:
227: But sometimes you want to decrypt an encrypted file, and leave the
228: inner signature still attached, so that you are left with a decrypted
229: signed message. This may be useful if you want to send a copy of a
230: signed document to a third party, perhaps re-enciphering it. For
231: example, suppose you get a message signed by Charlie, encrypted to
232: you. You want to decrypt it, and, leaving Charlie's signature on it,
233: you want to send it to Alice, perhaps re-enciphering it with Alice's
234: public key. No problem. PGP can handle that.
235:
236: To simply decrypt a message and leave the signature on it intact,
237: type:
238:
239: pgp -d letter
240:
241: This decrypts letter.pgp, and if there is an inner signature, it is
242: left intact with the decrypted plaintext in the output file.
243:
244: Now you can archive it, or maybe re-encrypt it and send it to someone
245: else.
246:
247:
248:
249: Sending ASCII Text Files Across Different Machine Environments
250: --------------------------------------------------------------
251:
252: You may use PGP to encrypt any kind of plaintext file, binary 8-bit
253: data or ASCII text. Probably the most common usage of PGP will be for
254: E-mail, when the plaintext is ASCII text.
255:
256: ASCII text is sometimes represented differently on different
257: machines. For example, on an MSDOS system, all lines of ASCII text
258: are terminated with a carriage return followed by a linefeed. On a
259: Unix system, all lines end with just a linefeed. On a Macintosh, all
260: lines end with just a carriage return. This is a sad fact of life.
261:
262: Normal unencrypted ASCII text messages are often automatically
263: translated to some common "canonical" form when they are transmitted
264: from one machine to another. Canonical text has a carriage return
265: and a linefeed at the end of each line of text. For example, the
266: popular KERMIT communication protocol can convert text to canonical
267: form when transmitting it to another system. This gets converted
268: back to local text line terminators by the receiving KERMIT. This
269: makes it easy to share text files across different systems.
270:
271: But encrypted text cannot be automatically converted by a
272: communication protocol, because the plaintext is hidden by
273: encipherment. To remedy this inconvenience, PGP lets you specify
274: that the plaintext should be treated as ASCII text (not binary data)
275: and should be converted to canonical text form before it gets
276: encrypted. At the receiving end, the decrypted plaintext is
277: automatically converted back to whatever text form is appropriate for
278: the local environment.
279:
280: To make PGP assume the plaintext is text that should be converted to
281: canonical text before encryption, just add the "t" option when
282: encrypting or signing a message, like so:
283:
284: pgp -et message.txt her_userid
285:
286: This mode is automatically turned off if PGP detects that the
287: plaintext file contains what it thinks is non-text binary data.
288:
1.1.1.6 ! root 289: If you need to use the -t option a lot, you can just turn on the
! 290: TEXTMODE flag in the PGP configuration file. That's what I do.
! 291:
1.1.1.4 root 292: For PGP users that use non-English 8-bit character sets, when PGP
293: converts text to canonical form, it may convert data from the local
294: character set into the LATIN1 (ISO 8859-1 Latin Alphabet 1) character
295: set, depending on the setting of the CHARSET parameter in the PGP
296: configuration file. LATIN1 is a superset of ASCII, with extra
297: characters added for many European languages.
298:
299:
300:
1.1.1.6 ! root 301: Using PGP as a Better Uuencode
! 302: ------------------------------
! 303:
! 304: A lot of people in the Unix world send binary data files through
! 305: E-mail channels by using the Unix "uuencode" utility to convert the
! 306: file into printable ASCII characters that can be sent via email. No
! 307: encryption is involved, so neither the sender nor the recipient need
! 308: any special keys. The uuencode format was designed for a similar
! 309: purpose as PGP's radix-64 ASCII transport armor format described in
! 310: the "Sending Ciphertext Through E-mail Channels: Radix-64 Format"
! 311: section, but not as good. A different radix-64 character set is
! 312: used. Uuencode has its problems, such as 1) several slightly
! 313: incompatible character sets for different versions of uuencode in the
! 314: MSDOS and Unix worlds, and 2) the data can be corrupted by some
! 315: E-mail gateways that strip trailing blanks or do other modifications
! 316: to the character set used by uuencode.
! 317:
! 318: PGP may be used in a manner that offers the same general features as
! 319: uuencode, and then some. You can get PGP to just convert a file into
! 320: PGP's radix-64 ASCII transport armor format, but you don't have to
! 321: encrypt the file or sign it, so no keys are needed by either party.
! 322: Simply use the -a option alone. For example:
! 323:
! 324: pgp -a filename
! 325:
! 326: This would produce a radix-64 armored file called "filename.asc".
! 327:
! 328: If you read the "Sending Ciphertext Through E-mail Channels: Radix-64
! 329: Format" section, you will see that PGP's approach offers several
! 330: important advantages over the uuencode approach:
! 331:
! 332: * PGP will break big files up into chunks small enough to E-mail.
! 333: * PGP will append a CRC error detection code to each chunk.
! 334: * PGP will attempt to compress the data before converting it to
! 335: radix-64 armor.
! 336: * PGP's radix-64 character set is more resilient to E-mail character
! 337: conversions than the one used by uuencode.
! 338: * Textfiles can be converted by the sender to canonical text
! 339: format, as explained in the "Sending ASCII Text Files Across
! 340: Different Machine Environments" section.
! 341:
! 342: The recipient can restore the sender's original filename by
! 343: unwrapping the message with PGP's -p option. You can use "pgp -a" in
! 344: any situation in which you could have used uuencode, if the recipient
! 345: also has PGP. PGP is a better uuencode than uuencode.
! 346:
! 347:
! 348:
1.1.1.4 root 349: Leaving No Traces of Plaintext on the Disk
350: ------------------------------------------
351:
352: After PGP makes a ciphertext file for you, you can have PGP
353: automatically overwrite the plaintext file and delete it, leaving no
354: trace of plaintext on the disk so that no one can recover it later
355: using a disk block scanning utility. This is useful if the plaintext
356: file contains sensitive information that you don't want to keep
357: around.
358:
359: To wipe out the plaintext file after producing the ciphertext file,
360: just add the "w" (wipe) option when encrypting or signing a message,
361: like so:
362:
363: pgp -esw message.txt her_userid
364:
365: This example creates the ciphertext file "message.pgp", and the
366: plaintext file "message.txt" is destroyed beyond recovery.
367:
368: Obviously, you should be careful with this option. Also note that
369: this will not wipe out any fragments of plaintext that your word
370: processor might have created on the disk while you were editing the
371: message before running PGP. Most word processors create backup
372: files, scratch files, or both. Also, it overwrites the file only
373: once, which is enough to thwart conventional disk recovery efforts,
374: but not enough to withstand a determined and sophisticated effort to
375: recover the faint magnetic traces of the data using special disk
376: recovery hardware.
377:
378:
379:
380: Displaying Decrypted Plaintext on Your Screen
381: ---------------------------------------------
382:
383: To view the decrypted plaintext output on your screen (like the
384: Unix-style "more" command), without writing it to a file, use the -m
385: (more) option while decrypting:
386:
387: pgp -m ciphertextfile
388:
389: This displays the decrypted plaintext display on your screen one
390: screenful at a time.
391:
392:
393:
394: Making a Message For Her Eyes Only
395: ----------------------------------
396:
397: To specify that the recipient's decrypted plaintext will be shown
398: ONLY on her screen and will not be saved to disk, add the -m option:
399:
400: pgp -sem message.txt her_userid
401:
402: Later, when the recipient decrypts the ciphertext with her secret key
403: and pass phrase, the plaintext will be displayed on her screen but
404: will not be saved to disk. The text will be displayed as it would if
405: she used the Unix "more" command, one screenful at a time. If she
406: wants to read the message again, she will have to decrypt the
407: ciphertext again.
408:
409: This feature is the safest way for you to prevent your sensitive
410: message from being inadvertently left on the recipient's disk. This
411: feature was added at the request of a user who wanted to send
412: intimate messages to his lover, but was afraid she might accidentally
413: leave the decrypted messages on her husband's computer.
414:
415: Note that this feature will not prevent a clever and determined
416: person from finding a way to save the decrypted plaintext to disk--
417: it's to help prevent a casual user from doing it inadvertently.
418:
419:
420:
421: Preserving the Original Plaintext Filename
422: ------------------------------------------
423:
424: Normally, PGP names the decrypted plaintext output file with a name
425: similar to the input ciphertext filename, but dropping the
426: extension. Or, you can override that convention by specifying an
427: output plaintext filename on the command line with the -o option.
428: For most E-mail, this is a reasonable way to name the plaintext file,
429: because you get to decide its name when you decipher it, and your
430: typical E-mail messages often come from useless original plaintext
431: filenames like "to_phil.txt".
432:
433: But when PGP encrypts a plaintext file, it always saves the original
434: filename and attaches it to the plaintext before it compresses and
435: encrypts the plaintext. Normally, this hidden original filename is
436: discarded by PGP when it decrypts, but you can tell PGP you want to
437: preserve the original plaintext filename and use it as the name of
438: the decrypted plaintext output file. This is useful if PGP is used
439: on files whose names are important to preserve.
440:
441: To recover the original plaintext filename while decrypting, add
442: the -p option, like so:
443:
444: pgp -p ciphertextfile
445:
446: I usually don't use this option, because if I did, about half of my
447: incoming E-mail would decrypt to the same plaintext filenames of
448: "to_phil.txt" or "prz.txt".
449:
450:
451:
452: Editing Your User ID or Pass Phrase
453: -----------------------------------
454:
455: Sometimes you may need to change your pass phrase, perhaps because
456: someone looked over your shoulder while you typed it in.
457:
458: Or you may need to change your user ID, because you got married and
459: changed your name, or maybe you changed your E-mail address. Or
460: maybe you want to add a second or third user ID to your key, because
461: you may be known by more than one name or E-mail address or job
462: title. PGP lets you attach more than one user ID to your key, any
463: one of which may be used to look up your key on the key ring.
464:
465: To edit your own userid or pass phrase for your secret key:
466:
467: pgp -ke userid [keyring]
468:
469: PGP prompts you for a new user ID or a new pass phrase.
470:
1.1.1.5 root 471: If you edit your user ID, PGP actually adds a new user ID, without
472: deleting the old one. If you want to delete an old user ID, you will
473: have to do that in a separate operation.
474:
1.1.1.4 root 475: The optional [keyring] parameter, if specified, must be a public
476: keyring, not a secret keyring. The userid field must be your own
477: userid, which PGP knows is yours because it appears on both your
478: public keyring and your secret keyring. Both keyrings will be
479: updated, even though you only specified the public keyring.
480:
481: The -ke command works differently depending on whether you use it on
482: a public or secret key. It can also be used to edit the trust
483: parameters for a public key.
484:
485:
486: Editing the Trust Parameters for a Public Key
487: ---------------------------------------------
488:
489: Sometimes you need to alter the trust parameters for a public key on
490: your public key ring. For a discussion on what these trust
491: parameters mean, see the section "How Does PGP Keep Track of Which
492: Keys are Valid?" in the Essential Topics volume of the PGP User's
493: Guide.
494:
495: To edit the trust parameters for a public key:
496:
497: pgp -ke userid [keyring]
498:
499: The optional [keyring] parameter, if specified, must be a public
500: keyring, not a secret keyring.
501:
502:
503:
504: Checking If Everything is OK on Your Public Key Ring
505: ----------------------------------------------------
506:
507: Normally, PGP automatically checks any new keys or signatures on your
508: public key ring and updates all the trust parameters and validity
509: scores. In theory, it keeps all the key validity status information
510: up to date as material is added to or deleted from your public key
511: ring. But perhaps you may want to explicitly force PGP to perform a
512: comprehensive analysis of your public key ring, checking all the
513: certifying signatures, checking the trust parameters, updating all
514: the validity scores, and checking your own ultimately-trusted key
515: against a backup copy on a write-protected floppy disk. It may be a
516: good idea to do this hygienic maintenance periodically to make sure
517: nothing is wrong with your public key ring. To force PGP to perform
518: a full analysis of your public key ring, use the -kc (key ring check)
519: command:
520:
521: pgp -kc
522:
523: You can also make PGP check all the signatures for just a single
524: selected public key by:
525:
526: pgp -kc userid [keyring]
527:
528: For further information on how the backup copy of your own key is
529: checked, see the description of the BAKRING parameter in the
530: configuration file section of this manual.
531:
532:
533:
534: Verifying a Public Key Over the Phone
535: -------------------------------------
536:
537: If you get a public key from someone that is not certified by anyone
538: you trust, how can you tell if it's really their key? The best way
539: to verify an uncertified key is to verify it over some independent
540: channel other than the one you received the key through. One
541: convenient way to tell, if you know this person and would recognize
542: them on the phone, is to call them and verify their key over the
543: telephone. Rather than reading their whole tiresome (ASCII-armored)
544: key to them over the phone, you can just read their key's
545: "fingerprint" to them. To see this fingerprint, use the -kvc
546: command:
547:
548: pgp -kvc userid [keyring]
549:
550: This will display the key with the 16-byte digest of the public key
551: components. Read this 16-byte fingerprint to the key's owner on the
552: phone, while she checks it against her own, using the same -kvc
553: command at her end.
554:
555: You can both verify each other's keys this way, and then you can sign
556: each other's keys with confidence. This is a safe and convenient way
557: to get the key trust network started for your circle of friends.
558:
559: Note that sending a key fingerprint via E-mail is not the best way to
560: verify the key, because E-mail can be intercepted and modified. It's
561: best to use a different channel than the one that was used to send
562: the key itself. A good combination is to send the key via E-mail,
563: and the key fingerprint via a voice telephone conversation. Some
564: people distribute their key fingerprint on their business cards,
565: which looks really cool.
566:
1.1.1.5 root 567: For current versions of PGP, the key fingerprint is computed using
568: the MD5 hash function. A future version of PGP will optionally use a
569: new and different hash function, SHA, instead of MD5.
570:
1.1.1.4 root 571: If you don't know me, please don't call me to verify my key over the
572: phone-- I get too many calls like that. Since every PGP user has a
573: copy of my public key, no one could tamper with all the copies that
574: are out there. The discrepancy would soon be noticed by someone who
575: checked it from more than one source, and word would soon get out on
576: the Internet.
577:
1.1.1.5 root 578: For those of you who want to verify my public key (included in the
579: standard PGP release package), here are the particulars:
580:
581: UserID: "Philip R. Zimmermann <[email protected]>"
582: Key Size: 1024 bits; Creation date: 21 May 1993; KeyID: C7A966DD
583: Key fingerprint: 9E 94 45 13 39 83 5F 70 7B E7 D8 ED C4 BE 5A A6
584:
585: The information printed above conceivably could still be tampered
586: with in the electronic distribution of the PGP User's Guide. But if
587: you read this in the printed version of the manual, available in
588: bookstores from MIT Press, it's a safe bet that it really is my own
589: key's fingerprint.
1.1.1.4 root 590:
591:
592: Handling Large Public Keyrings
593: ------------------------------
594:
595: PGP was originally designed for handling small personal keyrings for
596: keeping all your friends on, like a personal rolodex. A couple
597: hundred keys is a reasonable size for such a keyring. But as PGP has
598: become more popular, people are now trying to add other large
599: keyrings to their own keyring. Sometimes this involves adding
600: thousands of keys to your keyring. PGP, in its present form, cannot
601: perform this operation in a reasonable period of time, while you wait
602: at your keyboard. Not for huge keyrings.
603:
604: You may want to add a huge "imported" keyring to your own keyring,
605: because you are only interested in a few dozen keys on the bigger
606: keyring you are bringing in. If that's all you want from the other
607: keyring, it would be more efficient if you extract the few keys you
608: need from the big foreign keyring, and then add just these few keys
609: to your own keyring. Use the -kx command to extract them from the
610: foreign keyring, specifying the keyring name on the command line.
611: Then add these extracted keys to your own keyring.
612:
613: The real solution is to improve PGP to use advanced database
1.1.1.5 root 614: techniques to manage large keyrings efficiently. We are working on
615: this, and should have it done Real Soon Now. Until this happens, you
616: will just have to use smaller keyrings, or be patient.
1.1.1.4 root 617:
618:
619:
620: Using PGP as a Unix-style Filter
621: --------------------------------
622:
623: Unix fans are accustomed to using Unix "pipes" to make two
624: applications work together. The output of one application can be
625: directly fed through a pipe to be read as input to another
626: application. For this to work, the applications must be capable of
627: reading the raw material from "standard input" and writing the
628: finished output to "standard output". PGP can operate in this mode.
629: If you don't understand what this means, then you probably don't need
630: this feature.
631:
632: To use a Unix-style filter mode, reading from standard input and
633: writing to standard output, add the -f option, like so:
634:
635: pgp -feast her_userid <inputfile >outputfile
636:
637: This feature makes it easier to make PGP work with electronic mail
638: applications.
639:
640: When using PGP in filter mode to decrypt a ciphertext file, you may
641: find it useful to use the PGPPASS environmental variable to hold the
642: pass phrase, so that you won't be prompted for it. The PGPPASS
643: feature is explained below.
644:
645:
646: Suppressing Unnecessary Questions: BATCHMODE
647: ----------------------------------------------
648:
649: With the BATCHMODE flag enabled on the command line, PGP will not ask
650: any unnecessary questions or prompt for alternate filenames. Here
651: is an example of how to set this flag:
652:
653: pgp +batchmode cipherfile
654:
655: This is useful for running PGP non-interactively from Unix shell
656: scripts or MSDOS batch files. Some key management commands still
657: need user interaction even when BATCHMODE is on, so shell scripts may
658: need to avoid them.
659:
660: BATCHMODE may also be enabled to check the validity of a signature on
661: a file. If there was no signature on the file, the exit code is 1.
662: If it had a signature that was good, the exit code is 0.
663:
664:
665: Force "Yes" Answer to Confirmation Questions: FORCE
666: ----------------------------------------------------
667:
668: This command-line flag makes PGP assume "yes" for the user response
669: to the confirmation request to overwrite an existing file, or when
670: removing a key from the keyring via the -kr command. Here is an
671: example of how to set this flag:
672:
673: pgp +force cipherfile
674: or:
675: pgp -kr +force Smith
676:
677: This feature is useful for running PGP non-interactively from a Unix
678: shell script or MSDOS batch file.
679:
680:
681:
682: PGP Returns Exit Status to the Shell
683: ------------------------------------
684:
685: To facilitate running PGP in "batch" mode, such as from an MSDOS
686: ".bat" file or from a Unix shell script, PGP returns an error exit
687: status to the shell. An exit status code of zero means normal exit,
688: while a nonzero exit status indicates some kind of error occurred.
689: Different error exit conditions return different exit status codes to
690: the shell.
691:
692:
693:
694: Environmental Variable for Pass Phrase
695: --------------------------------------
696:
697: Normally, PGP prompts the user to type a pass phrase whenever PGP
698: needs a pass phrase to unlock a secret key. But it is possible to
699: store the pass phrase in an environmental variable from your
700: operating system's command shell. The environmental variable PGPPASS
701: can be used to hold the pass phrase that PGP will attempt to use
702: first. If the pass phrase stored in PGPPASS is incorrect, PGP
703: recovers by prompting the user for the correct pass phrase.
704:
705: For example, on MSDOS, the shell command:
706:
707: SET PGPPASS=zaphod beeblebrox for president
708:
709: would eliminate the prompt for the pass phrase if the pass phrase
710: were indeed "zaphod beeblebrox for president".
711:
712: This dangerous feature makes your life more convenient if you have to
713: regularly deal with a large number of incoming messages addressed to
714: your secret key, by eliminating the need for you to repeatedly type
715: in your pass phrase every time you run PGP.
716:
717: I added this feature because of popular demand. However, this is a
718: somewhat dangerous feature, because it keeps your precious pass
719: phrase stored somewhere other than just in your brain. Even worse,
720: if you are particularly reckless, it may even be stored on a disk on
721: the same computer as your secret key. It would be particularly
722: dangerous and stupid if you were to install this command in a batch
723: or script file, such as the MSDOS AUTOEXEC.BAT file. Someone could
724: come along on your lunch hour and steal both your secret key ring and
725: the file containing your pass phrase.
726:
727: I can't emphasize the importance of this risk enough. If you are
728: contemplating using this feature, be sure to read the sections
729: "Exposure on Multi-user Systems" and "How to Protect Secret Keys from
730: Disclosure" in this volume and in the Essential Topics volume of the
731: PGP User's Guide.
732:
733: If you must use this feature, the safest way to do it would be to
734: just manually type in the shell command to set PGPPASS every time you
735: boot your machine to start using PGP, and then erase it or turn off
736: your machine when you are done. And you should definitely never do
737: it in an environment where someone else may have access to your
738: machine. Someone could come along and simply ask your computer to
739: display the contents of PGPPASS.
740:
1.1.1.5 root 741: Sometimes you want to pass the pass phrase into PGP from another
742: application, such as an E-mail package. In some cases, it may not
743: always be desirable to use the PGPPASS variable for that purpose.
744: There is another way to pass your pass phrase into PGP from another
745: application. Use the "-z" command line option. This option is
746: designed primarily for invoking PGP from inside an E-mail package.
747: The pass phrase follows the -z option on the command line. There are
748: risks associated with using this approach, similar to those risks
749: described above for using the PGPPASS variable.
1.1.1.4 root 750:
751:
1.1.1.6 ! root 752: Setting Parameters in the PGP Configuration File
! 753: ================================================
1.1.1.4 root 754:
755: PGP has a number of user-settable parameters that can be defined in a
1.1.1.6 ! root 756: special PGP configuration text file called "config.txt", in the
! 757: directory pointed to by the shell environmental variable PGPPATH.
! 758: Having a configuration file enables the user to define various flags
! 759: and parameters for PGP without the burden of having to always define
1.1.1.4 root 760: these parameters in the PGP command line.
761:
1.1.1.6 ! root 762: The filename "config.txt" has been in use for a long time by PGP, but
! 763: some folks have pointed out that it may be at odds with naming
! 764: conventions for configuration files for specific operating systems.
! 765: Accordingly, PGP now tries to open this filename only after first
! 766: trying to open the file ".pgprc" on Unix platforms, and "pgp.ini" on
! 767: other platforms, in the same directory that PGP would look for
! 768: "config.txt".
! 769:
1.1.1.4 root 770: Configuration parameters may be assigned integer values, character
771: string values, or on/off values, depending on what kind of
772: configuration parameter it is. A sample configuration file is
773: provided with PGP, so you can see some examples.
774:
775: In the configuration file, blank lines are ignored, as is anything
776: following the '#' comment character. Keywords are not
777: case-sensitive.
778:
779: Here is a short sample fragment of a typical configuration file:
780:
781: # TMP is the directory for PGP scratch files, such as a RAM disk.
782: TMP = "e:\" # Can be overridden by environment variable TMP.
783: Armor = on # Use -a flag for ASCII armor whenever applicable.
784: # CERT_DEPTH is how deeply introducers may introduce introducers.
785: cert_depth = 3
786:
787: If some configuration parameters are not defined in the configuration
788: file, or if there is no configuration file, or if PGP can't find the
789: configuration file, the values for the configuration parameters
790: default to some reasonable value.
791:
792: Note that it is also possible to set these same configuration
793: parameters directly from the PGP command line, by preceding the
794: parameter setting with a "+" character. For example, the following
795: two PGP commands produce the same effect:
796:
797: pgp -e +armor=on message.txt smith
798: or: pgp -ea message.txt smith
799:
800:
801: The following is a summary of the various parameters than may be
802: defined in the configuration file.
803:
804:
805: TMP - Directory Pathname for Temporary Files
806: --------------------------------------------
807:
808: Default setting: TMP = ""
809:
810: The configuration parameter TMP specifies what directory to use for
811: PGP's temporary scratch files. The best place to put them is on a
812: RAM disk, if you have one. That speeds things up quite a bit, and
813: increases security somewhat. If TMP is undefined, the temporary
814: files go in the current directory. If the shell environmental
815: variable TMP is defined, PGP instead uses that to specify where the
816: temporary files should go.
817:
818:
819: LANGUAGE - Foreign Language Selector
820: ------------------------------------
821:
822: Default setting: LANGUAGE = "en"
823:
824: PGP displays various prompts, warning messages, and advisories to the
825: user on the screen. For example, messages such as "File not found.",
826: or "Please enter your pass phrase:". These messages are normally in
827: English. But it is possible to get PGP to display its messages to
828: the user in other languages, without having to modify the PGP
829: executable program.
830:
831: A number of people in various countries have translated all of PGP's
832: display messages, warnings, and prompts into their native languages.
833: These hundreds of translated message strings have been placed in a
834: special text file called "language.txt", distributed with the PGP
835: release. The messages are stored in this file in English, Spanish,
836: Dutch, German, French, Italian, Russian, Latvian, and Lithuanian.
837: Other languages may be added later.
838:
839: The configuration parameter LANGUAGE specifies what language to
840: display these messages in. LANGUAGE may be set to "en" for English,
841: "es" for Spanish, "de" for German, "nl" for Dutch, "fr" for French,
842: "it" for Italian, "ru" for Russian, "lt3" for Lithuanian, "lv" for
843: Latvian, "esp" for Esperanto. For example, if this line appeared in
844: the configuration file:
845:
846: LANGUAGE = "fr"
847:
848: PGP would select French as the language for its display messages.
849: The default setting is English.
850:
851: When PGP needs to display a message to the user, it looks in the
852: "language.txt" file for the equivalent message string in the selected
853: foreign language and displays that translated message to the user.
854: If PGP can't find the language string file, or if the selected
855: language is not in the file, or if that one phrase is not translated
856: into the selected language in the file, or if that phrase is missing
857: entirely from the file, PGP displays the message in English.
858:
859: To conserve disk space, most foreign translations are not included
860: in the standard PGP release package, but are available separately.
861:
862:
863: MYNAME - Default User ID for Making Signatures
864: ----------------------------------------------
865:
866: Default setting: MYNAME = ""
867:
868: The configuration parameter MYNAME specifies the default user ID to
869: use to select the secret key for making signatures. If MYNAME is not
870: defined, the most recent secret key you installed on your secret key
871: ring will be used. The user may also override this setting by
872: specifying a user ID on the PGP command line with the -u option.
873:
874:
875: TEXTMODE - Assuming Plaintext is a Text File
876: --------------------------------------------
877:
878: Default setting: TEXTMODE = off
879:
880: The configuration parameter TEXTMODE is equivalent to the -t command
881: line option. If enabled, it causes PGP to assume the plaintext is a
882: text file, not a binary file, and converts it to "canonical text"
883: before encrypting it. Canonical text has a carriage return and a
884: linefeed at the end of each line of text.
885:
886: This mode will be automatically turned off if PGP detects that the
887: plaintext file contains what it thinks is non-text binary data. If
888: you intend to use PGP primarily for E-mail purposes, you should turn
889: TEXTMODE=ON.
890:
891: For VAX/VMS systems, the current version of PGP defaults TEXTMODE=ON.
892:
893: For further details, see the section "Sending ASCII Text Files Across
894: Different Machine Environments".
895:
896:
897: CHARSET - Specifies Local Character Set for Text Files
898: ------------------------------------------------------
899:
900: Default setting: CHARSET = NOCONV
901:
902: Because PGP must process messages in many non-English languages with
903: non-ASCII character sets, you may have a need to tell PGP what local
904: character set your machine uses. This determines what character
905: conversions are performed when converting plaintext files to and from
906: canonical text format. This is only a concern if you are in a
907: non-English non-ASCII environment.
908:
909: The configuration parameter CHARSET selects the local character set.
910: The choices are NOCONV (no conversion), LATIN1 (ISO 8859-1 Latin
911: Alphabet 1), KOI8 (used by most Russian Unix systems), ALT_CODES
912: (used by Russian MSDOS systems), ASCII, and CP850 (used by most
913: western European languages on standard MSDOS PCs).
914:
915: LATIN1 is the internal representation used by PGP for canonical text,
916: so if you select LATIN1, no conversion is done. Note also that PGP
917: treats KOI8 as LATIN1, even though it is a completely different
918: character set (Russian), because trying to convert KOI8 to either
919: LATIN1 or CP850 would be futile anyway. This means that setting
920: CHARSET to NOCONV, LATIN1, or KOI8 are all equivalent to PGP.
921:
922: If you use MSDOS and expect to send or receive traffic in western
923: European languages, set CHARSET = "CP850". This will make PGP
924: convert incoming canonical text messages from LATIN1 to CP850 after
925: decryption. If you use the -t (textmode) option to convert to
926: canonical text, PGP will convert your CP850 text to LATIN1 before
927: encrypting it.
928:
929: For further details, see the section "Sending ASCII Text Files Across
930: Different Machine Environments".
931:
932:
933: ARMOR - Enable ASCII Armor Output
934: ---------------------------------
935:
936: Default setting: ARMOR = off
937:
938: The configuration parameter ARMOR is equivalent to the -a command
939: line option. If enabled, it causes PGP to emit ciphertext or keys in
940: ASCII Radix-64 format suitable for transporting through E-mail
941: channels. Output files are named with the ".asc" extension.
942:
943: If you intend to use PGP primarily for E-mail purposes, you should
944: turn ARMOR=ON.
945:
946: For further details, see the section "Sending Ciphertext Through
947: E-mail Channels: Radix-64 Format" in the Essential Topics volume.
948:
949:
950: ARMORLINES - Size of ASCII Armor Multipart Files
951: ------------------------------------------------
952:
953: Default setting: ARMORLINES = 720
954:
955: When PGP creates a very large ".asc" radix-64 file for sending
956: ciphertext or keys through the E-mail, it breaks the file up into
957: separate chunks small enough to send through Internet mail
958: utilities. Normally, Internet mailers prohibit files larger than
959: about 50000 bytes, which means that if we restrict the number of
960: lines to about 720, we'll be well within the limit. The file chunks
961: are named with suffixes ".as1", ".as2", ".as3", ...
962:
963: The configuration parameter ARMORLINES specifies the maximum number
964: of lines to make each chunk in a multipart ".asc" file sequence. If
965: you set it to zero, PGP will not break up the file into chunks.
966:
1.1.1.5 root 967: Fidonet E-mail files usually have an upper limit of about 32K bytes,
1.1.1.4 root 968: so 450 lines would be appropriate for Fidonet environments.
969:
970: For further details, see the section "Sending Ciphertext Through
971: E-mail Channels: Radix-64 Format" in the Essential Topics volume.
972:
973:
974: KEEPBINARY - Keep Binary Ciphertext Files After Decrypting
975: ----------------------------------------------------------
976:
977: Default setting: KEEPBINARY = off
978:
979: When PGP reads a ".asc" file, it recognizes that the file is in
980: radix-64 format and will convert it back to binary before processing
981: as it normally does, producing as a by-product a ".pgp" ciphertext
982: file in binary form. After further processing to decrypt the ".pgp"
983: file, the final output file will be in normal plaintext form.
984:
985: You may want to delete the binary ".pgp" intermediate file, or you
986: may want PGP to delete it for you automatically. You can still rerun
987: PGP on the original ".asc" file.
988:
989: The configuration parameter KEEPBINARY enables or disables keeping
990: the intermediate ".pgp" file during decryption.
991:
992: For further details, see the section "Sending Ciphertext Through
993: E-mail Channels: Radix-64 Format" in the Essential Topics volume.
994:
995:
996: COMPRESS - Enable Compression
997: -----------------------------
998:
999: Default setting: COMPRESS = on
1000:
1001: The configuration parameter COMPRESS enables or disables data
1002: compression before encryption. It is used mainly for debugging PGP.
1003: Normally, PGP attempts to compress the plaintext before it encrypts
1004: it. Generally, you should leave this alone and let PGP attempt to
1005: compress the plaintext.
1006:
1007:
1008: COMPLETES_NEEDED - Number of Completely Trusted Introducers Needed
1009: ------------------------------------------------------------------
1010:
1011: Default setting: COMPLETES_NEEDED = 1
1012:
1013: The configuration parameter COMPLETES_NEEDED specifies the minimum
1014: number of completely trusted introducers required to fully certify a
1015: public key on your public key ring. This gives you a way of tuning
1016: PGP's skepticism.
1017:
1018: For further details, see the section "How Does PGP Keep Track of
1019: Which Keys are Valid?" in the Essential Topics volume.
1020:
1021:
1022: MARGINALS_NEEDED - Number of Marginally Trusted Introducers Needed
1023: ------------------------------------------------------------------
1024:
1025: Default setting: MARGINALS_NEEDED = 2
1026:
1027: The configuration parameter MARGINALS_NEEDED specifies the minimum
1028: number of marginally trusted introducers required to fully certify a
1029: public key on your public key ring. This gives you a way of tuning
1030: PGP's skepticism.
1031:
1032: For further details, see the section "How Does PGP Keep Track of
1033: Which Keys are Valid?" in the Essential Topics volume.
1034:
1035:
1036: CERT_DEPTH - How Deep May Introducers Be Nested
1037: -----------------------------------------------
1038:
1039: Default setting: CERT_DEPTH = 4
1040:
1041: The configuration parameter CERT_DEPTH specifies how many levels deep
1042: you may nest introducers to certify other introducers to certify
1043: public keys on your public key ring. For example, If CERT_DEPTH is
1044: set to 1, there may only be one layer of introducers below your own
1045: ultimately-trusted key. If that were the case, you would be required
1046: to directly certify the public keys of all trusted introducers on
1047: your key ring. If you set CERT_DEPTH to 0, you could have no
1048: introducers at all, and you would have to directly certify each and
1049: every key on your public key ring in order to use it. The minimum
1050: CERT_DEPTH is 0, the maximum is 8.
1051:
1052: For further details, see the section "How Does PGP Keep Track of
1053: Which Keys are Valid?" in the Essential Topics volume.
1054:
1055:
1056: BAKRING - Filename for Backup Secret Keyring
1057: --------------------------------------------
1058:
1059: Default setting: BAKRING = ""
1060:
1061: All of the key certification that PGP does on your public key ring
1062: ultimately depends on your own ultimately-trusted public key (or
1063: keys). To detect any tampering of your public key ring, PGP must
1064: check that your own key has not been tampered with. To do this, PGP
1065: must compare your public key against a backup copy of your secret key
1066: on some tamper-resistant media, such as a write-protected floppy
1067: disk. A secret key contains all the information that your public key
1068: has, plus some secret components. This means PGP can check your
1069: public key against a backup copy of your secret key.
1070:
1071: The configuration parameter BAKRING specifies what pathname to use
1072: for PGP's trusted backup copy of your secret key ring. On MSDOS, you
1073: could set it to "a:\secring.pgp" to point it at a write-protected
1074: backup copy of your secret key ring on your floppy drive. This check
1075: is performed only when you execute the PGP -kc option to check your
1076: whole public key ring.
1077:
1078: If BAKRING is not defined, PGP will not check your own key against
1079: any backup copy.
1080:
1081: For further details, see the sections "How to Protect Public Keys
1082: from Tampering" and "How Does PGP Keep Track of Which Keys are
1083: Valid?" in the Essential Topics volume.
1084:
1085:
1086: PUBRING - Filename for Your Public Keyring
1087: ------------------------------------------
1088:
1089: Default setting: PUBRING = "$PGPPATH/pubring.pgp"
1090:
1091: You may want to keep your public keyring in a directory separate from
1.1.1.6 ! root 1092: your PGP configuration file in the directory specified by your
! 1093: $PGPPATH environmental variable. You may specify the full path and
! 1094: filename for your public keyring by setting the PUBRING parameter.
! 1095: For example, on an MSDOS system, you might want to keep your public
1.1.1.4 root 1096: keyring on a floppy disk by:
1097:
1098: PUBRING = "a:pubring.pgp"
1099:
1100: This feature is especially handy for specifying an alternative
1101: keyring on the command line.
1102:
1103:
1104: SECRING - Filename for Your Secret Keyring
1105: ------------------------------------------
1106:
1107: Default setting: SECRING = "$PGPPATH/secring.pgp"
1108:
1109: You may want to keep your secret keyring in a directory separate from
1.1.1.6 ! root 1110: your PGP configuration file in the directory specified by your
! 1111: $PGPPATH environmental variable. This comes in handy for putting
! 1112: your secret keyring in a directory or device that is more protected
! 1113: than your public keyring. You may specify the full path and filename
! 1114: for your secret keyring by setting the SECRING parameter. For
! 1115: example, on an MSDOS system, you might want to keep your secret
! 1116: keyring on a floppy disk by:
1.1.1.4 root 1117:
1118: SECRING = "a:secring.pgp"
1119:
1120:
1121: RANDSEED - Filename for Random Number Seed
1122: ------------------------------------------
1123:
1124: Default setting: RANDSEED = "$PGPPATH/randseed.bin"
1125:
1126: You may want to keep your random number seed file (for generation of
1.1.1.6 ! root 1127: session keys) in a directory separate from your PGP configuration file
! 1128: in the directory specified by your $PGPPATH environmental variable.
1.1.1.4 root 1129: This comes in handy for putting your random number seed file in a
1130: directory or device that is more protected than your public keyring.
1131: You may specify the full path and filename for your random seed file
1132: by setting the RANDSEED parameter. For example, on an MSDOS system,
1133: you might want to keep it on a floppy disk by:
1134:
1135: RANDSEED = "a:randseed.bin"
1136:
1137:
1138: PAGER - Selects Shell Command to Display Plaintext Output
1139: ---------------------------------------------------------
1140:
1141: Default setting: PAGER = ""
1142:
1143: PGP lets you view the decrypted plaintext output on your screen (like
1144: the Unix-style "more" command), without writing it to a file, if you
1145: use the -m (more) option while decrypting. This displays the
1146: decrypted plaintext display on your screen one screenful at a time.
1147:
1148: If you prefer to use a fancier page display utility, rather than
1149: PGP's built-in one, you can specify the name of a shell command that
1150: PGP will invoke to display your plaintext output file. The
1151: configuration parameter PAGER specifies the shell command to invoke
1152: to display the file. For example, on MSDOS systems, you might want
1153: to use the popular shareware program "list.com" to display your
1154: plaintext message. Assuming you have a copy of "list.com", you may
1155: set PAGER accordingly:
1156:
1157: PAGER = "list"
1158:
1159: However, if the sender specified that this file is for your eyes
1160: only, and may not be written to disk, PGP always uses its own
1161: built-in display function.
1162:
1163: For further details, see the section "Displaying Decrypted Plaintext
1164: on Your Screen".
1165:
1166:
1167: SHOWPASS - Echo Pass Phrase to User
1168: -----------------------------------
1169:
1170: Default setting: SHOWPASS = off
1171:
1172: Normally, PGP does not let you see your pass phrase as you type it
1173: in. This makes it harder for someone to look over your shoulder
1174: while you type and learn your pass phrase. But some typing-impaired
1175: people have problems typing their pass phrase without seeing what
1176: they are typing, and they may be typing in the privacy of their own
1177: homes. So they asked if PGP can be configured to let them see what
1178: they type when they type in their pass phrase.
1179:
1180: The configuration parameter SHOWPASS enables PGP to echo your typing
1181: during pass phrase entry.
1182:
1183:
1184: TZFIX - Timezone Adjustment
1185: ---------------------------
1186:
1187: Default setting: TZFIX = 0
1188:
1189: PGP provides timestamps for keys and signature certificates in
1190: Greenwich Mean Time (GMT), or Coordinated Universal Time (UTC), which
1191: means the same thing for our purposes. When PGP asks the system for
1192: the time of day, the system is supposed to provide it in GMT.
1193:
1194: But sometimes, because of improperly configured MSDOS systems, the
1195: system time is returned in US Pacific Standard Time time plus 8
1196: hours. Sounds weird, doesn't it? Perhaps because of some sort of US
1197: west-coast jingoism, MSDOS presumes local time is US Pacific time,
1198: and pre-corrects Pacific time to GMT. This adversely affects the
1199: behavior of the internal MSDOS GMT time function that PGP calls.
1200: However, if your MSDOS environmental variable TZ is already properly
1201: defined for your timezone, this corrects the misconception MSDOS has
1202: that the whole world lives on the US west coast.
1203:
1204: The configuration parameter TZFIX specifies the number of hours to
1205: add to the system time function to get GMT, for GMT timestamps on
1206: keys and signatures. If the MSDOS environmental variable TZ is
1207: defined properly, you can leave TZFIX=0. Unix systems usually
1208: shouldn't need to worry about setting TZFIX at all. But if you are
1209: using some other obscure operating system that doesn't know about
1210: GMT, you may have to use TZFIX to adjust the system time to GMT.
1211:
1212: On MSDOS systems that do not have TZ defined in the environment, you
1213: should make TZFIX=0 for California, -1 for Colorado, -2 for Chicago,
1214: -3 for New York, -8 for London, -9 for Amsterdam. In the summer,
1215: TZFIX should be manually decremented from these values. What a mess.
1216:
1217: It would be much cleaner to set your MSDOS environmental variable TZ
1218: in your AUTOEXEC.BAT file, and not use the TZFIX correction. Then
1219: MSDOS gives you good GMT timestamps, and will handle daylight savings
1220: time adjustments for you. Here are some sample lines to insert into
1221: AUTOEXEC.BAT, depending on your time zone:
1222:
1223: For Los Angeles: SET TZ=PST8PDT
1224: For Denver: SET TZ=MST7MDT
1225: For Arizona: SET TZ=MST7
1226: (Arizona never uses daylight savings time)
1227: For Chicago: SET TZ=CST6CDT
1228: For New York: SET TZ=EST5EDT
1229: For London: SET TZ=GMT0BST
1230: For Amsterdam: SET TZ=MET-1DST
1231: For Moscow: SET TZ=MSK-3MSD
1232: For Aukland: SET TZ=NZT-13
1233:
1234:
1235: CLEARSIG - Enable Signed Messages to be Encapsulated as Clear Text
1236: ------------------------------------------------------------------
1237:
1238: Default setting: CLEARSIG = on
1239:
1240: Normally, unencrypted PGP signed messages have a signature
1241: certificate prepended in binary form. Also, the signed message is
1242: compressed, rendering the message unreadable to casual human eyes,
1243: even though the message is not actually encrypted. To send this
1244: binary data through a 7-bit E-mail channel, radix-64 ASCII armor is
1245: applied (see the ARMOR parameter). Even if PGP didn't compress the
1246: message, the ASCII armor would still render the message unreadable to
1247: human eyes. The recipient must use PGP to strip the armor off and
1248: decompress it before reading the message.
1249:
1250: If the original plaintext message is in text (not binary) form, there
1251: is a way to send a signed message through an E-mail channel in such a
1252: way that the signed message is not compressed and the ASCII armor is
1253: applied only to the binary signature certificate, but not to the
1254: plaintext message. The CLEARSIG flag provides this useful feature,
1255: making it possible to generate a signed message that can be read with
1256: human eyes, without the aid of PGP. Of course, you still need PGP to
1257: actually check the signature.
1258:
1259: The CLEARSIG flag is preset to "on" beginning with PGP version 2.5.
1260: To enable the full CLEARSIG behavior, the ARMOR and TEXTMODE flags
1261: must also be turned on. Set ARMOR=ON (or use the -a option), and set
1262: TEXTMODE=ON (or use the -t option). If your config file has CLEARSIG
1263: turned off, you can turn it back on again directly on the command
1264: line, like so:
1265:
1266: pgp -sta +clearsig=on message.txt
1267:
1268: This message representation is analogous to the MIC-CLEAR message type
1269: used in Internet Privacy Enhanced Mail (PEM). It is important to
1270: note that since this method only applies ASCII armor to the binary
1271: signature certificate, and not to the message text itself, there is
1272: some risk that the unarmored message may suffer some accidental
1273: molestation while en route. This can happen if it passes through
1274: some E-mail gateway that performs character set conversions, or in
1275: some cases extra spaces may be added to or stripped from the ends of
1276: lines. If this occurs, the signature will fail to verify, which may
1277: give a false indication of intentional tampering. But since PEM
1278: lives under a similar vulnerability, it seems worth having this
1279: feature despite the risks.
1280:
1281: Beginning with PGP version 2.2, trailing blanks are ignored on each
1282: line in calculating the signature for text in CLEARSIG mode.
1283:
1284:
1285: VERBOSE - Quiet, Normal, or Verbose Messages
1286: --------------------------------------------
1287:
1288: Default setting: VERBOSE = 1
1289:
1290: VERBOSE may be set to 0, 1, or 2, depending on how much detail you
1291: want to see from PGP diagnostic messages. The settings are:
1292:
1293: 0 - Display messages only if there is a problem. Unix fans wanted
1294: this "quiet mode" setting.
1295:
1296: 1 - Normal default setting. Displays a reasonable amount of detail
1297: in diagnostic or advisory messages.
1298:
1299: 2 - Displays maximum information, usually to help diagnose problems
1300: in PGP. Not recommended for normal use. Besides, PGP doesn't have
1301: any problems, right?
1302:
1303:
1304: INTERACTIVE - Ask for Confirmation for Key Adds
1305: -----------------------------------------------
1306:
1307: Default Setting: INTERACTIVE = off
1308:
1309: Enabling this mode will mean that if you add a key file containing
1310: multiple keys to your key ring, PGP will ask for confirmation for
1311: each key before adding it to your key ring.
1312:
1313:
1314: NOMANUAL - Let PGP Generate Keys Without the Manual
1315: ---------------------------------------------------
1316:
1317: Default Setting: NOMANUAL = off
1318:
1319: It is important that the freeware version of PGP not be distributed
1320: without the user documentation, which normally comes with it in the
1321: standard release package. This manual contains important information
1322: for using PGP, as well as important legal notices. But some people
1323: have distributed previous versions of PGP without the manual, causing
1324: a lot of problems for a lot of people who get it. To discourage the
1325: distribution of PGP without the required documentation, PGP has been
1326: changed to require the PGP User's Guide to be found somewhere on your
1327: computer (like in your PGP directory) before PGP will let you generate
1328: a key pair. However, some users like to use PGP on tiny palmtop
1329: computers with limited storage capacity, so they like to run PGP
1330: without the documentation present on their systems. To satisfy these
1331: users, PGP can be made to relax its requirement that the manual be
1332: present, by enabling the NOMANUAL flag on the command line during key
1333: generation, like so:
1334:
1335: pgp -kg +nomanual
1336:
1337: The NOMANUAL flag can only be set on the command line, not in the
1.1.1.5 root 1338: config file. Since you must read this manual to learn how to enable
1.1.1.6 ! root 1339: this simple override feature, I hope this will still be effective in
1.1.1.4 root 1340: discouraging the distribution of PGP without the manual.
1341:
1.1.1.6 ! root 1342: Some people may object to PGP insisting on finding the manual
! 1343: somewhere in the neighborhood to generate a key. They bristle
! 1344: against this seemingly authoritarian attitude. Some people have even
! 1345: modified PGP to defeat this feature, and redistributed their hotwired
! 1346: version to others. That creates problems for me. Before I added
! 1347: this feature, there were maimed versions of the PGP distribution
! 1348: package floating around that lacked the manual. One of them was
! 1349: uploaded to Compuserve, and was distributed to countless users who
! 1350: called me on the phone to ask me why such a complicated program had
! 1351: no manual. It spread out to BBS systems around the country. And a
! 1352: freeware distributor got hold of the package from Compuserve and
! 1353: enshrined it on CD-ROM, distributing thousands of copies without the
! 1354: manual. What a mess.
1.1.1.4 root 1355:
1356:
1357: A Peek Under the Hood
1358: =====================
1359:
1360: Let's take a look at a few internal features of PGP.
1361:
1362:
1363: Random Numbers
1364: --------------
1365:
1366: PGP uses a cryptographically strong pseudorandom number generator for
1367: creating temporary conventional session keys. The seed file for this
1368: is called "randseed.bin". It too can be kept in whatever directory
1369: is indicated by the PGPPATH environmental variable. If this random
1370: seed file does not exist, it is automatically created and seeded with
1371: truly random numbers derived from timing your keystroke latencies.
1372:
1373: This generator reseeds the disk file each time it is used by mixing
1374: in new key material partially derived with the time of day and other
1375: truly random sources. It uses the conventional encryption algorithm
1376: as an engine for the random number generator. The seed file contains
1377: both random seed material and random key material to key the
1378: conventional encryption engine for the random generator.
1379:
1380: This random seed file should be at least slightly protected from
1381: disclosure, to reduce the risk of an attacker deriving your next or
1382: previous session keys. The attacker would have a very hard time
1383: getting anything useful from capturing this random seed file, because
1384: the file is cryptographically laundered before and after each use.
1385: Nonetheless, it seems prudent to at least try to keep it from falling
1386: into the wrong hands.
1387:
1388: If you feel uneasy about trusting any algorithmically derived random
1389: number source however strong, keep in mind that you already trust the
1390: strength of the same conventional cipher to protect your messages.
1391: If it's strong enough for that, then it should be strong enough to
1392: use as a source of random numbers for temporary session keys. Note
1393: that PGP still uses truly random numbers from physical sources
1394: (mainly keyboard timings) to generate long-term public/secret key
1395: pairs.
1396:
1397:
1398:
1399: PGP's Conventional Encryption Algorithm
1400: ---------------------------------------
1401:
1402: As described earlier, PGP "bootstraps" into a conventional single-key
1403: encryption algorithm by using a public key algorithm to encipher the
1404: conventional session key and then switching to fast conventional
1405: cryptography. So let's talk about this conventional encryption
1406: algorithm. It isn't the DES.
1407:
1408: The Federal Data Encryption Standard (DES) used to be a good
1409: algorithm for most commercial applications. But the Government never
1410: did trust the DES to protect its own classified data, because the DES
1411: key length is only 56 bits, short enough for a brute force attack.
1412: Also, the full 16-round DES has been attacked with some success by
1413: Biham and Shamir using differential cryptanalysis, and by Matsui
1414: using linear cryptanalysis.
1415:
1416: The most devastating practical attack on the DES was described at the
1417: Crypto '93 conference, where Michael Wiener of Bell Northern Research
1418: presented a paper on how to crack the DES with a special machine. He
1419: has fully designed and tested a chip that guesses 50 million DES keys
1420: per second until it finds the right one. Although he has refrained
1421: from building the real chips so far, he can get these chips
1422: manufactured for $10.50 each, and can build 57000 of them into a
1423: special machine for $1 million that can try every DES key in 7 hours,
1424: averaging a solution in 3.5 hours. $1 million can be hidden in the
1425: budget of many companies. For $10 million, it takes 21 minutes to
1426: crack, and for $100 million, just two minutes. With any major
1427: government's budget for examining DES traffic, it can be cracked in
1428: seconds. This means that straight 56-bit DES is now effectively dead
1429: for purposes of serious data security applications.
1430:
1431: A possible successor to DES may be a variation known as "triple DES",
1432: which uses two DES keys to encrypt three times, achieving an
1433: effective key space of 112 bits. But this approach is three times
1434: slower than normal DES. A future version of PGP may support triple
1435: DES as an option.
1436:
1437: PGP does not use the DES as its conventional single-key algorithm to
1438: encrypt messages. Instead, PGP uses a different conventional
1439: single-key block encryption algorithm, called IDEA(tm).
1440:
1441: For the cryptographically curious, the IDEA cipher has a 64-bit block
1442: size for the plaintext and the ciphertext. It uses a key size of 128
1443: bits. It is based on the design concept of "mixing operations from
1444: different algebraic groups". It runs much faster in software than
1445: the DES. Like the DES, it can be used in cipher feedback (CFB) and
1446: cipher block chaining (CBC) modes. PGP uses it in 64-bit CFB mode.
1447:
1448: The IPES/IDEA block cipher was developed at ETH in Zurich by James L.
1449: Massey and Xuejia Lai, and published in 1990. This is not a
1450: "home-grown" algorithm. Its designers have a distinguished
1451: reputation in the cryptologic community. Early published papers on
1452: the algorithm called it IPES (Improved Proposed Encryption Standard),
1453: but they later changed the name to IDEA (International Data
1454: Encryption Algorithm). So far, IDEA has resisted attack much better
1455: than other ciphers such as FEAL, REDOC-II, LOKI, Snefru and Khafre.
1456: And recent evidence suggests that IDEA is more resistant than the DES
1457: to Biham & Shamir's highly successful differential cryptanalysis
1458: attack. Biham and Shamir have been examining the IDEA cipher for
1459: weaknesses, without success. Academic cryptanalyst groups in
1460: Belgium, England, and Germany are also attempting to attack it, as
1461: well as the military services from several European countries. As
1462: this new cipher continues to attract attack efforts from the most
1463: formidable quarters of the cryptanalytic world, confidence in IDEA is
1464: growing with the passage of time.
1465:
1466: Every once in a while, I get a letter from someone who has just
1467: learned the awful truth that PGP does not use pure RSA to encrypt
1468: bulk data. They are concerned that the whole package is weakened if
1469: we use a hybrid public-key and conventional scheme just to speed
1470: things up. After all, a chain is only as strong as its weakest
1471: link. They demand an explanation for this apparent "compromise" in
1472: the strength of PGP. This may be because they have been caught up in
1473: the public's reverence and awe for the strength and mystique of RSA,
1474: mistakenly believing that RSA is intrinsically stronger than any
1475: conventional cipher. Well, it's not.
1476:
1477: People who work in factoring research say that the workload to
1.1.1.5 root 1478: exhaust all the possible 128-bit keys in the IDEA cipher would
1479: roughly equal the factoring workload to crack a 3100-bit RSA key,
1480: which is quite a bit bigger than the 1024-bit RSA key size that most
1481: people use for high security applications. Given this range of key
1482: sizes, and assuming there are no hidden weaknesses in the
1483: conventional cipher, the weak link in this hybrid approach is in the
1484: public key algorithm, not the conventional cipher.
1.1.1.4 root 1485:
1486: It is not ergonomically practical to use pure RSA with large keys to
1487: encrypt and decrypt long messages. A 1024-bit RSA key would decrypt
1488: messages about 4000 times slower than the IDEA cipher. Absolutely no
1489: one does it that way in the real world. Many people less experienced
1490: in cryptography do not realize that the attraction of public key
1491: cryptography is not because it is intrinsically stronger than a
1492: conventional cipher-- its appeal is because it helps you manage keys
1493: more conveniently.
1494:
1495: Not only is RSA too slow to use on bulk data, but it even has certain
1496: weaknesses that can be exploited in some special cases of particular
1.1.1.5 root 1497: kinds of messages that are fed to the RSA cipher, even for large
1498: keys. These special cases can be avoided by using the hybrid
1499: approach of using RSA to encrypt random session keys for a
1500: conventional cipher, like PGP does. So the bottom line is this:
1501: Using pure RSA on bulk data is the wrong approach, period. It's too
1502: slow, it's not stronger, and may even be weaker. If you find a
1503: software application that uses pure RSA on bulk data, it probably
1504: means the implementor does not understand these issues, which could
1505: imply he doesn't understand other important concepts of cryptography.
1.1.1.4 root 1506:
1507:
1508:
1509: Data Compression
1510: ----------------
1511:
1512: PGP normally compresses the plaintext before encrypting it. It's too
1513: late to compress it after it has been encrypted; encrypted data is
1514: incompressible. Data compression saves modem transmission time and
1515: disk space and more importantly strengthens cryptographic security.
1516: Most cryptanalysis techniques exploit redundancies found in the
1517: plaintext to crack the cipher. Data compression reduces this
1518: redundancy in the plaintext, thereby greatly enhancing resistance to
1519: cryptanalysis. It takes extra time to compress the plaintext, but
1520: from a security point of view it seems worth it, at least in my
1521: cautious opinion.
1522:
1523: Files that are too short to compress or just don't compress well are
1524: not compressed by PGP.
1525:
1526: If you prefer, you can use PKZIP to compress the plaintext before
1527: encrypting it. PKZIP is a widely-available and effective MSDOS
1528: shareware compression utility from PKWare, Inc. Or you can use ZIP,
1529: a PKZIP-compatible freeware compression utility on Unix and other
1530: systems, available from Jean-Loup Gailly. There is some advantage in
1531: using PKZIP or ZIP in certain cases, because unlike PGP's built-in
1532: compression algorithm, PKZIP and ZIP have the nice feature of
1533: compressing multiple files into a single compressed file, which is
1534: reconstituted again into separate files when decompressed. PGP will
1535: not try to compress a plaintext file that has already been
1536: compressed. After decrypting, the recipient can decompress the
1537: plaintext with PKUNZIP. If the decrypted plaintext is a PKZIP
1538: compressed file, PGP automatically recognizes this and advises the
1539: recipient that the decrypted plaintext appears to be a PKZIP file.
1540:
1541: For the technically curious readers, the current version of PGP uses
1542: the freeware ZIP compression routines written by Jean-loup Gailly,
1543: Mark Adler, and Richard B. Wales. This ZIP software uses
1544: functionally-equivalent compression algorithms as those used by
1545: PKWare's new PKZIP 2.0. This ZIP compression software was selected
1546: for PGP mainly because of its free portable C source code
1547: availability, and because it has a really good compression ratio, and
1548: because it's fast.
1549:
1550: Peter Gutmann has also written a nice compression utility called
1551: HPACK, available for free from many Internet FTP sites. It encrypts
1552: the compressed archives, using PGP data formats and key rings. He
1553: wanted me to mention that here.
1554:
1555:
1556:
1557: Message Digests and Digital Signatures
1558: --------------------------------------
1559:
1560: To create a digital signature, PGP encrypts with your secret key.
1561: But PGP doesn't actually encrypt your entire message with your secret
1562: key-- that would take too long. Instead, PGP encrypts a "message
1563: digest".
1564:
1565: The message digest is a compact (128 bit) "distillate" of your
1566: message, similar in concept to a checksum. You can also think of it
1567: as a "fingerprint" of the message. The message digest "represents"
1568: your message, such that if the message were altered in any way, a
1569: different message digest would be computed from it. This makes it
1570: possible to detect any changes made to the message by a forger. A
1571: message digest is computed using a cryptographically strong one-way
1572: hash function of the message. It would be computationally infeasible
1573: for an attacker to devise a substitute message that would produce an
1574: identical message digest. In that respect, a message digest is much
1575: better than a checksum, because it is easy to devise a different
1576: message that would produce the same checksum. But like a checksum,
1577: you can't derive the original message from its message digest.
1578:
1579: A message digest alone is not enough to authenticate a message. The
1580: message digest algorithm is publicly known, and does not require
1581: knowledge of any secret keys to calculate. If all we did was attach
1582: a message digest to a message, then a forger could alter a message
1583: and simply attach a new message digest calculated from the new
1584: altered message. To provide real authentication, the sender has to
1585: encrypt (sign) the message digest with his secret key.
1586:
1587: A message digest is calculated from the message by the sender. The
1588: sender's secret key is used to encrypt the message digest and an
1589: electronic timestamp, forming a digital signature, or signature
1590: certificate. The sender sends the digital signature along with the
1591: message. The receiver receives the message and the digital
1592: signature, and recovers the original message digest from the digital
1593: signature by decrypting it with the sender's public key. The
1594: receiver computes a new message digest from the message, and checks
1595: to see if it matches the one recovered from the digital signature. If
1596: it matches, then that proves the message was not altered, and it came
1597: from the sender who owns the public key used to check the signature.
1598:
1599: A potential forger would have to either produce an altered message
1600: that produces an identical message digest (which is infeasible), or
1601: he would have to create a new digital signature from a different
1602: message digest (also infeasible, without knowing the true sender's
1603: secret key).
1604:
1605: Digital signatures prove who sent the message, and that the message
1606: was not altered either by error or design. It also provides
1607: non-repudiation, which means the sender cannot easily disavow his
1608: signature on the message.
1609:
1610: Using message digests to form digital signatures has other advantages
1611: besides being faster than directly signing the entire actual message
1612: with the secret key. Using message digests allows signatures to be
1613: of a standard small fixed size, regardless of the size of the actual
1614: message. It also allows the software to check the message integrity
1615: automatically, in a manner similar to using checksums. And it allows
1616: signatures to be stored separately from messages, perhaps even in a
1617: public archive, without revealing sensitive information about the
1618: actual messages, because no one can derive any message content from a
1619: message digest.
1620:
1621: The message digest algorithm used here is the MD5 Message Digest
1622: Algorithm, placed in the public domain by RSA Data Security, Inc.
1623: MD5's designer, Ronald Rivest, writes this about MD5:
1624:
1625: "It is conjectured that the difficulty of coming up with two messages
1626: having the same message digest is on the order of 2^64 operations,
1627: and that the difficulty of coming up with any message having a given
1628: message digest is on the order of 2^128 operations. The MD5
1629: algorithm has been carefully scrutinized for weaknesses. It is,
1630: however, a relatively new algorithm and further security analysis is
1631: of course justified, as is the case with any new proposal of this
1632: sort. The level of security provided by MD5 should be sufficient for
1633: implementing very high security hybrid digital signature schemes
1634: based on MD5 and the RSA public-key cryptosystem."
1635:
1636:
1637:
1.1.1.5 root 1638: Compatibility with Previous and Future Versions of PGP
1639: ======================================================
1.1.1.4 root 1640:
1.1.1.5 root 1641: PGP version 2.6 can read anything produced by versions 2.3 through
1642: 2.7. However, because of a negotiated agreement between MIT and RSA
1.1.1.6 ! root 1643: Data Security, PGP 2.6 was programmed to change its behavior slightly
! 1644: on 1 September 1994, triggered by a built-in software timer. On that
! 1645: date, version 2.6 started producing a new and slightly different data
! 1646: format for messages, signatures and keys. PGP 2.6 will still be able
! 1647: to read and process messages, signatures, and keys produced under the
! 1648: old format, but it will generate the new format. This change is
! 1649: intended to discourage people from continuing to use the older (2.3a
! 1650: and earlier) versions of PGP, which Public Key Partners contends
! 1651: infringes its RSA patent (see the section on Legal Issues). ViaCrypt
! 1652: PGP (see the section Where to Get a Commercial Version of PGP),
! 1653: versions 2.4 and 2.7, avoids questions of infringement through
1.1.1.5 root 1654: Viacrypt's license arrangement with Public Key Partners. PGP 2.5 and
1655: 2.6 avoid questions of infringement by using the RSAREF(TM)
1656: Cryptographic Toolkit, under license from RSA Data Security, Inc.
1.1.1.4 root 1657:
1658: Outside the United States, the RSA patent is not in force, so PGP
1.1.1.5 root 1659: users there are free to use implementations of PGP that do not rely
1660: on RSAREF and its restrictions. See the notes on foreign versions in
1661: the Legal Issues section later in this manual. It seems likely that
1.1.1.6 ! root 1662: any versions of PGP prepared outside the US will accept the new
1.1.1.5 root 1663: format, whose detailed description is available from MIT. If
1664: everyone upgrades before September 1994, or soon thereafter, there
1665: will be little interoperability problems.
1.1.1.4 root 1666:
1667: This format change beginning with 2.6 is similar to the process that
1668: naturally happens when new features are added, causing older versions
1669: of PGP to be unable to read stuff from the newer PGP, while the newer
1670: version can still read the old stuff. The only difference is that
1671: this is a "legal upgrade", instead of a technical one. It's a
1672: worthwhile change, if it can achieve peace in our time.
1673:
1674: According to ViaCrypt, which sells a commercial version of PGP,
1675: ViaCrypt PGP will evolve to maintain interoperability with new
1676: freeware versions of PGP.
1677:
1678: There is a another change that effects interoperability with earlier
1679: versions of PGP. Unfortunately, due to data format limitations
1680: imposed by RSAREF, PGP 2.5 and 2.6 cannot interpret any messages or
1681: signatures made with PGP version 2.2 or earlier. Since we had no
1.1.1.5 root 1682: choice but to use the new data formats, because of the need to switch
1683: to RSAREF, we can't do anything about this problem.
1.1.1.4 root 1684:
1685: Beginning with version 2.4 (which was ViaCrypt's first version)
1686: through at least 2.6, PGP does not allow you to generate RSA keys
1687: bigger than 1024 bits. The upper limit was always intended to be
1.1.1.5 root 1688: 1024 bits -- there had to be some kind of upper limit, for
1689: performance and interoperability reasons. But because of a bug in
1690: earlier versions of PGP, it was possible to generate keys larger than
1691: 1024 bits. These larger keys caused interoperability problems
1692: between different older versions of PGP that used different
1693: arithmetic algorithms with different native word sizes. On some
1694: platforms, PGP choked on the larger keys. In addition to these older
1695: key size problems, the 1024-bit limit is now enforced by RSAREF. A
1696: 1024-bit key is very likely to be well out of reach of attacks by
1697: major governments. In a future version, PGP will support bigger keys.
1.1.1.4 root 1698:
1699: In general, there is compatibility from version 2.0 upwards through
1700: 2.4. Because new features are added, older versions may not always be
1701: able to handle some files created with newer versions. Because of
1702: massive changes to all the algorithms and data structures, PGP version
1703: 2.0 (and later) is not even slightly compatible with PGP version 1.0,
1704: which no one uses anymore anyway.
1705:
1.1.1.5 root 1706: Future versions of PGP may have to change the data formats for
1707: messages, signatures, keys and key rings, in order to provide
1708: important new features. We will endeavor to make future versions
1709: handle keys, signatures, and messages from this version, but this is
1710: not guaranteed. Future releases may provide conversion utilities to
1711: convert old keys, but you may have to dispose of old messages created
1712: with the old PGP. Also, this current version may not be able to read
1713: stuff produced from all future versions.
1714:
1.1.1.4 root 1715:
1716: Vulnerabilities
1717: ===============
1718:
1719: No data security system is impenetrable. PGP can be circumvented in
1720: a variety of ways. In any data security system, you have to ask
1721: yourself if the information you are trying to protect is more
1722: valuable to your attacker than the cost of the attack. This should
1723: lead you to protecting yourself from the cheapest attacks, while not
1724: worrying about the more expensive attacks.
1725:
1726: Some of the discussion that follows may seem unduly paranoid, but
1727: such an attitude is appropriate for a reasonable discussion of
1728: vulnerability issues.
1729:
1730:
1731: Compromised Pass Phrase and Secret Key
1732: --------------------------------------
1733:
1734: Probably the simplest attack is if you leave your pass phrase for
1735: your secret key written down somewhere. If someone gets it and also
1736: gets your secret key file, they can read your messages and make
1737: signatures in your name.
1738:
1739: Don't use obvious passwords that can be easily guessed, such as the
1740: names of your kids or spouse. If you make your pass phrase a single
1741: word, it can be easily guessed by having a computer try all the words
1742: in the dictionary until it finds your password. That's why a pass
1743: phrase is so much better than a password. A more sophisticated
1744: attacker may have his computer scan a book of famous quotations to
1745: find your pass phrase. An easy to remember but hard to guess pass
1746: phrase can be easily constructed by some creatively nonsensical
1747: sayings or very obscure literary quotes.
1748:
1749: For further details, see the section "How to Protect Secret Keys from
1750: Disclosure" in the Essential Topics volume of the PGP User's Guide.
1751:
1752:
1753: Public Key Tampering
1754: --------------------
1755:
1756: A major vulnerability exists if public keys are tampered with. This
1757: may be the most crucially important vulnerability of a public key
1758: cryptosystem, in part because most novices don't immediately
1759: recognize it. The importance of this vulnerability, and appropriate
1760: hygienic countermeasures, are detailed in the section "How to Protect
1761: Public Keys from Tampering" in the Essential Topics volume.
1762:
1763: To summarize: When you use someone's public key, make certain it has
1764: not been tampered with. A new public key from someone else should be
1765: trusted only if you got it directly from its owner, or if it has been
1766: signed by someone you trust. Make sure no one else can tamper with
1767: your own public key ring. Maintain physical control of both your
1768: public key ring and your secret key ring, preferably on your own
1769: personal computer rather than on a remote timesharing system. Keep a
1770: backup copy of both key rings.
1771:
1772:
1773: "Not Quite Deleted" Files
1774: -------------------------
1775:
1776: Another potential security problem is caused by how most operating
1777: systems delete files. When you encrypt a file and then delete the
1778: original plaintext file, the operating system doesn't actually
1779: physically erase the data. It merely marks those disk blocks as
1780: deleted, allowing the space to be reused later. It's sort of like
1781: discarding sensitive paper documents in the paper recycling bin
1782: instead of the paper shredder. The disk blocks still contain the
1783: original sensitive data you wanted to erase, and will probably
1784: eventually be overwritten by new data at some point in the future.
1785: If an attacker reads these deleted disk blocks soon after they have
1786: been deallocated, he could recover your plaintext.
1787:
1788: In fact this could even happen accidentally, if for some reason
1789: something went wrong with the disk and some files were accidentally
1790: deleted or corrupted. A disk recovery program may be run to recover
1791: the damaged files, but this often means some previously deleted files
1792: are resurrected along with everything else. Your confidential files
1793: that you thought were gone forever could then reappear and be
1794: inspected by whomever is attempting to recover your damaged disk.
1795: Even while you are creating the original message with a word
1796: processor or text editor, the editor may be creating multiple
1797: temporary copies of your text on the disk, just because of its
1798: internal workings. These temporary copies of your text are deleted
1799: by the word processor when it's done, but these sensitive fragments
1800: are still on your disk somewhere.
1801:
1802: Let me tell you a true horror story. I had a friend, married with
1803: young children, who once had a brief and not very serious affair.
1804: She wrote a letter to her lover on her word processor, and deleted
1805: the letter after she sent it. Later, after the affair was over, the
1806: floppy disk got damaged somehow and she had to recover it because it
1807: contained other important documents. She asked her husband to
1808: salvage the disk, which seemed perfectly safe because she knew she
1809: had deleted the incriminating letter. Her husband ran a commercial
1810: disk recovery software package to salvage the files. It recovered
1811: the files alright, including the deleted letter. He read it, which
1812: set off a tragic chain of events.
1813:
1814: The only way to prevent the plaintext from reappearing is to somehow
1815: cause the deleted plaintext files to be overwritten. Unless you know
1816: for sure that all the deleted disk blocks will soon be reused, you
1817: must take positive steps to overwrite the plaintext file, and also
1818: any fragments of it on the disk left by your word processor. You can
1819: overwrite the original plaintext file after encryption by using the
1820: PGP -w (wipe) option. You can take care of any fragments of the
1821: plaintext left on the disk by using any of the disk utilities
1822: available that can overwrite all of the unused blocks on a disk. For
1823: example, the Norton Utilities for MSDOS can do this.
1824:
1825: Even if you overwrite the plaintext data on the disk, it may still be
1826: possible for a resourceful and determined attacker to recover the
1827: data. Faint magnetic traces of the original data remain on the disk
1828: after it has been overwritten. Special sophisticated disk recovery
1829: hardware can sometimes be used to recover the data.
1830:
1831:
1832: Viruses and Trojan Horses
1833: -------------------------
1834:
1835: Another attack could involve a specially-tailored hostile computer
1836: virus or worm that might infect PGP or your operating system. This
1837: hypothetical virus could be designed to capture your pass phrase or
1838: secret key or deciphered messages, and covertly write the captured
1839: information to a file or send it through a network to the virus's
1840: owner. Or it might alter PGP's behavior so that signatures are not
1841: properly checked. This attack is cheaper than cryptanalytic attacks.
1842:
1843: Defending against this falls under the category of defending against
1844: viral infection generally. There are some moderately capable
1845: anti-viral products commercially available, and there are hygienic
1846: procedures to follow that can greatly reduce the chances of viral
1847: infection. A complete treatment of anti-viral and anti-worm
1848: countermeasures is beyond the scope of this document. PGP has no
1849: defenses against viruses, and assumes your own personal computer is a
1850: trustworthy execution environment. If such a virus or worm actually
1851: appeared, hopefully word would soon get around warning everyone.
1852:
1853: Another similar attack involves someone creating a clever imitation
1854: of PGP that behaves like PGP in most respects, but doesn't work the
1855: way it's supposed to. For example, it might be deliberately crippled
1856: to not check signatures properly, allowing bogus key certificates to
1857: be accepted. This "Trojan horse" version of PGP is not hard for an
1858: attacker to create, because PGP source code is widely available, so
1859: anyone could modify the source code and produce a lobotomized zombie
1860: imitation PGP that looks real but does the bidding of its diabolical
1861: master. This Trojan horse version of PGP could then be widely
1862: circulated, claiming to be from me. How insidious.
1863:
1864: You should make an effort to get your copy of PGP from a reliable
1865: source, whatever that means. Or perhaps from more than one
1866: independent source, and compare them with a file comparison utility.
1867:
1868: There are other ways to check PGP for tampering, using digital
1869: signatures. If someone you trust signs the executable version of
1870: PGP, vouching for the fact that it has not been infected or tampered
1871: with, you can be reasonably sure that you have a good copy. You
1872: could use an earlier trusted version of PGP to check the signature on
1873: a later suspect version of PGP. But this will not help at all if
1874: your operating system is infected, nor will it detect if your
1875: original copy of PGP.EXE has been maliciously altered in such a way
1876: as to compromise its own ability to check signatures. This test also
1877: assumes that you have a good trusted copy of the public key that you
1878: use to check the signature on the PGP executable.
1879:
1.1.1.5 root 1880: I recommend you not trust your copy of PGP unless it was originally
1881: distributed by MIT or ViaCrypt, or unless it comes with a digitally
1882: signed endorsement from me. Every new version comes with one or more
1883: digital signatures in the distribution package, signed by the
1884: originator of that release package. This is usually someone
1885: representing MIT or ViaCrypt, or whoever released that version.
1886: Check the signatures on the version that you get. I have actually
1887: seen several bogus versions of PGP distribution packages, even from
1888: apparantly reliable freeware distribution channels such as CD-ROM
1889: distributors and Compuserve. Always check the signature when you get
1890: a new version.
1891:
1.1.1.4 root 1892:
1893: Physical Security Breach
1894: ------------------------
1895:
1896: A physical security breach may allow someone to physically acquire
1897: your plaintext files or printed messages. A determined opponent
1898: might accomplish this through burglary, trash-picking, unreasonable
1899: search and seizure, or bribery, blackmail or infiltration of your
1900: staff. Some of these attacks may be especially feasible against
1901: grassroots political organizations that depend on a largely volunteer
1902: staff. It has been widely reported in the press that the FBI's
1903: COINTELPRO program used burglary, infiltration, and illegal bugging
1904: against antiwar and civil rights groups. And look what happened at
1905: the Watergate Hotel.
1906:
1907: Don't be lulled into a false sense of security just because you have
1908: a cryptographic tool. Cryptographic techniques protect data only
1909: while it's encrypted-- direct physical security violations can still
1910: compromise plaintext data or written or spoken information.
1911:
1912: This kind of attack is cheaper than cryptanalytic attacks on PGP.
1913:
1914:
1915: Tempest Attacks
1916: ---------------
1917:
1918: Another kind of attack that has been used by well-equipped opponents
1919: involves the remote detection of the electromagnetic signals from
1920: your computer. This expensive and somewhat labor-intensive attack is
1921: probably still cheaper than direct cryptanalytic attacks. An
1922: appropriately instrumented van can park near your office and remotely
1923: pick up all of your keystrokes and messages displayed on your
1924: computer video screen. This would compromise all of your passwords,
1925: messages, etc. This attack can be thwarted by properly shielding all
1926: of your computer equipment and network cabling so that it does not
1927: emit these signals. This shielding technology is known as "Tempest",
1928: and is used by some Government agencies and defense contractors.
1929: There are hardware vendors who supply Tempest shielding commercially,
1930: although it may be subject to some kind of Government licensing. Now
1931: why do you suppose the Government would restrict access to Tempest
1932: shielding?
1933:
1934:
1935: Exposure on Multi-user Systems
1936: ------------------------------
1937:
1938: PGP was originally designed for a single-user MSDOS machine under
1939: your direct physical control. I run PGP at home on my own PC, and
1940: unless someone breaks into my house or monitors my electromagnetic
1941: emissions, they probably can't see my plaintext files or secret keys.
1942:
1943: But now PGP also runs on multi-user systems such as Unix and VAX/VMS.
1944: On multi-user systems, there are much greater risks of your plaintext
1945: or keys or passwords being exposed. The Unix system administrator or
1946: a clever intruder can read your plaintext files, or perhaps even use
1947: special software to covertly monitor your keystrokes or read what's
1948: on your screen. On a Unix system, any other user can read your
1949: environment information remotely by simply using the Unix "ps"
1950: command. Similar problems exist for MSDOS machines connected on a
1951: local area network. The actual security risk is dependent on your
1952: particular situation. Some multi-user systems may be safe because
1953: all the users are trusted, or because they have system security
1954: measures that are safe enough to withstand the attacks available to
1955: the intruders, or because there just aren't any sufficiently
1956: interested intruders. Some Unix systems are safe because they are
1957: only used by one user-- there are even some notebook computers
1958: running Unix. It would be unreasonable to simply exclude PGP from
1959: running on all Unix systems.
1960:
1961: PGP is not designed to protect your data while it is in plaintext
1962: form on a compromised system. Nor can it prevent an intruder from
1963: using sophisticated measures to read your secret key while it is
1964: being used. You will just have to recognize these risks on
1965: multi-user systems, and adjust your expectations and behavior
1966: accordingly. Perhaps your situation is such that you should consider
1967: running PGP only on an isolated single-user system under your direct
1968: physical control. That's what I do, and that's what I recommend.
1969:
1970:
1971: Traffic Analysis
1972: ----------------
1973:
1974: Even if the attacker cannot read the contents of your encrypted
1975: messages, he may be able to infer at least some useful information by
1976: observing where the messages come from and where they are going, the
1977: size of the messages, and the time of day the messages are sent.
1978: This is analogous to the attacker looking at your long distance phone
1979: bill to see who you called and when and for how long, even though the
1980: actual content of your calls is unknown to the attacker. This is
1981: called traffic analysis. PGP alone does not protect against traffic
1982: analysis. Solving this problem would require specialized
1983: communication protocols designed to reduce exposure to traffic
1984: analysis in your communication environment, possibly with some
1985: cryptographic assistance.
1986:
1987:
1.1.1.5 root 1988: Protecting Against Bogus Timestamps
1989: -----------------------------------
1990:
1991: A somewhat obscure vulnerability of PGP involves dishonest users
1992: creating bogus timestamps on their own public key certificates and
1993: signatures. You can skip over this section if you are a casual user
1994: and aren't deeply into obscure public key protocols.
1995:
1996: There's nothing to stop a dishonest user from altering the date and
1997: time setting of his own system's clock, and generating his own public
1998: key certificates and signatures that appear to have been created at a
1999: different time. He can make it appear that he signed something
2000: earlier or later than he actually did, or that his public/secret key
2001: pair was created earlier or later. This may have some legal or
2002: financial benefit to him, for example by creating some kind of
2003: loophole that might allow him to repudiate a signature.
2004:
2005: I think this problem of falsified timestamps in digital signatures is
2006: no worse than it is already in handwritten signatures. Anyone may
2007: write a date next to their handwritten signature on a contract with
2008: any date they choose, yet no one seems to be alarmed over this state
2009: of affairs. In some cases, an "incorrect" date on a handwritten
2010: signature might not be associated with actual fraud. The timestamp
2011: might be when the signator asserts that he signed a document, or
2012: maybe when he wants the signature to go into effect.
2013:
2014: In situations where it is critical that a signature be trusted to
2015: have the actual correct date, people can simply use notaries to
2016: witness and date a handwritten signature. The analog to this in
2017: digital signatures is to get a trusted third party to sign a
2018: signature certificate, applying a trusted timestamp. No exotic or
2019: overly formal protocols are needed for this. Witnessed signatures
2020: have long been recognized as a legitimate way of determining when a
2021: document was signed.
2022:
2023: A trustworthy Certifying Authority or notary could create notarized
2024: signatures with a trustworthy timestamp. This would not necessarily
2025: require a centralized authority. Perhaps any trusted introducer or
2026: disinterested party could serve this function, the same way real
2027: notary publics do now. When a notary signs other people's
2028: signatures, it creates a signature certificate of a signature
2029: certificate. This would serve as a witness to the signature the same
2030: way real notaries now witness handwritten signatures. The notary
2031: could enter the detached signature certificate (without the actual
2032: whole document that was signed) into a special log controlled by the
2033: notary. Anyone can read this log. The notary's signature would have
2034: a trusted timestamp, which might have greater credibility or more
2035: legal significance than the timestamp in the original signature.
2036:
2037: There is a good treatment of this topic in Denning's 1983 article in
2038: IEEE Computer (see references). Future enhancements to PGP might
2039: have features to easily manage notarized signatures of signatures,
2040: with trusted timestamps.
2041:
2042:
1.1.1.4 root 2043: Cryptanalysis
2044: -------------
2045:
2046: An expensive and formidable cryptanalytic attack could possibly be
2047: mounted by someone with vast supercomputer resources, such as a
2048: Government intelligence agency. They might crack your RSA key by
2049: using some new secret factoring breakthrough. Perhaps so, but it is
2050: noteworthy that the US Government trusts the RSA algorithm enough in
2051: some cases to use it to protect its own nuclear weapons, according to
2052: Ron Rivest. And civilian academia has been intensively attacking it
2053: without success since 1978.
2054:
2055: Perhaps the Government has some classified methods of cracking the
2056: IDEA(tm) conventional encryption algorithm used in PGP. This is
2057: every cryptographer's worst nightmare. There can be no absolute
2058: security guarantees in practical cryptographic implementations.
2059:
2060: Still, some optimism seems justified. The IDEA algorithm's designers
2061: are among the best cryptographers in Europe. It has had extensive
2062: security analysis and peer review from some of the best cryptanalysts
2063: in the unclassified world. It appears to have some design advantages
1.1.1.5 root 2064: over the DES in withstanding differential and linear cryptanalysis,
2065: which have both been used to crack the DES.
1.1.1.4 root 2066:
2067: Besides, even if this algorithm has some subtle unknown weaknesses,
2068: PGP compresses the plaintext before encryption, which should greatly
2069: reduce those weaknesses. The computational workload to crack it is
2070: likely to be much more expensive than the value of the message.
2071:
2072: If your situation justifies worrying about very formidable attacks of
2073: this caliber, then perhaps you should contact a data security
2074: consultant for some customized data security approaches tailored to
2075: your special needs. Boulder Software Engineering, whose address and
2076: phone are given at the end of this document, can provide such
2077: services.
2078:
2079:
2080: In summary, without good cryptographic protection of your data
2081: communications, it may have been practically effortless and perhaps
2082: even routine for an opponent to intercept your messages, especially
2083: those sent through a modem or E-mail system. If you use PGP and
2084: follow reasonable precautions, the attacker will have to expend far
2085: more effort and expense to violate your privacy.
2086:
2087: If you protect yourself against the simplest attacks, and you feel
2088: confident that your privacy is not going to be violated by a
2089: determined and highly resourceful attacker, then you'll probably be
2090: safe using PGP. PGP gives you Pretty Good Privacy.
2091:
2092:
2093: Legal Issues
2094: ============
2095:
2096:
2097: Trademarks, Copyrights, and Warranties
2098: --------------------------------------
2099:
1.1.1.5 root 2100: "PGP", "Pretty Good Privacy", "Phil's Pretty Good Software", and the
2101: "Pretty Good" label for computer software and hardware products are
2102: all trademarks of Philip R. Zimmermann.
2103:
2104: PGP is (c) Copyright Philip R. Zimmermann, 1990-1994. All rights
2105: reserved. The PGP User's Guide is also copyright Philip Zimmermann,
2106: 1990-1994. All rights reserved. These rights include but are not
2107: limited to any foreign language translations of the manual or the
2108: software, and all derivative works of both.
1.1.1.4 root 2109:
2110: MIT may have a copyright on the particular software distribution
2111: package that they distribute from the MIT FTP site. This copyright
2112: on the "compilation" of the distribution package in no way implies
2113: that MIT has a copyright on PGP itself, or its user documentation.
2114:
2115: The author assumes no liability for damages resulting from the use of
2116: this software, even if the damage results from defects in this
2117: software, and makes no representations concerning the merchantability
2118: of this software or its suitability for any specific purpose. It is
2119: provided "as is" without express or implied warranty of any kind.
2120: Because certain actions may delete files or render them
2121: unrecoverable, the author assumes no responsibility for the loss or
2122: modification of any data.
2123:
2124:
1.1.1.5 root 2125:
1.1.1.4 root 2126: Patent Rights on the Algorithms
2127: -------------------------------
2128:
2129: The RSA public key cryptosystem was developed at MIT, which holds a
2130: patent on it (U.S. patent #4,405,829, issued 20 Sep 1983). A company
2131: in California called Public Key Partners (PKP) holds the exclusive
2132: commercial license to sell and sub-license the RSA public key
2133: cryptosystem. MIT distributes a freeware version of PGP under the
2134: terms of the RSAREF license from RSA Data Security, Inc. (RSADSI).
2135:
1.1.1.6 ! root 2136: At the time of this writing (September 1994), it appears that PKP may
! 2137: be breaking up soon, in which case the patents they hold may fall
! 2138: into other hands. The RSA patent may end up with RSADSI.
! 2139:
1.1.1.4 root 2140: Non-US users of earlier versions of PGP should note that the RSA
2141: patent does not apply outside the US, and at least at the time of
2142: this writing, the author is not aware of any RSA patent in any other
2143: country. Federal agencies may use the RSA algorithm, because the
2144: Government paid for the development of RSA with grants from the
2145: National Science Foundation and the Navy. But despite the fact of
2146: Government users having free access to the RSA algorithm, Government
2147: use of PGP has additional restrictions imposed by the agreement I
2148: have with ViaCrypt, as explained later.
2149:
2150: I wrote my PGP software from scratch, with my own independently
1.1.1.5 root 2151: developed implementation of the RSA algorithm. Before publishing PGP
2152: in 1991, I got a formal written legal opinion from a patent attorney
2153: with extensive experience in software patents. I'm convinced that
1.1.1.4 root 2154: publishing PGP the way I did does not violate patent law.
2155:
2156: Not only did PKP acquire the exclusive patent rights for the RSA
2157: cryptosystem, but they also acquired the exclusive rights to three
2158: other patents covering other public key schemes invented by others at
2159: Stanford University, also developed with federal funding. This
1.1.1.5 root 2160: one company claims to have a legal lock in the USA on nearly all
1.1.1.4 root 2161: practical public key cryptosystems. They even appear to be claiming
2162: patent rights on the very concept of public key cryptography,
2163: regardless of what clever new original algorithms are independently
2164: invented by others. I find such a comprehensive monopoly troubling,
2165: because I think public key cryptography is destined to become a
2166: crucial technology in the protection of our civil liberties and
2167: privacy in our increasingly connected society. At the very least,
2168: it places these vital tools at risk by affording to the Government
2169: a single pressure point of influence.
2170:
2171: Beginning with PGP version 2.5 (distributed by MIT, the holders of
2172: the original RSA patent), the freeware version of PGP uses the RSAREF
2173: subroutine library to perform its RSA calculations, under the RSAREF
2174: license, which allows noncommercial use in the USA. RSAREF is a
2175: subroutine package from RSA Data Security Inc, that implements the
2176: RSA algorithm. The RSAREF subroutines are used instead of PGP's
2177: original subroutines to implement the RSA functions in PGP. See the
1.1.1.5 root 2178: RSAREF license for terms and conditions of use of RSAREF
2179: applications.
1.1.1.4 root 2180:
2181: PGP 2.5 was released by MIT for a brief test period in May, 1994
1.1.1.5 root 2182: before releasing 2.6. PGP 2.5 was released under the 16 March, 1994
2183: RSAREF license, which is a perpetual license, so it may legally be
2184: used forever in the US. But it would be better for PGP's legal and
2185: political future for users in the United States to upgrade to version
2186: 2.6 or later to facilitate the demise of PGP 2.3a and earlier
2187: versions. Also, PGP 2.5 has bugs that are corrected in 2.6, and 2.5
2188: will not read the new data format after September 1, 1994. (See the
2189: section on Compatibility with Previous and Future Versions of PGP.)
1.1.1.4 root 2190:
2191: The PGP 2.0 release was a joint effort of an international team of
2192: software engineers, implementing enhancements to the original PGP
2193: with design guidance from me. It was released by Branko Lankester in
2194: The Netherlands and Peter Gutmann in New Zealand, out of reach of US
2195: patent law. Although released only in Europe and New Zealand, it
2196: spontaneously spread to the USA without help from me or the PGP
2197: development team.
2198:
2199: The IDEA(tm) conventional block cipher used by PGP is covered by a
2200: patent in Europe, held by ETH and a Swiss company called Ascom-Tech
1.1.1.5 root 2201: AG. The US Patent number is 5,214,703, and the European patent
1.1.1.4 root 2202: number is EP 0 482 154 B1. IDEA(tm) is a trademark of Ascom-Tech AG.
2203: There is no license fee required for noncommercial use of IDEA.
2204: Commercial users of IDEA may obtain licensing details from Dieter
2205: Profos, Ascom Tech AG, Teleservices Section, Postfach 151, 4502
2206: Solothurn, Switzerland, Tel +41 65 242885, Fax +41 65 235761.
2207:
2208: Ascom-Tech AG has granted permission for the freeware version PGP to
2209: use the IDEA cipher in non-commercial uses, everywhere. In the US
2210: and Canada, all commercial or Government users must obtain a licensed
2211: version from ViaCrypt, who has a license from Ascom-Tech for the IDEA
1.1.1.5 root 2212: cipher.
2213:
2214: Ascom-Tech has recently been changing its policies regarding the use
2215: of IDEA in PGP for commercial use outside the US, and that policy
2216: still seems to be in flux. They tell me that their current thinking
2217: is as follows: They will allow commercial users of PGP outside the
2218: US or Canada to use IDEA in PGP without paying royalties to
2219: Ascom-Tech, because it is not currently possible for commercial users
2220: to buy a licensed version of PGP outside the US or Canada. If the
2221: legal situation in the USA changes in the future, so that users
2222: outside the US or Canada can buy a licensed version of PGP (either
2223: from ViaCrypt, or from me, or from a foreign enterprise licensed by
2224: me), then Ascom-Tech will begin enforcing its patent licensing
2225: policies on commercial users who are in a position to buy a licensed
2226: version of PGP. To get a more up-to-date report on this, contact
2227: Ascom-Tech AG.
1.1.1.4 root 2228:
2229: The ZIP compression routines in PGP come from freeware source code,
2230: with the author's permission. I'm not aware of any patents on the
1.1.1.5 root 2231: compression algorithms used in the ZIP routines.
1.1.1.4 root 2232:
2233:
1.1.1.5 root 2234: Freeware Status and Restrictions
2235: --------------------------------
2236:
2237: PGP is not shareware, it's freeware. Published as a community
2238: service. Giving PGP away for free will encourage far more people to
2239: use it, which will have a greater social impact. Feel free to
2240: disseminate the complete unmodified PGP release package as widely as
2241: possible, but be careful not to violate U.S. export controls if you
2242: live in the USA. Give it to all your friends. If you have access to
2243: any electronic Bulletin Board Systems, please upload the complete PGP
2244: executable object release package to as many BBS's as possible.
2245:
2246: You may also disseminate the source code release package. PGP's
2247: source code is published to assist public scrutiny of PGP to show that
2248: it has no hidden weaknesses or back doors, and to help people to find
2249: bugs and report them. Recompile it and port it to new target
2250: machines. Experiment with the code and learn from it.
2251:
2252: I place no restraints on your modifying the source code for your own
2253: use. However, do not distribute a modified version of PGP under the
2254: name "PGP" without first getting permission from me. Please respect
2255: this restriction. PGP's reputation for cryptographic integrity
2256: depends on maintaining strict quality control on PGP's cryptographic
2257: algorithms and protocols. Beyond that, ad hoc "improvements" to PGP
2258: can affect interoperability, which creates user confusion and
2259: compatability problems that could damage PGP's (and my own)
2260: reputation and undermine the good will earned by the PGP trademark.
2261:
2262: This has already started to happen, which is why I'm making a point
2263: of it here. This creates technical support headaches, and I get
2264: phone calls from confused users who run into problems either because
2265: they have a mutant strain of PGP, or are trying to process a key,
2266: signature, or message that came from an incompatible mutant strain of
2267: PGP. The source code to PGP was not published to help spawn these
2268: mutant strains.
2269:
2270: If you want to distribute a modified version of PGP, or use a modified
2271: version to send messages to other people, you should name the program
2272: in such a way that no one could mistake it for PGP. The messages,
2273: signatures, and keys it produces must also be labeled in such a way
2274: that no one could mistake them for material produced by PGP. If you
2275: feel you must modify your copy of PGP, and there is any chance that
2276: the modified version could escape into the environment, please contact
2277: me first to discuss some easy methods for how to prevent people from
2278: confusing your version with the standard PGP. Perhaps we'll even
2279: decide that your changes are appropriate for incorporating into the
2280: standard PGP release.
2281:
2282: Also, you should note that official executable versions of PGP are
2283: always released signed by the PGP developers, so you can verify their
2284: authenticity. If you find a corrupted copy of PGP, or notice one
2285: being distributed, please contact the people doing the distribution
2286: and suggest that they replace this with an authentic version.
2287:
2288: Some older versions of PGP were published under the terms of the
2289: General Public License (GPL), a license designed by the Free Software
2290: Foundation to protect the status of free software. Newer freeware
2291: versions of PGP are no longer published under the GPL. The RSAREF
2292: licensing terms are more stringent than those of the GPL. But even
2293: if a version of PGP is published without RSAREF, in a situation or
2294: place where the RSA patent does not apply, I still do not want the
2295: GPL to apply to PGP, for a variety of reasons, not the least of which
2296: is because the GPL is not optimal for protecting PGP from being
2297: republished with ad-hoc "improvements".
2298:
2299: Outside the United States, the RSA patent is not in force, so PGP
2300: users there are free to use implementations of PGP that do not rely
2301: on RSAREF and its restrictions. Canadians may use PGP without using
2302: RSAREF, and there are legal ways to export PGP to Canada. In Canada,
2303: where RSAREF is not needed, it is easy to modify and recompile the
2304: current PGP source code to perform the RSA calculations without using
2305: the RSAREF library, just as it was done in PGP 2.3a. In such a case,
2306: this modified PGP may be re-released under the identical licensing
2307: terms as the current official freeware PGP release, but without the
2308: RSAREF-specific restrictions. It may not be re-released under the
2309: GPL, as certain older versions were. And this manual must accompany
2310: it. That modified version of PGP may not be used in environments
2311: where RSAREF would be needed.
2312:
2313:
2314: Restrictions on Commercial Use of PGP
2315: -------------------------------------
1.1.1.4 root 2316:
1.1.1.5 root 2317: The freeware version of PGP is for personal, non-commercial use. For
2318: commercial use in the USA or Canada, contact ViaCrypt in Phoenix,
2319: Arizona (phone 602 944-0773, or email [email protected]).
2320:
2321: I made an agreement with ViaCrypt in the summer of 1993 to license the
2322: exclusive commercial rights to PGP, so that there would be a way for
2323: corporations to use PGP without risk of a patent infringement lawsuit
2324: from PKP. For PGP to succeed in the long term as a viable industry
2325: standard, the legal stigma associated with the RSA patent rights had
2326: to be resolved. ViaCrypt had already obtained a patent license from
2327: PKP to make, use, and sell products that practice the RSA patents.
2328: ViaCrypt offered a way out of the patent quagmire for PGP to penetrate
2329: the corporate environment. They could sell a fully-licensed version
2330: of PGP, but only if I licensed it to them under these terms. So we
2331: entered into an agreement to do that, opening the door for PGP's
2332: future in the commercial sector, which was necessary for PGP's
2333: long-term political future.
1.1.1.4 root 2334:
1.1.1.5 root 2335: Therefore, regardless of the complexities and partially overlapping
1.1.1.4 root 2336: restrictions from all the other terms and conditions imposed by the
2337: various patent and copyright licenses (RSA, RSAREF, and IDEA) from
2338: various third parties, an additional overriding restriction on PGP
1.1.1.5 root 2339: usage is imposed by my own agreement with ViaCrypt: The freeware
2340: version of PGP is only for personal, non-commercial use -- all other
1.1.1.4 root 2341: users in the USA and Canada must obtain a fully licensed version of
1.1.1.5 root 2342: PGP from ViaCrypt. The restrictions imposed by my agreement with
2343: ViaCrypt do not apply outside the USA or Canada.
1.1.1.4 root 2344:
1.1.1.5 root 2345: Finally, if you want to turn PGP into a commercial product and make
2346: money selling it, then we must agree on a way for me to also make
2347: money on it. If you use PGP in such a manner that you must pay
2348: patent royalties or any other software licensing fees to the patent
2349: holders for any cryptographic algorithms used by PGP, then we must
2350: agree on a way for me to also be paid in some manner. Buying PGP
2351: from ViaCrypt is one way to meet this requirement.
2352:
2353:
2354: Other Licensing Restrictions
2355: ----------------------------
2356:
2357: Under no circumstances may PGP be distributed without the PGP
2358: documentation, including this PGP User's Guide. And, assuming this is
2359: an RSAREF version of PGP, the RSAREF license agreement must be kept
2360: with it. You must also keep the copyright, patent, and trademark
2361: notices on PGP and its documentation.
2362:
2363: The standard freeware PGP release is primarily distributed in
2364: electronic form, as a single compressed archive file, containing a
2365: collection of files in a "shrink-wrapped" package. This package
2366: should not be broken up and the components separately distributed --
2367: in the interests of quality control, we want to make it difficult for
2368: users to obtain PGP without getting the full release package.
2369:
2370:
2371: Distribution
2372: ------------
2373:
2374: In the USA, PGP is available for free from the Massachusetts Institute
2375: of Technology, under the restrictions described above.
1.1.1.4 root 2376:
2377: The primary release site for PGP is the Massachusetts Institute of
1.1.1.5 root 2378: Technology, at their FTP site "net-dist.mit.edu", in the /pub/PGP
1.1.1.4 root 2379: directory. You may obtain free copies or updates to PGP from this
2380: site, or any other Internet FTP site or BBS that PGP has spread to.
2381: Don't ask me for a copy directly from me, especially if you live
1.1.1.5 root 2382: outside the US or Canada. I recommend that you not use any modified
2383: version of PGP that comes from any other source, other than MIT,
2384: ViaCrypt, or me, unless it is accompanied by a signed endorsement
2385: from me personally. You can get the official release software from
2386: many other distribution sites "downstream" from MIT. Hopefully, all
2387: these other sites are adhering to US export controls.
2388:
1.1.1.6 ! root 2389: The PGP version 2.6.2 executable object release package for MSDOS
1.1.1.5 root 2390: contains the PGP executable software, documentation, RSAREF license,
2391: sample key rings including my own public key, and signatures for the
2392: software and this manual, all in one PKZIP compressed file called
1.1.1.6 ! root 2393: pgp262.zip. The PGP source release package for MSDOS contains all
! 2394: the C source files in one PKZIP compressed file called pgp262s.zip.
1.1.1.5 root 2395: The filename for the release package is derived from the version
2396: number of the release.
1.1.1.4 root 2397:
2398:
2399: Export Controls
2400: ---------------
2401:
2402: The U.S. Government has made it illegal in most cases to export good
2403: cryptographic technology, and that may include PGP. They regard this
2404: kind of software just like they regard munitions. This is determined
1.1.1.5 root 2405: not by legislation, but by administrative policies of the State
2406: Department, Defense Department and Commerce Department.
2407:
2408: The U.S. Government is using export restrictions as a means of
2409: suppressing both domestic and foreign availability of cryptographic
2410: technology. In particular, it is trying to suppress the emergence of
2411: an international standard for cryptographic protocols, until it can
2412: establish the Escrowed Encryption Standard (the Clipper chip) as the
2413: dominant standard.
2414:
2415: Any export restrictions on PGP are imposed by the US Government.
2416: This does not imply that I or MIT agree with these restrictions. We
2417: just comply with them. We do not impose additional licensing
2418: restrictions of our own on the use of PGP outside of the US, other
2419: than those restrictions that already apply inside the US. PGP may be
2420: subject to export controls. Anyone wishing to export it should first
2421: consult the State Department's Office of Defense Trade Controls.
2422:
2423: I will not export this software out of the US or Canada in cases when
2424: it is illegal to do so under US controls, and I urge other people not
2425: to export it on their own. If you live outside the US or Canada, I
2426: urge you not to violate US export laws by getting any version of PGP
2427: in a way that violates those laws. Since thousands of domestic users
2428: got the first version after its initial publication, it somehow
2429: leaked out of the US and spread itself widely abroad, like dandelion
2430: seeds blowing in the wind.
1.1.1.4 root 2431:
2432: Starting with PGP version 2.0 through version 2.3a, the release point
2433: of the software has been outside the US, on publicly-accessible
2434: computers in Europe. Each release was electronically sent back into
2435: the US and posted on publicly-accessible computers in the US by PGP
2436: privacy activists in foreign countries. There are some restrictions
2437: in the US regarding the import of munitions, but I'm not aware of any
2438: cases where this was ever enforced for importing cryptographic
2439: software into the US. I imagine that a legal action of that type
2440: would be quite a spectacle of controversy.
2441:
1.1.1.5 root 2442: ViaCrypt PGP is sold in the United States and Canada and is not for
2443: export. The following language was supplied by the US Government to
2444: ViaCrypt for inclusion in the ViaCrypt PGP documentation: "PGP is
2445: export restricted by the Office of Export Administration, United
2446: States Department of Commerce and the Offices of Defense Trade
2447: Controls and Munitions Control, United States Department of State.
2448: PGP cannot be exported or reexported, directly or indirectly, (a)
2449: without all export or reexport licenses and governmental approvals
2450: required by any applicable laws, or (b) in violation of any
2451: prohibition against the export or reexport of any part of PGP." The
2452: Government may take the position that the freeware PGP versions are
2453: also subject to those controls.
1.1.1.4 root 2454:
2455: The freeware PGP versions 2.5 and 2.6 were released through a posting
2456: on a controlled FTP site maintained by MIT. This site has
2457: restrictions and limitations which have been used on other FTP sites
2458: to comply with export control requirements with respect to other
2459: encryption software such as Kerberos and software from RSA Data
1.1.1.5 root 2460: Security, Inc. I urge you not to do anything which would weaken
2461: those controls or facilitate any improper export of PGP.
2462:
2463: Although PGP has become a worldwide de facto standard for E-mail
2464: encryption, and is widely available overseas, I still get calls from
2465: people outside the US who ask me if it is legal to use it in their
2466: own country, for versions that are already available there. Please
2467: don't contact me to ask me if it is legal to use PGP in your country
2468: if you live outside the US. That question is not up to me. I've got
2469: enough legal problems of my own with export control issues, without
2470: getting involved in giving you legal advice over my phone. It might
2471: even put me at some legal risk to simply answer a question like that
2472: for a foreigner. If this question concerns you, ask someone else,
2473: like a lawyer.
2474:
2475: You may have a need to use PGP in a commercial application outside
2476: the US or Canada. Unfortunately, at the time of this writing, there
2477: is no current commercial source for PGP outside the US or Canada. I
2478: am trying to find a US-legal way to make a commercially licensed
2479: version available abroad, but right now the US export restrictions
2480: make that difficult without putting me at legal risk. This situation
2481: may change.
1.1.1.4 root 2482:
2483: Some foreign governments impose serious penalties on anyone inside
2484: their country for merely using encrypted communications. In some
2485: countries they might even shoot you for that. But if you live in
2486: that kind of country, perhaps you need PGP even more.
2487:
2488:
2489:
2490: Philip Zimmermann's Legal Situation
2491: -----------------------------------
2492:
2493: At the time of this writing, I am the target of a US Customs criminal
1.1.1.5 root 2494: investigation in the Northern District of California. A criminal
2495: investigation is not a civil lawsuit. Civil lawsuits do not involve
2496: prison terms. My defense attorney has been told by the Assistant US
2497: Attorney that the area of law of interest to the investigation has to
2498: do with the export controls on encryption software. The federal
2499: mandatory sentencing guidelines for this offense are 41 to 51 months
2500: in a federal prison. US Customs appears to be taking the position
2501: that electronic domestic publication of encryption software is the
2502: same as exporting it. The prosecutor has issued a number of federal
2503: grand jury subpoenas. It may be months before a decision is reached
2504: on whether to seek indictment. This situation may change at any
2505: time, so this description may be out of date by the time you read
2506: it. Watch the news for further developments. If I am indicted and
2507: this goes to trial, it will be a major test case.
1.1.1.4 root 2508:
2509: I have a legal defense fund set up for this case. So far, no other
2510: organization is doing the fundraising for me, so I am depending on
1.1.1.5 root 2511: people like you to contribute directly to this cause. If you care
2512: about the future of your civil liberties in the information age, then
2513: perhaps you will care about this case. The legal fees are expensive,
2514: the meter is running, and I need your help. The fund is run by my
2515: lead defense attorney, Phil Dubois, here in Boulder. Please send
2516: your contributions to:
1.1.1.4 root 2517:
1.1.1.5 root 2518: Philip L. Dubois, Lawyer
1.1.1.4 root 2519: 2305 Broadway
2520: Boulder, Colorado 80304 USA
1.1.1.5 root 2521: Phone (303) 444-3885
1.1.1.4 root 2522: E-mail: [email protected]
2523:
2524: You can also phone in your donation and put it on Mastercard or Visa.
2525: If you want to be really cool, you can use Internet E-mail to send in
2526: your contribution, encrypting your message with PGP so that no one
2527: can intercept your credit card number. Include in your E-mail
2528: message your Mastercard or Visa number, expiration date, name on the
2529: card, and amount of donation. Then sign it with your own key and
2530: encrypt it with Phil Dubois's public key (his key is included in the
2531: standard PGP distribution package, in the "keys.asc" file). Put a
2532: note on the subject line that this is a donation to my legal defense
2533: fund, so that Mr. Dubois will decrypt it promptly. Please don't send
1.1.1.5 root 2534: a lot of casual encrypted E-mail to him -- I'd rather he use his
1.1.1.4 root 2535: valuable time to work on my case.
2536:
1.1.1.5 root 2537: If you want to read some press stories to find out why this is an
2538: important case, see the following references:
1.1.1.4 root 2539:
2540: 1) William Bulkeley, "Cipher Probe", Wall Street Journal, Thursday
1.1.1.5 root 2541: 28 April 1994, front page.
1.1.1.4 root 2542: 2) John Cary, "Spy vs. Computer Nerd: The Fight Over Data
2543: Security", Business Week, 4 Oct 1993, page 43.
2544: 3) Jon Erickson, "Cryptography Fires Up the Feds", Dr. Dobb's
2545: Journal, December 1993, page 6.
2546: 4) John Markoff, "Federal Inquiry on Software Examines Privacy
2547: Programs", New York Times, Tuesday 21 Sep 1993, page C1.
2548: 5) Kurt Kleiner, "Punks and Privacy", Mother Jones Magazine,
2549: Jan/Feb 1994, page 17.
1.1.1.5 root 2550: 6) Steven Levy, "Battle of the Clipper Chip", New York Times
2551: Magazine, Sunday 12 Jun 1994, page 44.
2552: 7) Steven Levy, "Crypto Rebels", WIRED, May/Jun 1993, page 54.
2553: 8) John Markoff, "Cyberspace Under Lock and Key", New York Times,
1.1.1.4 root 2554: Sunday 13 Feb 1994.
1.1.1.5 root 2555: 9) Philip Elmer-DeWitt, "Who Should Keep the Keys", Time, 14 Mar
1.1.1.4 root 2556: 1994, page 90.
2557:
1.1.1.5 root 2558: There are a great many other articles on PGP from around the world.
2559: I'm keeping a scrapbook.
2560:
2561:
2562: Other Sources of Information on PGP
2563: ===================================
2564:
1.1.1.4 root 2565:
2566: Where to Get a Commercial Version of PGP
2567: ----------------------------------------
2568:
2569: To get a fully licensed version of PGP for use in the USA or Canada,
2570: contact:
2571:
2572: ViaCrypt
1.1.1.5 root 2573: 9033 North 24th Avenue, Suite 7
2574: Phoenix, Arizona 85021 USA
2575: Phone: (602) 944-0773, or (800) 536-2664
2576: Fax: (602) 943-2601
1.1.1.4 root 2577: E-mail: [email protected]
2578:
2579: ViaCrypt has a version of PGP for MSDOS, and a number of Unix
1.1.1.5 root 2580: platforms. They also have a Windows shell version, and other
2581: versions are under development, including Macintosh. If you have a
2582: need to use PGP in a commercial or Government setting, and ViaCrypt
2583: has a version of PGP for your hardware platform, you should get
2584: ViaCrypt PGP.
1.1.1.4 root 2585:
2586: ViaCrypt has obtained all the necessary licenses from PKP, Ascom-Tech
2587: AG, and Philip Zimmermann to sell PGP for use in commercial or
1.1.1.5 root 2588: government environments. ViaCrypt PGP is every bit as secure as the
1.1.1.4 root 2589: freeware PGP, and is entirely compatible in both directions with the
2590: freeware version of PGP. ViaCrypt PGP is the perfect way to get a
2591: fully licensed version of PGP into your corporate environment.
2592:
1.1.1.5 root 2593: If you work in a large company and you are a fan of PGP, I urge you
2594: to try to persuade your company to buy lots of copies of PGP from
2595: ViaCrypt. Not just because that will earn royalties for me. If
2596: ViaCrypt can make PGP a commercial success, it will go a long way
2597: toward cementing PGP's political future as an unstoppable standard
2598: for E-mail encryption in the corporate world. The corporate world is
2599: where the money is, and that affects public policy like nothing
2600: else. And that includes Government policy to suppress strong
2601: cryptography.
2602:
2603:
1.1.1.4 root 2604:
2605: Reporting PGP Bugs
2606: ------------------
2607:
2608: Bugs in PGP should be reported via E-mail to MIT, the official
2609: distribution site of PGP. The E-mail address for bug reports is
1.1.1.5 root 2610: [email protected]. MIT will forward a copy of your bug report to me.
2611: When you report bugs, be sure to specify what machine and operating
2612: system you are using and what version of PGP you have, and provide
2613: enough detail to reproduce the problem. It would also be a good idea
2614: to find out if you have the latest version of PGP, in case the bug
2615: has already been fixed. Also, it's a good idea to make sure it
2616: really is a bug before you report it. RTFM.
2617:
2618:
2619:
2620: Fan Mail, Updates, and News
2621: ---------------------------
2622:
2623: After all this work I have to admit I wouldn't mind getting some fan
2624: mail for PGP, to gauge its popularity. Let me know what you think
2625: about it and how many of your friends use it. Bug reports and
2626: suggestions for enhancing PGP are welcome, too. Perhaps a future PGP
2627: release will reflect your suggestions.
2628:
2629: This project has not been funded and the project has nearly eaten me
2630: alive. This means you usually won't get a reply to your mail, unless
2631: you only need a short written reply and you include a stamped
2632: self-addressed envelope. But I often do reply to E-mail. Please
2633: keep it in English, as my foreign language skills are weak. If you
2634: call and I'm not in, it's best to just try again later. I usually
2635: don't return long distance phone calls, unless you leave a message
2636: that I can call you collect, and even then I might not return your
2637: call. If you need any significant amount of my time, I am available
2638: on a paid consulting basis, and I always return those calls.
2639:
2640: The most inconvenient mail I get is for some well-intentioned person
2641: to send me a few dollars asking me for a copy of PGP. I don't send
2642: it to them because I'd rather avoid any legal problems with PKP. Or
2643: worse, sometimes these requests are from foreign countries, and I
2644: would be risking a violation of US cryptographic export control
2645: laws. Even if there were no legal hassles involved in sending PGP to
2646: them, they usually don't send enough money to make it worth my time.
2647: I'm just not set up as a low cost low volume mail order business. I
2648: can't just ignore the request and keep the money, because they
2649: probably regard the money as a fee for me to fulfill their request.
2650: If I return the money, I might have to get in my car and drive down
2651: to the post office and buy some postage stamps, because these
2652: requests rarely include a stamped self-addressed envelope. And I
2653: have to take the time to write a polite reply that I can't do it. If
2654: I postpone the reply and set the letter down on my desk, it might be
2655: buried within minutes and won't see the light of day again for
2656: months. Multiply these minor inconveniences by the number of
2657: requests I get, and you can see the problem. Isn't it enough that
2658: the software is free? It would be nicer if people could try to get
2659: PGP from any of the myriad other sources. If you don't have a modem,
2660: ask a friend to get it for you. If you can't find it yourself, I
2661: don't mind answering a quick phone call.
2662:
2663: If anyone wants to volunteer to improve PGP, please let me know. It
2664: could certainly use some more work. Some features were deferred to
2665: get it out the door. A number of PGP users have since donated their
2666: time to port PGP to Unix on Sun SPARCstations, to Ultrix, to VAX/VMS,
2667: to OS/2, to the Amiga, and to the Atari ST. Perhaps you can help
2668: port it to some new environments. But please let me know if you plan
2669: to port or add enhancements to PGP, to avoid duplication of effort,
2670: and to avoid starting with an obsolete version of the source code.
2671:
2672: Because so many foreign language translations of PGP have been
2673: produced, most of them are not distributed with the regular PGP
2674: release package because it would require too much disk space.
2675: Separate language translation "kits" are available from a number of
2676: independent sources, and are sometimes available separately from the
2677: same distribution centers that carry the regular PGP release
2678: software. These kits include translated versions of the file
2679: LANGUAGE.TXT, PGP.HLP, and the PGP User's Guide. If you want to
2680: produce a translation for your own native language, contact me first
2681: to get the latest information and standard guidelines, and to find
2682: out if it's been translated to your language already. To find out
2683: where to get a foreign language kit for your language, you might
2684: check on the Internet newsgroups, or get it from Mike Johnson
2685: ([email protected]).
2686:
2687: If you have access to the Internet, watch for announcements of new
2688: releases of PGP on the Internet newsgroups "sci.crypt" and PGP's own
2689: newsgroup, "alt.security.pgp". If you want to know where to get PGP,
2690: MIT is the primary FTP distribution site (net-dist.mit.edu). Or ask
2691: Mike Johnson ([email protected]) for a list of Internet FTP sites and BBS
2692: phone numbers.
1.1.1.4 root 2693:
2694:
2695:
2696: Computer-Related Political Groups
1.1.1.5 root 2697: ---------------------------------
1.1.1.4 root 2698:
2699: PGP is a very political piece of software. It seems appropriate to
2700: mention here some computer-related activist groups. Full details on
2701: these groups, and how to join them, is provided in a separate
2702: document file in the PGP release package.
2703:
1.1.1.5 root 2704: The Electronic Privacy Information Center (EPIC) is a public interest
2705: research center in Washington, DC. It was established in 1994 to
2706: focus public attention on emerging privacy issues relating to the
2707: National Information Infrastructure, such as the Clipper Chip, the
2708: Digital Telephony proposal, medical record privacy, and the sale of
2709: consumer data. EPIC is sponsored by the Fund for Constitutional
2710: Government and Computer Professionals for Social Responsibility.
2711: EPIC publishes the EPIC Alert and EPIC Reports, pursues Freedom of
2712: Information Act litigation, and conducts policy research on emerging
2713: privacy issues. For more information email [email protected], or write
2714: EPIC, 666 Pennsylvania Ave., SE, Suite 301, Washington, DC 20003.
2715: +1 202 544 9240 (tel), +1 202 547 5482 (fax).
2716:
1.1.1.4 root 2717: The Electronic Frontier Foundation (EFF) was founded in 1990 to
2718: assure freedom of expression in digital media, with a particular
2719: emphasis on applying the principles embodied in the US Constitution
2720: and the Bill of Rights to computer-based communication. They can be
2721: reached in Washington DC, at (202) 347-5400. Internet E-mail address:
2722: [email protected].
2723:
2724: Computer Professionals For Social Responsibility (CPSR) empowers
2725: computer professionals and computer users to advocate for the
2726: responsible use of information technology and empowers all who use
2727: computer technology to participate in public policy debates on the
2728: impacts of computers on society. They can be reached at:
1.1.1.5 root 2729: (415) 322-3778 in Palo Alto, E-mail address [email protected].
1.1.1.4 root 2730:
1.1.1.5 root 2731: The League for Programming Freedom (LPF) is a grass-roots
2732: organization of professors, students, businessmen, programmers and
2733: users dedicated to bringing back the freedom to write programs. They
2734: regard patents on computer algorithms as harmful to the US software
2735: industry (and so do I!). They can be reached at (617) 433-7071.
2736: E-mail address: [email protected].
1.1.1.4 root 2737:
2738: For more details on these groups, see the accompanying document in
2739: the PGP release package.
2740:
1.1.1.5 root 2741:
2742:
2743: Recommended Readings
2744: --------------------
2745:
2746:
2747: Introductory Readings
1.1.1.4 root 2748:
2749: 1) Bruce Schneier, "Applied Cryptography: Protocols, Algorithms, and
2750: Source Code in C", John Wiley & Sons, 1993
2751: (This book is a watershed work on the subject.)
2752: 2) Dorothy Denning, "Cryptography and Data Security", Addison-Wesley,
2753: Reading, MA 1982
2754: 3) Dorothy Denning, "Protecting Public Keys and Signature Keys",
2755: IEEE Computer, Feb 1983
2756: 4) Martin E. Hellman, "The Mathematics of Public-Key Cryptography,"
2757: Scientific American, Aug 1979
2758: 5) Steven Levy, "Crypto Rebels", WIRED, May/Jun 1993, page 54.
1.1.1.5 root 2759: (A "must-read" article on PGP and other related topics.)
2760: 6) Steven Levy, "Battle of the Clipper Chip", New York Times
2761: Magazine, Sunday 12 Jun 1994, page 44. (Great article, great
2762: photos.)
2763: 7) William Bulkeley, "Cipher Probe", Wall Street Journal, 28 April
2764: 1994, front page. (An article on PGP and Zimmermann.)
2765:
1.1.1.4 root 2766:
2767: Other Readings
2768:
1.1.1.5 root 2769: 8) Ronald Rivest, "The MD5 Message Digest Algorithm", MIT Laboratory
1.1.1.4 root 2770: for Computer Science, 1991
1.1.1.5 root 2771: 9) Xuejia Lai, "On the Design and Security of Block Ciphers",
1.1.1.4 root 2772: ETH Series on Information Processing (Ed. J. L. Massey),
2773: Vol. 1, Hartung-Gorre Verlag, Konstanz, Switzerland, 1992
1.1.1.5 root 2774: 10) Philip Zimmermann, "A Proposed Standard Format for RSA
1.1.1.4 root 2775: Cryptosystems", Advances in Computer Security, Vol III, edited by
2776: Rein Turn, Artech House, 1988
1.1.1.5 root 2777: 11) Paul Wallich, "Electronic Envelopes", Scientific American, Feb
2778: 1993, page 30. (An article on PGP)
2779: 12) William Stallings, "Pretty Good Privacy", BYTE, July 1994, page
2780: 193
2781: 13) Philip Zimmermann, "The Official PGP User's Guide", MIT Press,
2782: 1994 (in press)
2783: 14) Philip Zimmermann, "PGP Source Code and Internals", MIT Press,
2784: 1994 (in press)
2785:
1.1.1.4 root 2786:
2787:
2788: To Contact the Author
1.1.1.5 root 2789: ---------------------
1.1.1.4 root 2790:
2791: Philip Zimmermann may be reached at:
2792:
2793: Boulder Software Engineering
2794: 3021 Eleventh Street
2795: Boulder, Colorado 80304 USA
2796: Internet: [email protected]
1.1.1.5 root 2797: Phone (303) 541-0140 (voice) (10:00am - 7:00pm Mountain Time)
2798: Fax available, if you arrange it via voice line.
1.1.1.4 root 2799:
2800:
2801: Appendix A: Where to Get PGP
2802: =============================
2803:
2804: The following describes how to get the freeware public key
2805: cryptographic software PGP (Pretty Good Privacy) from an anonymous
2806: FTP site on Internet, or from other sources.
2807:
1.1.1.5 root 2808: PGP has become a worldwide de facto standard for E-mail encryption.
1.1.1.4 root 2809: PGP has sophisticated key management, an RSA/conventional hybrid
2810: encryption scheme, message digests for digital signatures, data
2811: compression before encryption, and good ergonomic design. PGP is
2812: well featured and fast, and has excellent user documentation. Source
2813: code is free.
2814:
2815: The Massachusetts Institute of Technology is the distributor of PGP
2816: version 2.6, for distribution in the USA only. It is available from
2817: "net-dist.mit.edu," a controlled FTP site that has restrictions and
2818: limitations, similar to those used by RSA Data Security, Inc., to comply
2819: with export control requirements. The software resides in the directory
2820: /pub/PGP.
2821:
2822: A reminder: Set mode to binary or image when doing an FTP transfer.
2823: And when doing a kermit download to your PC, specify 8-bit binary
2824: mode at both ends.
2825:
2826: There are two compressed archive files in the standard release, with
2827: the file name derived from the release version number. For PGP
1.1.1.6 ! root 2828: version 2.6.2, you must get pgp262.zip which contains the MSDOS
1.1.1.5 root 2829: binary executable and the PGP User's Guide, and you can optionally
1.1.1.6 ! root 2830: get pgp262s.zip which contains all the source code. These files can
1.1.1.5 root 2831: be decompressed with the MSDOS shareware archive decompression
2832: utility PKUNZIP.EXE, version 1.10 or later. For Unix users who lack
2833: an implementation of UNZIP, the source code can also be found in the
1.1.1.6 ! root 2834: compressed tar file pgp262s.tar.Z.
1.1.1.4 root 2835:
2836: If you don't have any local BBS phone numbers handy, here is a BBS
2837: you might try. The Catacombs BBS, operated by Mike Johnson in
2838: Longmont, Colorado, has PGP available for download by people in the US
2839: or Canada only. The BBS phone number is 303-772-1062. Mike
1.1.1.5 root 2840: Johnson's voice phone number is 303 772-1773, and his E-mail address
1.1.1.4 root 2841: is [email protected]. Mike also has PGP available on an Internet FTP site
2842: for users in the US or Canada only; the site name is csn.org, in
2843: directory /mpj/, and you must read the README.MPJ file to get it.
2844:
2845: To get a fully licensed version of PGP for use in the USA or Canada,
2846: contact ViaCrypt in Phoenix, Arizona. Their phone number is
2847: 602-944-0773. ViaCrypt has obtained all the necessary licenses from
2848: PKP, Ascom-Tech AG, and Philip Zimmermann to sell PGP for use in
2849: commercial or Government environments. ViaCrypt PGP is every bit as
2850: secure as the freeware PGP, and is entirely compatible in both
2851: directions with the freeware version of PGP. ViaCrypt PGP is the
2852: perfect way to get a fully licensed version of PGP into your
2853: corporate or Government environment.
2854:
1.1.1.5 root 2855: Here are a few people and their E-mail addresses or phone numbers you
1.1.1.4 root 2856: can contact in some countries to get information on local PGP
2857: availability for versions earlier than 2.5:
2858:
2859: Peter Gutmann Hugh Kennedy
2860: [email protected] [email protected]
2861: New Zealand Germany
2862:
2863: Branko Lankester Miguel Angel Gallardo
2864: [email protected] [email protected]
2865: +31 2159 42242 (341) 474 38 09
2866: The Netherlands Spain
2867:
2868: Hugh Miller Colin Plumb
2869: [email protected] [email protected]
2870: (312) 508-2727 Toronto, Ontario, Canada
2871: USA
2872:
2873: Jean-loup Gailly
2874: [email protected]
2875: France
2876:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.