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