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