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