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