![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to pgpdoc1.txt CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [PGP] / pgp / doc|
Return to pgpdoc1.txt CVS log | Up to [PGP] / pgp / doc |
1.1.1.4 root 1: 1.1.1.5 ! root 2: ! 3: 1.1.1.4 root 4: Phil's Pretty Good Software 5: Presents 6: 7: ======= 8: PGP(tm) 9: ======= 10: 11: Pretty Good(tm) Privacy 12: Public Key Encryption for the Masses 13: 14: 15: -------------------------- 1.1.1.5 ! root 16: PGP(tm) User's Guide ! 17: Volume I: Essential Topics 1.1.1.4 root 18: -------------------------- 1.1.1.5 ! root 19: by Philip Zimmermann ! 20: Revised 31 August 94 1.1.1.4 root 21: 22: 1.1.1.5 ! root 23: PGP Version 2.6.1 - 30 Aug 94 1.1.1.4 root 24: Software by 25: Philip Zimmermann, and many others. 26: 27: 28: 29: 30: Synopsis: PGP(tm) uses public-key encryption to protect E-mail and 31: data files. Communicate securely with people you've never met, with 32: no secure channels needed for prior exchange of keys. PGP is well 33: featured and fast, with sophisticated key management, digital 34: signatures, data compression, and good ergonomic design. 35: 36: 37: Software and documentation (c) Copyright 1990-1994 Philip Zimmermann. 38: All rights reserved. For information on PGP licensing, distribution, 39: copyrights, patents, trademarks, liability limitations, and export 40: controls, see the "Legal Issues" section in the "PGP User's Guide, 41: Volume II: Special Topics". Distributed by the Massachusetts 42: Institute of Technology. 43: 44: 45: "Whatever you do will be insignificant, but it is very important that 46: you do it." --Mahatma Gandhi 47: 48: 49: Contents 50: ======== 51: 52: Quick Overview 53: Why Do You Need PGP? 54: How it Works 55: Installing PGP 56: How to Use PGP 57: To See a Usage Summary 58: Encrypting a Message 59: Encrypting a Message to Multiple Recipients 60: Signing a Message 61: Signing and then Encrypting 62: Using Just Conventional Encryption 63: Decrypting and Checking Signatures 64: Managing Keys 65: RSA Key Generation 66: Adding a Key to Your Key Ring 67: Removing a Key or User ID from Your Key Ring 68: Extracting (copying) a Key from Your Key Ring 69: Viewing the Contents of Your Key Ring 70: How to Protect Public Keys from Tampering 71: How Does PGP Keep Track of Which Keys are Valid? 72: How to Protect Secret Keys from Disclosure 73: Revoking a Public Key 74: What If You Lose Your Secret Key? 75: Advanced Topics 76: Sending Ciphertext Through E-mail Channels: Radix-64 Format 77: Environmental Variable for Path Name 78: Setting Configuration Parameters: CONFIG.TXT 79: Vulnerabilities 80: Beware of Snake Oil 1.1.1.5 ! root 81: Notice to Macintosh Users 1.1.1.4 root 82: PGP Quick Reference 83: Legal Issues 84: Acknowledgments 85: About the Author 86: 87: 88: Quick Overview 89: ============== 90: 91: Pretty Good(tm) Privacy (PGP), from Phil's Pretty Good Software, is a 92: high security cryptographic software application for MSDOS, Unix, 93: VAX/VMS, and other computers. PGP allows people to exchange files or 94: messages with privacy, authentication, and convenience. Privacy 95: means that only those intended to receive a message can read it. 96: Authentication means that messages that appear to be from a 97: particular person can only have originated from that person. 98: Convenience means that privacy and authentication are provided 99: without the hassles of managing keys associated with conventional 100: cryptographic software. No secure channels are needed to exchange 101: keys between users, which makes PGP much easier to use. This is 102: because PGP is based on a powerful new technology called "public key" 103: cryptography. 104: 105: PGP combines the convenience of the Rivest-Shamir-Adleman (RSA) 106: public key cryptosystem with the speed of conventional cryptography, 107: message digests for digital signatures, data compression before 108: encryption, good ergonomic design, and sophisticated key management. 109: And PGP performs the public-key functions faster than most other 110: software implementations. PGP is public key cryptography for the 111: masses. 112: 113: PGP does not provide any built-in modem communications capability. 114: You must use a separate software product for that. 115: 116: This document, "Volume I: Essential Topics", only explains the 117: essential concepts for using PGP, and should be read by all PGP 118: users. "Volume II: Special Topics" covers the advanced features of 119: PGP and other special topics, and may be read by more serious PGP 120: users. Neither volume explains the underlying technology details of 121: cryptographic algorithms and data structures. 122: 123: 124: Why Do You Need PGP? 125: ==================== 126: 127: It's personal. It's private. And it's no one's business but yours. 128: You may be planning a political campaign, discussing your taxes, or 129: having an illicit affair. Or you may be doing something that you 130: feel shouldn't be illegal, but is. Whatever it is, you don't want 131: your private electronic mail (E-mail) or confidential documents read 132: by anyone else. There's nothing wrong with asserting your privacy. 133: Privacy is as apple-pie as the Constitution. 134: 135: Perhaps you think your E-mail is legitimate enough that encryption is 136: unwarranted. If you really are a law-abiding citizen with nothing to 137: hide, then why don't you always send your paper mail on postcards? 138: Why not submit to drug testing on demand? Why require a warrant for 139: police searches of your house? Are you trying to hide something? 140: You must be a subversive or a drug dealer if you hide your mail 141: inside envelopes. Or maybe a paranoid nut. Do law-abiding citizens 142: have any need to encrypt their E-mail? 143: 144: What if everyone believed that law-abiding citizens should use 145: postcards for their mail? If some brave soul tried to assert his 146: privacy by using an envelope for his mail, it would draw suspicion. 147: Perhaps the authorities would open his mail to see what he's hiding. 148: Fortunately, we don't live in that kind of world, because everyone 149: protects most of their mail with envelopes. So no one draws suspicion 150: by asserting their privacy with an envelope. There's safety in 151: numbers. Analogously, it would be nice if everyone routinely used 152: encryption for all their E-mail, innocent or not, so that no one drew 153: suspicion by asserting their E-mail privacy with encryption. Think 154: of it as a form of solidarity. 155: 156: Today, if the Government wants to violate the privacy of ordinary 157: citizens, it has to expend a certain amount of expense and labor to 158: intercept and steam open and read paper mail, and listen to and 159: possibly transcribe spoken telephone conversation. This kind of 160: labor-intensive monitoring is not practical on a large scale. This 161: is only done in important cases when it seems worthwhile. 162: 163: More and more of our private communications are being routed through 164: electronic channels. Electronic mail is gradually replacing 165: conventional paper mail. E-mail messages are just too easy to 166: intercept and scan for interesting keywords. This can be done 167: easily, routinely, automatically, and undetectably on a grand scale. 168: International cablegrams are already scanned this way on a large 169: scale by the NSA. 170: 171: We are moving toward a future when the nation will be crisscrossed 172: with high capacity fiber optic data networks linking together all our 173: increasingly ubiquitous personal computers. E-mail will be the norm 174: for everyone, not the novelty it is today. The Government will 175: protect our E-mail with Government-designed encryption protocols. 176: Probably most people will acquiesce to that. But perhaps some people 177: will prefer their own protective measures. 178: 179: Senate Bill 266, a 1991 omnibus anti-crime bill, had an unsettling 180: measure buried in it. If this non-binding resolution had become real 181: law, it would have forced manufacturers of secure communications 182: equipment to insert special "trap doors" in their products, so that 183: the Government can read anyone's encrypted messages. It reads: "It 184: is the sense of Congress that providers of electronic communications 185: services and manufacturers of electronic communications service 186: equipment shall insure that communications systems permit the 187: Government to obtain the plain text contents of voice, data, and 188: other communications when appropriately authorized by law." This 189: measure was defeated after rigorous protest from civil libertarians 190: and industry groups. 191: 192: In 1992, the FBI Digital Telephony wiretap proposal was introduced to 193: Congress. It would require all manufacturers of communications 194: equipment to build in special remote wiretap ports that would enable 195: the FBI to remotely wiretap all forms of electronic communication 196: from FBI offices. Although it never attracted any sponsors in 197: Congress in 1992 because of citizen opposition, it was reintroduced in 198: 1994. 199: 200: Most alarming of all is the White House's bold new encryption policy 201: initiative, under development at NSA since the start of the Bush 202: administration, and unveiled April 16th, 1993. The centerpiece of 203: this initiative is a Government-built encryption device, called the 204: "Clipper" chip, containing a new classified NSA encryption 205: algorithm. The Government is encouraging private industry to design 206: it into all their secure communication products, like secure phones, 207: secure FAX, etc. AT&T is now putting the Clipper into their secure 208: voice products. The catch: At the time of manufacture, each Clipper 209: chip will be loaded with its own unique key, and the Government gets 210: to keep a copy, placed in escrow. Not to worry, though-- the 211: Government promises that they will use these keys to read your 212: traffic only when duly authorized by law. Of course, to make Clipper 213: completely effective, the next logical step would be to outlaw other 214: forms of cryptography. 215: 216: If privacy is outlawed, only outlaws will have privacy. Intelligence 217: agencies have access to good cryptographic technology. So do the big 218: arms and drug traffickers. So do defense contractors, oil companies, 219: and other corporate giants. But ordinary people and grassroots 220: political organizations mostly have not had access to affordable 221: "military grade" public-key cryptographic technology. Until now. 222: 223: PGP empowers people to take their privacy into their own hands. 224: There's a growing social need for it. That's why I wrote it. 225: 226: 227: How it Works 228: ============ 229: 230: It would help if you were already familiar with the concept of 231: cryptography in general and public key cryptography in particular. 232: Nonetheless, here are a few introductory remarks about public key 233: cryptography. 234: 235: First, some elementary terminology. Suppose I want to send you a 236: message, but I don't want anyone but you to be able to read it. I 237: can "encrypt", or "encipher" the message, which means I scramble it 238: up in a hopelessly complicated way, rendering it unreadable to anyone 239: except you, the intended recipient of the message. I supply a 240: cryptographic "key" to encrypt the message, and you have to use the 241: same key to decipher or "decrypt" it. At least that's how it works 242: in conventional "single-key" cryptosystems. 243: 244: In conventional cryptosystems, such as the US Federal Data Encryption 245: Standard (DES), a single key is used for both encryption and 246: decryption. This means that a key must be initially transmitted via 247: secure channels so that both parties can know it before encrypted 248: messages can be sent over insecure channels. This may be 249: inconvenient. If you have a secure channel for exchanging keys, then 250: why do you need cryptography in the first place? 251: 252: In public key cryptosystems, everyone has two related complementary 1.1.1.5 ! root 253: keys, a publicly revealed key and a secret key (also frequently called ! 254: a private key). Each key unlocks the code that the other key makes. ! 255: Knowing the public key does not help you deduce the corresponding ! 256: secret key. The public key can be published and widely disseminated ! 257: across a communications network. This protocol provides privacy ! 258: without the need for the same kind of secure channels that a ! 259: conventional cryptosystem requires. 1.1.1.4 root 260: 261: Anyone can use a recipient's public key to encrypt a message to that 262: person, and that recipient uses her own corresponding secret key to 263: decrypt that message. No one but the recipient can decrypt it, 264: because no one else has access to that secret key. Not even the 265: person who encrypted the message can decrypt it. 266: 267: Message authentication is also provided. The sender's own secret key 268: can be used to encrypt a message, thereby "signing" it. This creates 269: a digital signature of a message, which the recipient (or anyone 270: else) can check by using the sender's public key to decrypt it. This 271: proves that the sender was the true originator of the message, and 272: that the message has not been subsequently altered by anyone else, 273: because the sender alone possesses the secret key that made that 274: signature. Forgery of a signed message is infeasible, and the sender 275: cannot later disavow his signature. 276: 277: These two processes can be combined to provide both privacy and 278: authentication by first signing a message with your own secret key, 279: then encrypting the signed message with the recipient's public key. 280: The recipient reverses these steps by first decrypting the message 281: with her own secret key, then checking the enclosed signature with 282: your public key. These steps are done automatically by the 283: recipient's software. 284: 285: Because the public key encryption algorithm is much slower than 286: conventional single-key encryption, encryption is better accomplished 287: by using a high-quality fast conventional single-key encryption 288: algorithm to encipher the message. This original unenciphered 289: message is called "plaintext". In a process invisible to the user, a 290: temporary random key, created just for this one "session", is used to 291: conventionally encipher the plaintext file. Then the recipient's 292: public key is used to encipher this temporary random conventional 293: key. This public-key-enciphered conventional "session" key is sent 294: along with the enciphered text (called "ciphertext") to the 295: recipient. The recipient uses her own secret key to recover this 296: temporary session key, and then uses that key to run the fast 297: conventional single-key algorithm to decipher the large ciphertext 298: message. 299: 300: Public keys are kept in individual "key certificates" that include 301: the key owner's user ID (which is that person's name), a timestamp of 302: when the key pair was generated, and the actual key material. Public 303: key certificates contain the public key material, while secret key 304: certificates contain the secret key material. Each secret key is 305: also encrypted with its own password, in case it gets stolen. A key 306: file, or "key ring" contains one or more of these key certificates. 307: Public key rings contain public key certificates, and secret key 308: rings contain secret key certificates. 309: 310: The keys are also internally referenced by a "key ID", which is an 311: "abbreviation" of the public key (the least significant 64 bits of 312: the large public key). When this key ID is displayed, only the lower 313: 32 bits are shown for further brevity. While many keys may share the 314: same user ID, for all practical purposes no two keys share the same 315: key ID. 316: 317: PGP uses "message digests" to form signatures. A message digest is a 318: 128-bit cryptographically strong one-way hash function of the 319: message. It is somewhat analogous to a "checksum" or CRC error 320: checking code, in that it compactly "represents" the message and is 321: used to detect changes in the message. Unlike a CRC, however, it is 322: computationally infeasible for an attacker to devise a substitute 323: message that would produce an identical message digest. The message 324: digest gets encrypted by the secret key to form a signature. 325: 326: Documents are signed by prefixing them with signature certificates, 327: which contain the key ID of the key that was used to sign it, a 328: secret-key-signed message digest of the document, and a timestamp of 329: when the signature was made. The key ID is used by the receiver to 330: look up the sender's public key to check the signature. The 331: receiver's software automatically looks up the sender's public key 332: and user ID in the receiver's public key ring. 333: 334: Encrypted files are prefixed by the key ID of the public key used to 335: encrypt them. The receiver uses this key ID message prefix to look 336: up the secret key needed to decrypt the message. The receiver's 337: software automatically looks up the necessary secret decryption key 338: in the receiver's secret key ring. 339: 340: These two types of key rings are the principal method of storing and 341: managing public and secret keys. Rather than keep individual keys in 342: separate key files, they are collected in key rings to facilitate the 343: automatic lookup of keys either by key ID or by user ID. Each user 344: keeps his own pair of key rings. An individual public key is 345: temporarily kept in a separate file long enough to send to your 346: friend who will then add it to her key ring. 347: 348: 349: 350: Installing PGP 351: ============== 352: 1.1.1.5 ! root 353: The MSDOS PGP release package comes in a compressed archive file with ! 354: a file named in this form: PGPxx.ZIP (each release version has a ! 355: different number for the "xx" in the filename). For example, the ! 356: release package for version 2.6 is called PGP26.ZIP. The archive can ! 357: be decompressed with the MSDOS shareware decompression utility ! 358: PKUNZIP, or the Unix utility "unzip". When the PGP release package ! 359: is decompressed, several files emerge from it. One such file, called ! 360: README.DOC, should always be read before installing PGP. This file ! 361: contains late-breaking news on what's new in this release of PGP, as ! 362: well as information on what's in all the other files included in the ! 363: release. 1.1.1.4 root 364: 365: If you already have an earlier version of PGP, you should rename it 366: or delete it, to avoid name conflicts with the new PGP. 367: 368: To install PGP on your MSDOS system, you just have to copy the 369: compressed archive PGPxx.ZIP file into a suitable directory on your 370: hard disk (like C:\PGP), and decompress it with PKUNZIP. For best 371: results, you will also modify your AUTOEXEC.BAT file, as described 372: elsewhere in this manual, but you can do that later, after you've 373: played with PGP a bit and read more of this manual. If you haven't 374: run PGP before, the first step after installation (and reading this 375: manual) is to run the PGP key generation command "pgp -kg". 376: 377: Installing on Unix and VAX/VMS is generally similar to installing on 378: MSDOS, but you may have to compile the source code first. A Unix 379: makefile is provided with the source release for this purpose. 380: 381: For further details on installation, see the separate PGP 382: Installation Guide, in the file SETUP.DOC included with this 383: release. It fully describes how to set up the PGP directory and your 384: AUTOEXEC.BAT file and how to use PKUNZIP to install it. 385: 386: 387: 388: How to Use PGP 389: ============== 390: 391: 392: To See a Usage Summary 393: ---------------------- 394: 395: To see a quick command usage summary for PGP, just type: 396: 397: pgp -h 398: 399: 400: 401: Encrypting a Message 402: -------------------- 403: 404: To encrypt a plaintext file with the recipient's public key, type: 405: 406: pgp -e textfile her_userid 407: 408: This command produces a ciphertext file called textfile.pgp. A 409: specific example is: 410: 411: pgp -e letter.txt Alice 412: or: 413: pgp -e letter.txt "Alice S" 414: 415: The first example searches your public key ring file "pubring.pgp" 416: for any public key certificates that contain the string "Alice" 417: anywhere in the user ID field. The second example would find any 418: user IDs that contain "Alice S". You can't use spaces in the string 419: on the command line unless you enclose the whole string in quotes. 420: The search is not case-sensitive. If it finds a matching public key, 421: it uses it to encrypt the plaintext file "letter.txt", producing a 422: ciphertext file called "letter.pgp". 423: 424: PGP attempts to compress the plaintext before encrypting it, thereby 425: greatly enhancing resistance to cryptanalysis. Thus the ciphertext 426: file will likely be smaller than the plaintext file. 427: 428: If you want to send this encrypted message through E-mail channels, 429: convert it into printable ASCII "radix-64" format by adding the -a 430: option, as described later. 431: 432: 433: 434: Encrypting a Message to Multiple Recipients 435: ------------------------------------------- 436: 437: If you want to send the same message to more than one person, you may 438: specify encryption for several recipients, any of whom may decrypt the 439: same ciphertext file. To specify multiple recipients, just add more 440: user IDs to the command line, like so: 441: 442: pgp -e letter.txt Alice Bob Carol 443: 444: This would create a ciphertext file called letter.pgp that could be 445: decrypted by Alice or Bob or Carol. Any number of recipients may be 446: specified. 447: 448: 449: 450: Signing a Message 451: ----------------- 452: 453: To sign a plaintext file with your secret key, type: 454: 455: pgp -s textfile [-u your_userid] 456: 457: Note that [brackets] denote an optional field, so don't actually type 458: real brackets. 459: 460: This command produces a signed file called textfile.pgp. A specific 461: example is: 462: 463: pgp -s letter.txt -u Bob 464: 465: This searches your secret key ring file "secring.pgp" for any secret 466: key certificates that contain the string "Bob" anywhere in the user 467: ID field. Your name is Bob, isn't it? The search is not 468: case-sensitive. If it finds a matching secret key, it uses it to 469: sign the plaintext file "letter.txt", producing a signature file 470: called "letter.pgp". 471: 472: If you leave off the user ID field, the first key on your secret 473: key ring is used as the default secret key for your signature. 474: 475: PGP attempts to compress the message after signing it. Thus the 476: signed file will likely be smaller than the original file, which is 477: useful for archival applications. However, this renders the file 478: unreadable to the casual human observer, even if the original message 479: was ordinary ASCII text. It would be nice if you could make a signed 480: file that was still directly readable to a human. This would be 481: particularly useful if you want to send a signed message as E-mail. 482: 483: For signing E-mail messages, where you most likely do want the result 484: to be human-readable, it is probably most convenient to use the 485: CLEARSIG feature, explained later. This allows the signature to be 486: applied in printable form at the end of the text, and also disables 487: compression of the text. This means the text is still human-readable 488: by the recipient even if the recipient doesn't use PGP to check the 489: signature. This is explained in detail in the section entitled 490: "CLEARSIG - Enable Signed Messages to be Encapsulated as Clear Text", 491: in the Special Topics volume. If you can't wait to read that section 492: of the manual, you can see how an E-mail message signed this way 493: would look, with this example: 494: 495: pgp -sta message.txt 496: 497: This would create a signed message in file "message.asc", comprised 498: of the original text, still human-readable, appended with a printable 499: ASCII signature certificate, ready to send through an E-mail system. 500: This example assumes that you are using the normal settings for 501: enabling the CLEARSIG flag in the config file. 502: 503: 504: Signing and then Encrypting 505: --------------------------- 506: 507: To sign a plaintext file with your secret key, and then encrypt it 508: with the recipient's public key: 509: 510: pgp -es textfile her_userid [-u your_userid] 511: 512: Note that [brackets] denote an optional field, so don't actually type 513: real brackets. 514: 515: This example produces a nested ciphertext file called textfile.pgp. 516: Your secret key to create the signature is automatically looked up in 517: your secret key ring via your_userid. Her public encryption key is 518: automatically looked up in your public key ring via her_userid. If 519: you leave off her user ID field from the command line, you will be 520: prompted for it. 521: 522: If you leave off your own user ID field, the first key on your secret 523: key ring is be used as the default secret key for your signature. 524: 525: Note that PGP attempts to compress the plaintext before encrypting 526: it. 527: 528: If you want to send this encrypted message through E-mail channels, 529: convert it into printable ASCII "radix-64" format by adding the -a 530: option, as described later. 531: 532: Multiple recipients may be specified by adding more user IDs to the 533: command line. 534: 535: 536: 537: Using Just Conventional Encryption 538: ---------------------------------- 539: 540: Sometimes you just need to encrypt a file the old-fashioned way, with 541: conventional single-key cryptography. This approach is useful for 542: protecting archive files that will be stored but will not be sent to 543: anyone else. Since the same person that encrypted the file will also 544: decrypt the file, public key cryptography is not really necessary. 545: 546: To encrypt a plaintext file with just conventional cryptography, 547: type: 548: 549: pgp -c textfile 550: 551: This example encrypts the plaintext file called textfile, producing a 552: ciphertext file called textfile.pgp, without using public key 553: cryptography, key rings, user IDs, or any of that stuff. It prompts 554: you for a pass phrase to use as a conventional key to encipher the 555: file. This pass phrase need not be (and, indeed, SHOULD not be) the 556: same pass phrase that you use to protect your own secret key. Note 557: that PGP attempts to compress the plaintext before encrypting it. 558: 559: PGP will not encrypt the same plaintext the same way twice, even if 560: you used the same pass phrase every time. 561: 562: 563: 564: Decrypting and Checking Signatures 565: ---------------------------------- 566: 567: To decrypt an encrypted file, or to check the signature integrity of a 568: signed file: 569: 570: pgp ciphertextfile [-o plaintextfile] 571: 572: Note that [brackets] denote an optional field, so don't actually type 573: real brackets. 574: 575: The ciphertext file name is assumed to have a default extension of 576: ".pgp". The optional plaintext output file name specifies where to 577: put processed plaintext output. If no name is specified, the 578: ciphertext filename is used, with no extension. If a signature is 579: nested inside of an encrypted file, it is automatically decrypted and 580: the signature integrity is checked. The full user ID of the signer 581: is displayed. 582: 583: Note that the "unwrapping" of the ciphertext file is completely 584: automatic, regardless of whether the ciphertext file is just signed, 585: just encrypted, or both. PGP uses the key ID prefix in the 586: ciphertext file to automatically find the appropriate secret 587: decryption key on your secret key ring. If there is a nested 588: signature, PGP then uses the key ID prefix in the nested signature to 589: automatically find the appropriate public key on your public key ring 590: to check the signature. If all the right keys are already present on 591: your key rings, no user intervention is required, except that you 592: will be prompted for your password for your secret key if necessary. 593: If the ciphertext file was conventionally encrypted without public 594: key cryptography, PGP recognizes this and prompts you for the pass 595: phrase to conventionally decrypt it. 596: 597: 598: Managing Keys 599: ============= 600: 601: Since the time of Julius Caesar, key management has always been the 602: hardest part of cryptography. One of the principal distinguishing 603: features of PGP is its sophisticated key management. 604: 605: 606: 607: RSA Key Generation 608: ------------------ 609: 610: To generate your own unique public/secret key pair of a specified 611: size, type: 612: 613: pgp -kg 614: 615: PGP shows you a menu of recommended key sizes (low commercial grade, 616: high commercial grade, or "military" grade) and prompts you for what 617: size key you want, up to more than a thousand bits. The bigger the 618: key, the more security you get, but you pay a price in speed. 619: 620: It also asks for a user ID, which means your name. It's a good idea 621: to use your full name as your user ID, because then there is less 622: risk of other people using the wrong public key to encrypt messages 623: to you. Spaces and punctuation are allowed in the user ID. It would 624: help if you put your E-mail address in <angle brackets> after your 625: name, like so: 626: 627: Robert M. Smith <[email protected]> 628: 629: If you don't have an E-mail address, use your phone number or some 630: other unique information that would help ensure that your user ID is 631: unique. 632: 633: PGP also asks for a "pass phrase" to protect your secret key in case 634: it falls into the wrong hands. Nobody can use your secret key file 635: without this pass phrase. The pass phrase is like a password, except 636: that it can be a whole phrase or sentence with many words, spaces, 637: punctuation, or anything else you want in it. Don't lose this pass 638: phrase-- there's no way to recover it if you do lose it. This pass 639: phrase will be needed later every time you use your secret key. The 640: pass phrase is case-sensitive, and should not be too short or easy to 641: guess. It is never displayed on the screen. Don't leave it written 642: down anywhere where someone else can see it, and don't store it on 643: your computer. If you don't want a pass phrase (You fool!), just 644: press return (or enter) at the pass phrase prompt. 645: 646: The public/secret key pair is derived from large truly random numbers 647: derived mainly from measuring the intervals between your keystrokes 648: with a fast timer. The software will ask you to enter some random 649: text to help it accumulate some random bits for the keys. When 650: asked, you should provide some keystrokes that are reasonably random 651: in their timing, and it wouldn't hurt to make the actual characters 652: that you type irregular in content as well. Some of the randomness 653: is derived from the unpredictability of the content of what you 654: type. So don't just type repeated sequences of characters. 655: 656: Note that RSA key generation is a lengthy process. It may take a few 657: seconds for a small key on a fast processor, or quite a few minutes 658: for a large key on an old IBM PC/XT. PGP will visually indicate its 659: progress during key generation. 660: 661: The generated key pair will be placed on your public and secret key 662: rings. You can later use the -kx command option to extract (copy) 663: your new public key from your public key ring and place it in a 664: separate public key file suitable for distribution to your friends. 665: The public key file can be sent to your friends for inclusion in 666: their public key rings. Naturally, you keep your secret key file to 667: yourself, and you should include it on your secret key ring. Each 668: secret key on a key ring is individually protected with its own pass 669: phrase. 670: 671: Never give your secret key to anyone else. For the same reason, don't 672: make key pairs for your friends. Everyone should make their own key 673: pair. Always keep physical control of your secret key, and don't risk 674: exposing it by storing it on a remote timesharing computer. Keep it 675: on your own personal computer. 676: 677: If PGP complains about not being able to find the PGP User's Guide on 678: your computer, and refuses to generate a key pair without it, read 679: the explanation of the NOMANUAL parameter in the section "Setting 680: Configuration Parameters" in the Special Topics volume. 681: 682: 683: Adding a Key to Your Key Ring 684: ----------------------------- 685: 686: Sometimes you will want to add to your keyring a key provided to you 687: by someone else, in the form of a keyfile. 688: 689: To add a public or secret key file's contents to your public or 690: secret key ring (note that [brackets] denote an optional field): 691: 692: pgp -ka keyfile [keyring] 693: 694: The keyfile extension defaults to ".pgp". The optional keyring file 695: name defaults to "pubring.pgp" or "secring.pgp", depending on whether 696: the keyfile contains a public or a secret key. You may specify a 697: different key ring file name, with the extension defaulting to 698: ".pgp". 699: 700: If the key is already on your key ring, PGP will not add it again. 701: All of the keys in the keyfile are added to the keyring, except for 702: duplicates. 703: 704: Later in the manual, we will explain the concept of certifying keys 705: with signatures. If the key being added has attached signatures 706: certifying it, the signatures are added with the key. If the key is 707: already on your key ring, PGP just merges in any new certifying 708: signatures for that key that you don't already have on your key ring. 709: 710: PGP was originally designed for handling small personal keyrings. If 711: you want to handle really big keyrings, see the section on "Handling 712: Large Public Keyrings" in the Special Topics volume. 713: 714: 715: 716: Removing a Key or User ID from Your Key Ring 717: -------------------------------------------- 718: 719: To remove a key or a user ID from your public key ring: 720: 721: pgp -kr userid [keyring] 722: 723: This searches for the specified user ID in your key ring, and removes 724: it if it finds a match. Remember that any fragment of the user ID 725: will suffice for a match. The optional keyring file name is assumed 726: to be literally "pubring.pgp". It can be omitted, or you can specify 727: "secring.pgp" if you want to remove a secret key. You may specify a 728: different key ring file name. The default key ring extension is 729: ".pgp". 730: 731: If more than one user ID exists for this key, you will be asked if 732: you want to remove only the user ID you specified, while leaving the 733: key and its other user IDs intact. 734: 735: 736: 737: Extracting (copying) a Key from Your Key Ring 738: --------------------------------------------- 739: 740: To extract (copy) a key from your public or secret key ring: 741: 742: pgp -kx userid keyfile [keyring] 743: 744: This non-destructively copies the key specified by the user ID from 745: your public or secret key ring to the specified key file. This is 746: particularly useful if you want to give a copy of your public key to 747: someone else. 748: 749: If the key has any certifying signatures attached to it on your key 750: ring, they are copied off along with the key. 751: 752: If you want the extracted key represented in printable ASCII 753: characters suitable for email purposes, use the -kxa options. 754: 755: 756: 757: Viewing the Contents of Your Key Ring 758: ------------------------------------- 759: 760: To view the contents of your public key ring: 761: 762: pgp -kv[v] [userid] [keyring] 763: 764: This lists any keys in the key ring that match the specified user ID 765: substring. If you omit the user ID, all of the keys in the key ring 766: are listed. The optional keyring file name is assumed to be 767: "pubring.pgp". It can be omitted, or you can specify "secring.pgp" 768: if you want to list secret keys. If you want to specify a different 769: key ring file name, you can. The default key ring extension is 770: ".pgp". 771: 772: Later in the manual, we will explain the concept of certifying keys 773: with signatures. To see all the certifying signatures attached to 774: each key, use the -kvv option: 775: 776: pgp -kvv [userid] [keyring] 777: 778: If you want to specify a particular key ring file name, but want to 779: see all the keys in it, try this alternative approach: 780: 781: pgp keyfile 782: 783: With no command options specified, PGP lists all the keys in 784: keyfile.pgp, and also attempts to add them to your key ring if they 785: are not already on your key ring. 786: 787: 788: 789: How to Protect Public Keys from Tampering 790: ----------------------------------------- 791: 792: In a public key cryptosystem, you don't have to protect public keys 793: from exposure. In fact, it's better if they are widely disseminated. 794: But it is important to protect public keys from tampering, to make 795: sure that a public key really belongs to whom it appears to belong to. 796: This may be the most important vulnerability of a public-key 797: cryptosystem. Let's first look at a potential disaster, then at how 798: to safely avoid it with PGP. 799: 800: Suppose you wanted to send a private message to Alice. You download 801: Alice's public key certificate from an electronic bulletin board 802: system (BBS). You encrypt your letter to Alice with this public key 803: and send it to her through the BBS's E-mail facility. 804: 805: Unfortunately, unbeknownst to you or Alice, another user named 806: Charlie has infiltrated the BBS and generated a public key of his own 807: with Alice's user ID attached to it. He covertly substitutes his 808: bogus key in place of Alice's real public key. You unwittingly use 809: this bogus key belonging to Charlie instead of Alice's public key. 810: All looks normal because this bogus key has Alice's user ID. Now 811: Charlie can decipher the message intended for Alice because he has 812: the matching secret key. He may even re-encrypt the deciphered 813: message with Alice's real public key and send it on to her so that no 814: one suspects any wrongdoing. Furthermore, he can even make 815: apparently good signatures from Alice with this secret key because 816: everyone will use the bogus public key to check Alice's signatures. 817: 818: The only way to prevent this disaster is to prevent anyone from 819: tampering with public keys. If you got Alice's public key directly 820: from Alice, this is no problem. But that may be difficult if Alice 821: is a thousand miles away, or is currently unreachable. 822: 823: Perhaps you could get Alice's public key from a mutual trusted friend 824: David who knows he has a good copy of Alice's public key. David 825: could sign Alice's public key, vouching for the integrity of Alice's 826: public key. David would create this signature with his own secret 827: key. 828: 829: This would create a signed public key certificate, and would show 830: that Alice's key had not been tampered with. This requires you have a 831: known good copy of David's public key to check his signature. Perhaps 832: David could provide Alice with a signed copy of your public key also. 833: David is thus serving as an "introducer" between you and Alice. 834: 835: This signed public key certificate for Alice could be uploaded by 836: David or Alice to the BBS, and you could download it later. You 837: could then check the signature via David's public key and thus be 838: assured that this is really Alice's public key. No impostor can fool 839: you into accepting his own bogus key as Alice's because no one else 840: can forge signatures made by David. 841: 842: A widely trusted person could even specialize in providing this 843: service of "introducing" users to each other by providing signatures 844: for their public key certificates. This trusted person could be 845: regarded as a "key server", or as a "Certifying Authority". Any 846: public key certificates bearing the key server's signature could be 847: trusted as truly belonging to whom they appear to belong to. All 848: users who wanted to participate would need a known good copy of just 849: the key server's public key, so that the key server's signatures 850: could be verified. 851: 852: A trusted centralized key server or Certifying Authority is 853: especially appropriate for large impersonal centrally-controlled 854: corporate or government institutions. Some institutional 855: environments use hierarchies of Certifying Authorities. 856: 857: For more decentralized grassroots "guerrilla style" environments, 858: allowing all users to act as a trusted introducers for their friends 859: would probably work better than a centralized key server. PGP tends 860: to emphasize this organic decentralized non-institutional approach. 861: It better reflects the natural way humans interact on a personal 862: social level, and allows people to better choose who they can trust 863: for key management. 864: 865: This whole business of protecting public keys from tampering is the 866: single most difficult problem in practical public key applications. 867: It is the Achilles' heel of public key cryptography, and a lot of 868: software complexity is tied up in solving this one problem. 869: 870: You should use a public key only after you are sure that it is a good 871: public key that has not been tampered with, and actually belongs to 872: the person it claims to. You can be sure of this if you got this 873: public key certificate directly from its owner, or if it bears the 874: signature of someone else that you trust, from whom you already have 875: a good public key. Also, the user ID should have the full name of 876: the key's owner, not just her first name. 877: 878: No matter how tempted you are-- and you will be tempted-- never, 879: NEVER give in to expediency and trust a public key you downloaded 880: from a bulletin board, unless it is signed by someone you trust. 881: That uncertified public key could have been tampered with by anyone, 882: maybe even by the system administrator of the bulletin board. 883: 884: If you are asked to sign someone else's public key certificate, make 885: certain that it really belongs to that person named in the user ID of 886: that public key certificate. This is because your signature on her 887: public key certificate is a promise by you that this public key 888: really belongs to her. Other people who trust you will accept her 889: public key because it bears your signature. It may be ill-advised to 890: rely on hearsay-- don't sign her public key unless you have 891: independent firsthand knowledge that it really belongs to her. 892: Preferably, you should sign it only if you got it directly from her. 893: 894: In order to sign a public key, you must be far more certain of that 895: key's ownership than if you merely want to use that key to encrypt a 896: message. To be convinced of a key's validity enough to use it, 897: certifying signatures from trusted introducers should suffice. But 898: to sign a key yourself, you should require your own independent 899: firsthand knowledge of who owns that key. Perhaps you could call the 900: key's owner on the phone and read the key file to her to get her to 901: confirm that the key you have really is her key-- and make sure you 902: really are talking to the right person. See the section called 903: "Verifying a Public Key Over the Phone" in the Special Topics volume 904: for further details. 905: 906: Bear in mind that your signature on a public key certificate does not 907: vouch for the integrity of that person, but only vouches for the 908: integrity (the ownership) of that person's public key. You aren't 909: risking your credibility by signing the public key of a sociopath, if 910: you were completely confident that the key really belonged to him. 911: Other people would accept that key as belonging to him because you 912: signed it (assuming they trust you), but they wouldn't trust that 913: key's owner. Trusting a key is not the same as trusting the key's 914: owner. 915: 916: Trust is not necessarily transferable; I have a friend who I trust 917: not to lie. He's a gullible person who trusts the President not to 918: lie. That doesn't mean I trust the President not to lie. This is 919: just common sense. If I trust Alice's signature on a key, and Alice 920: trusts Charlie's signature on a key, that does not imply that I have 921: to trust Charlie's signature on a key. 922: 923: It would be a good idea to keep your own public key on hand with a 924: collection of certifying signatures attached from a variety of 925: "introducers", in the hopes that most people will trust at least one 926: of the introducers who vouch for your own public key's validity. 927: You could post your key with its attached collection of certifying 928: signatures on various electronic bulletin boards. If you sign 929: someone else's public key, return it to them with your signature so 930: that they can add it to their own collection of credentials for their 931: own public key. 932: 933: PGP keeps track of which keys on your public key ring are properly 934: certified with signatures from introducers that you trust. All you 935: have to do is tell PGP which people you trust as introducers, and 936: certify their keys yourself with your own ultimately trusted key. 937: PGP can take it from there, automatically validating any other keys 938: that have been signed by your designated introducers. And of course 939: you may directly sign more keys yourself. More on this later. 940: 941: Make sure no one else can tamper with your own public key ring. 942: Checking a new signed public key certificate must ultimately depend 943: on the integrity of the trusted public keys that are already on your 944: own public key ring. Maintain physical control of your public key 945: ring, preferably on your own personal computer rather than on a 946: remote timesharing system, just as you would do for your secret key. 947: This is to protect it from tampering, not from disclosure. Keep a 948: trusted backup copy of your public key ring and your secret key ring 949: on write-protected media. 950: 951: Since your own trusted public key is used as a final authority to 952: directly or indirectly certify all the other keys on your key ring, 953: it is the most important key to protect from tampering. To detect 954: any tampering of your own ultimately-trusted public key, PGP can be 955: set up to automatically compare your public key against a backup copy 956: on write-protected media. For details, see the description of the 957: "-kc" key ring check command in the Special Topics volume. 958: 959: PGP generally assumes you will maintain physical security over your 960: system and your key rings, as well as your copy of PGP itself. If an 961: intruder can tamper with your disk, then in theory he can tamper with 962: PGP itself, rendering moot the safeguards PGP may have to detect 963: tampering with keys. 964: 965: One somewhat complicated way to protect your own whole public key ring 966: from tampering is to sign the whole ring with your own secret key. 967: You could do this by making a detached signature certificate of the 968: public key ring, by signing the ring with the "-sb" options (see the 969: section called "Separating Signatures from Messages" in the PGP 970: User's Guide, Special Topics volume). Unfortunately, you would still 971: have to keep a separate trusted copy of your own public key around to 972: check the signature you made. You couldn't rely on your own public 973: key stored on your public key ring to check the signature you made 974: for the whole ring, because that is part of what you're trying to 975: check. 976: 977: 978: 979: How Does PGP Keep Track of Which Keys are Valid? 980: ------------------------------------------------ 981: 982: Before you read this section, be sure to read the above section on 983: "How to Protect Public Keys from Tampering". 984: 985: PGP keeps track of which keys on your public key ring are properly 986: certified with signatures from introducers that you trust. All you 987: have to do is tell PGP which people you trust as introducers, and 988: certify their keys yourself with your own ultimately trusted key. 989: PGP can take it from there, automatically validating any other keys 990: that have been signed by your designated introducers. And of course 991: you may directly sign more keys yourself. 992: 993: There are two entirely separate criteria PGP uses to judge a public 994: key's usefulness-- don't get them confused: 995: 996: 1) Does the key actually belong to whom it appears to belong? 997: In other words, has it been certified with a trusted signature? 998: 2) Does it belong to someone you can trust to certify other keys? 999: 1000: PGP can calculate the answer to the first question. To answer the 1001: second question, PGP must be explicitly told by you, the user. When 1002: you supply the answer to question 2, PGP can then calculate the 1003: answer to question 1 for other keys signed by the introducer you 1004: designated as trusted. 1005: 1006: Keys that have been certified by a trusted introducer are deemed 1007: valid by PGP. The keys belonging to trusted introducers must 1008: themselves be certified either by you or by other trusted 1009: introducers. 1010: 1011: PGP also allows for the possibility of you having several shades of 1012: trust for people to act as introducers. Your trust for a key's owner 1013: to act as an introducer does not just reflect your estimation of 1014: their personal integrity-- it should also reflect how competent you 1015: think they are at understanding key management and using good 1016: judgment in signing keys. You can designate a person to PGP as 1017: unknown, untrusted, marginally trusted, or completely trusted to 1018: certify other public keys. This trust information is stored on your 1019: key ring with their key, but when you tell PGP to copy a key off your 1020: key ring, PGP will not copy the trust information along with the key, 1021: because your private opinions on trust are regarded as confidential. 1022: 1023: When PGP is calculating the validity of a public key, it examines the 1024: trust level of all the attached certifying signatures. It computes a 1025: weighted score of validity-- two marginally trusted signatures are 1026: deemed as credible as one fully trusted signature. PGP's skepticism 1027: is adjustable-- for example, you may tune PGP to require two fully 1028: trusted signatures or three marginally trusted signatures to judge a 1029: key as valid. 1030: 1031: Your own key is "axiomatically" valid to PGP, needing no introducer's 1032: signature to prove its validity. PGP knows which public keys are 1033: yours, by looking for the corresponding secret keys on the secret 1034: key ring. PGP also assumes you ultimately trust yourself to certify 1035: other keys. 1036: 1037: As time goes on, you will accumulate keys from other people that you 1038: may want to designate as trusted introducers. Everyone else will 1039: each choose their own trusted introducers. And everyone will 1040: gradually accumulate and distribute with their key a collection of 1041: certifying signatures from other people, with the expectation that 1042: anyone receiving it will trust at least one or two of the signatures. 1043: This will cause the emergence of a decentralized fault-tolerant web 1044: of confidence for all public keys. 1045: 1046: This unique grass-roots approach contrasts sharply with Government 1047: standard public key management schemes, such as Internet Privacy 1048: Enhanced Mail (PEM), which are based on centralized control and 1049: mandatory centralized trust. The standard schemes rely on a 1050: hierarchy of Certifying Authorities who dictate who you must trust. 1051: PGP's decentralized probabilistic method for determining public key 1052: legitimacy is the centerpiece of its key management architecture. 1053: PGP lets you alone choose who you trust, putting you at the top of 1054: your own private certification pyramid. PGP is for people who prefer 1055: to pack their own parachutes. 1056: 1057: 1058: 1059: How to Protect Secret Keys from Disclosure 1060: ------------------------------------------ 1061: 1062: Protect your own secret key and your pass phrase carefully. Really, 1063: really carefully. If your secret key is ever compromised, you'd 1064: better get the word out quickly to all interested parties (good luck) 1065: before someone else uses it to make signatures in your name. For 1066: example, they could use it to sign bogus public key certificates, 1067: which could create problems for many people, especially if your 1068: signature is widely trusted. And of course, a compromise of your own 1069: secret key could expose all messages sent to you. 1070: 1071: To protect your secret key, you can start by always keeping physical 1072: control of your secret key. Keeping it on your personal computer at 1073: home is OK, or keep it in your notebook computer that you can carry 1074: with you. If you must use an office computer that you don't always 1075: have physical control of, then keep your public and secret key rings 1076: on a write-protected removable floppy disk, and don't leave it behind 1077: when you leave the office. It wouldn't be a good idea to allow your 1078: secret key to reside on a remote timesharing computer, such as a 1079: remote dial-in Unix system. Someone could eavesdrop on your modem 1080: line and capture your pass phrase, and then obtain your actual secret 1081: key from the remote system. You should only use your secret key on a 1082: machine that you have physical control over. 1083: 1084: Don't store your pass phrase anywhere on the computer that has your 1085: secret key file. Storing both the secret key and the pass phrase on 1086: the same computer is as dangerous as keeping your PIN in the same 1087: wallet as your Automatic Teller Machine bank card. You don't want 1088: somebody to get their hands on your disk containing both the pass 1089: phrase and the secret key file. It would be most secure if you just 1090: memorize your pass phrase and don't store it anywhere but your brain. 1091: If you feel you must write down your pass phrase, keep it well 1092: protected, perhaps even more well protected than the secret key file. 1093: 1094: And keep backup copies of your secret key ring-- remember, you have 1095: the only copy of your secret key, and losing it will render useless 1096: all the copies of your public key that you have spread throughout the 1097: world. 1098: 1099: The decentralized non-institutional approach PGP uses to manage 1100: public keys has its benefits, but unfortunately this also means we 1101: can't rely on a single centralized list of which keys have been 1102: compromised. This makes it a bit harder to contain the damage of a 1103: secret key compromise. You just have to spread the word and hope 1104: everyone hears about it. 1105: 1106: If the worst case happens-- your secret key and pass phrase are both 1107: compromised (hopefully you will find this out somehow)-- you will 1108: have to issue a "key compromise" certificate. This kind of 1109: certificate is used to warn other people to stop using your public 1110: key. You can use PGP to create such a certificate by using the "-kd" 1111: command. Then you must somehow send this compromise certificate to 1112: everyone else on the planet, or at least to all your friends and 1113: their friends, et cetera. Their own PGP software will install this 1114: key compromise certificate on their public key rings and will 1115: automatically prevent them from accidentally using your public key 1116: ever again. You can then generate a new secret/public key pair and 1117: publish the new public key. You could send out one package containing 1118: both your new public key and the key compromise certificate for your 1119: old key. 1120: 1121: 1122: 1123: Revoking a Public Key 1124: --------------------- 1125: 1126: Suppose your secret key and your pass phrase are somehow both 1127: compromised. You have to get the word out to the rest of the world, 1128: so that they will all stop using your public key. To do this, you 1129: will have to issue a "key compromise", or "key revocation" certificate 1130: to revoke your public key. 1131: 1132: To generate a certificate to revoke your own key, use the -kd 1133: command: 1134: 1135: pgp -kd your_userid 1136: 1137: This certificate bears your signature, made with the same key you are 1138: revoking. You should widely disseminate this key revocation 1139: certificate as soon as possible. Other people who receive it can add 1140: it to their public key rings, and their PGP software then 1141: automatically prevents them from accidentally using your old public 1142: key ever again. You can then generate a new secret/public key pair 1143: and publish the new public key. 1144: 1145: You may choose to revoke your key for some other reason than the 1146: compromise of a secret key. If so, you may still use the same 1147: mechanism to revoke it. 1148: 1149: 1150: 1151: What If You Lose Your Secret Key? 1152: --------------------------------- 1153: 1154: Normally, if you want to revoke your own secret key, you can use the 1155: "-kd" command to issue a revocation certificate, signed with your own 1156: secret key (see "Revoking a Public Key"). 1157: 1158: But what can you do if you lose your secret key, or if your secret 1159: key is destroyed? You can't revoke it yourself, because you must use 1160: your own secret key to revoke it, and you don't have it anymore. A 1161: future version of PGP will offer a more secure means of revoking keys 1162: in these circumstances, allowing trusted introducers to certify that 1163: a public key has been revoked. But for now, you will have to get the 1164: word out through whatever informal means you can, asking users to 1165: "disable" your public key on their own individual public key rings. 1166: 1167: Other users may disable your public key on their own public key rings 1168: by using the "-kd" command. If a user ID is specified that does not 1169: correspond to a secret key on the secret key ring, the -kd command 1170: will look for that user ID on the public key ring, and mark that 1171: public key as disabled. A disabled key may not be used to encrypt 1172: any messages, and may not be extracted from the key ring with the -kx 1173: command. It can still be used to check signatures, but a warning is 1174: displayed. And if the user tries to add the same key again to his 1175: key ring, it will not work because the disabled key is already on the 1176: key ring. These combined features will help curtail the further 1177: spread of a disabled key. 1178: 1179: If the specified public key is already disabled, the -kd command will 1180: ask if you want the key reenabled. 1181: 1182: 1183: Advanced Topics 1184: =============== 1185: 1186: Most of the "Advanced Topics" are covered in the "PGP User's Guide, 1187: Volume II: Special Topics". But here are a few topics that bear 1188: mentioning here. 1189: 1190: 1191: Sending Ciphertext Through E-mail Channels: Radix-64 Format 1192: ----------------------------------------------------------- 1193: 1194: Many electronic mail systems only allow messages made of ASCII text, 1195: not the 8-bit raw binary data that ciphertext is made of. To get 1196: around this problem, PGP supports ASCII radix-64 format for 1197: ciphertext messages, similar to the Internet Privacy-Enhanced Mail 1198: (PEM) format, as well as the Internet MIME format. This special 1199: format represents binary data by using only printable ASCII 1200: characters, so it is useful for transmitting binary encrypted data 1201: through 7-bit channels or for sending binary encrypted data as normal 1202: E-mail text. This format acts as a form of "transport armor", 1203: protecting it against corruption as it travels through intersystem 1204: gateways on Internet. PGP also appends a CRC to detect transmission 1205: errors. 1206: 1207: Radix-64 format converts the plaintext by expanding groups of 3 1208: binary 8-bit bytes into 4 printable ASCII characters, so the file 1209: grows by about 33%. But this expansion isn't so bad when you 1210: consider that the file probably was compressed more than that by PGP 1211: before it was encrypted. 1212: 1213: To produce a ciphertext file in ASCII radix-64 format, just add the 1214: "a" option when encrypting or signing a message, like so: 1215: 1216: pgp -esa message.txt her_userid 1217: 1218: This example produces a ciphertext file called "message.asc" that 1219: contains data in a PEM-like ASCII radix-64 format. This file can be 1220: easily uploaded into a text editor through 7-bit channels for 1221: transmission as normal E-mail on Internet or any other E-mail 1222: network. 1223: 1224: Decrypting the radix-64 transport-armored message is no different than 1225: a normal decrypt. For example: 1226: 1227: pgp message 1228: 1229: PGP automatically looks for the ASCII file "message.asc" before it 1230: looks for the binary file "message.pgp". It recognizes that the file 1231: is in radix-64 format and converts it back to binary before 1232: processing as it normally does, producing as a by-product a ".pgp" 1233: ciphertext file in binary form. The final output file is in normal 1234: plaintext form, just as it was in the original file "message.txt". 1235: 1236: Most Internet E-mail facilities prohibit sending messages that are 1237: more than 50000 bytes long. Longer messages must be broken into 1238: smaller chunks that can be mailed separately. If your encrypted 1239: message is very large, and you requested radix-64 format, PGP 1240: automatically breaks it up into chunks that are each small enough to 1241: send via E-mail. The chunks are put into files named with extensions 1242: ".as1", ".as2", ".as3", etc. The recipient must concatenate these 1243: separate files back together in their proper order into one big file 1244: before decrypting it. While decrypting, PGP ignores any extraneous 1245: text in mail headers that are not enclosed in the radix-64 message 1246: blocks. 1247: 1248: If you want to send a public key to someone else in radix-64 format, 1249: just add the -a option while extracting the key from your keyring. 1250: 1251: If you forgot to use the -a option when you made a ciphertext file or 1252: extracted a key, you may still directly convert the binary file into 1253: radix-64 format by simply using the -a option alone, without any 1254: encryption specified. PGP converts it to a ".asc" file. 1255: 1256: If you sign a plaintext file without encrypting it, PGP will normally 1257: compress it after signing it, rendering it unreadable to the casual 1258: human observer. This is a suitable way of storing signed files in 1259: archival applications. But if you want to send the signed message as 1260: E-mail, and the the original plaintext message is in text (not 1261: binary) form, there is a way to send it through an E-mail channel in 1262: such a way that the plaintext does not get compressed, and the ASCII 1263: armor is applied only to the binary signature certificate, but not to 1264: the plaintext message. This makes it possible for the recipient to 1265: read the signed message with human eyes, without the aid of PGP. Of 1266: course, PGP is still needed to actually check the signature. For 1267: further information on this feature, see the explanation of the 1268: CLEARSIG parameter in the section "Setting Configuration Parameters: 1269: CONFIG.TXT" in the Special Topics volume. 1270: 1271: 1272: Environmental Variable for Path Name 1273: ------------------------------------ 1274: 1275: PGP uses several special files for its purposes, such as your 1276: standard key ring files "pubring.pgp" and "secring.pgp", the random 1277: number seed file "randseed.bin", the PGP configuration file 1278: "config.txt", and the foreign language string translation file 1279: "language.txt". These special files can be kept in any directory, by 1280: setting the environmental variable "PGPPATH" to the desired pathname. 1281: For example, on MSDOS, the shell command: 1282: 1283: SET PGPPATH=C:\PGP 1284: 1285: makes PGP assume that your public key ring filename is 1286: "C:\PGP\pubring.pgp". Assuming, of course, that this directory 1287: exists. Use your favorite text editor to modify your MSDOS 1288: AUTOEXEC.BAT file to automatically set up this variable whenever you 1289: start up your system. If PGPPATH remains undefined, these special 1290: files are assumed to be in the current directory. 1291: 1292: 1293: 1294: Setting Configuration Parameters: CONFIG.TXT 1295: -------------------------------------------- 1296: 1297: PGP has a number of user-settable parameters that can be defined in a 1298: special configuration text file called "config.txt", in the directory 1299: pointed to by the shell environmental variable PGPPATH. Having a 1300: configuration file enables the user to define various flags and 1301: parameters for PGP without the burden of having to always define 1302: these parameters in the PGP command line. 1303: 1304: With these configuration parameters, for example, you can control 1305: where PGP stores its temporary scratch files, or you can select what 1306: foreign language PGP will use to display its diagnostics messages and 1307: user prompts, or you can adjust PGP's level of skepticism in 1308: determining a key's validity based on the number of certifying 1309: signatures it has. 1310: 1311: For more details on setting these configuration parameters, see the 1312: appropriate section of the PGP User's Guide, Special Topics volume. 1313: 1314: 1315: 1316: Vulnerabilities 1317: --------------- 1318: 1319: No data security system is impenetrable. PGP can be circumvented in 1320: a variety of ways. Potential vulnerabilities you should be aware of 1321: include compromising your pass phrase or secret key, public key 1322: tampering, files that you deleted but are still somewhere on the 1323: disk, viruses and Trojan horses, breaches in your physical security, 1324: electromagnetic emissions, exposure on multi-user systems, traffic 1325: analysis, and perhaps even direct cryptanalysis. 1326: 1327: For a detailed discussion of these issues, see the "Vulnerabilities" 1328: section in the PGP User's Guide, Special Topics volume. 1329: 1330: 1331: Beware of Snake Oil 1332: =================== 1333: 1334: When examining a cryptographic software package, the question always 1335: remains, why should you trust this product? Even if you examined the 1336: source code yourself, not everyone has the cryptographic experience 1337: to judge the security. Even if you are an experienced cryptographer, 1338: subtle weaknesses in the algorithms could still elude you. 1339: 1340: When I was in college in the early seventies, I devised what I 1341: believed was a brilliant encryption scheme. A simple pseudorandom 1342: number stream was added to the plaintext stream to create 1343: ciphertext. This would seemingly thwart any frequency analysis of 1344: the ciphertext, and would be uncrackable even to the most resourceful 1345: Government intelligence agencies. I felt so smug about my 1346: achievement. So cock-sure. 1347: 1348: Years later, I discovered this same scheme in several introductory 1349: cryptography texts and tutorial papers. How nice. Other 1350: cryptographers had thought of the same scheme. Unfortunately, the 1351: scheme was presented as a simple homework assignment on how to use 1352: elementary cryptanalytic techniques to trivially crack it. So much 1353: for my brilliant scheme. 1354: 1355: From this humbling experience I learned how easy it is to fall into a 1356: false sense of security when devising an encryption algorithm. Most 1357: people don't realize how fiendishly difficult it is to devise an 1358: encryption algorithm that can withstand a prolonged and determined 1359: attack by a resourceful opponent. Many mainstream software engineers 1360: have developed equally naive encryption schemes (often even the very 1361: same encryption scheme), and some of them have been incorporated into 1362: commercial encryption software packages and sold for good money to 1363: thousands of unsuspecting users. 1364: 1365: This is like selling automotive seat belts that look good and feel 1366: good, but snap open in even the slowest crash test. Depending on 1367: them may be worse than not wearing seat belts at all. No one 1368: suspects they are bad until a real crash. Depending on weak 1369: cryptographic software may cause you to unknowingly place sensitive 1370: information at risk. You might not otherwise have done so if you had 1371: no cryptographic software at all. Perhaps you may never even 1372: discover your data has been compromised. 1373: 1374: Sometimes commercial packages use the Federal Data Encryption 1.1.1.5 ! root 1375: Standard (DES), a fairly good conventional algorithm recommended by ! 1376: the Government for commercial use (but not for classified ! 1377: information, oddly enough-- hmmm). There are several "modes of ! 1378: operation" the DES can use, some of them better than others. The ! 1379: Government specifically recommends not using the weakest simplest ! 1380: mode for messages, the Electronic Codebook (ECB) mode. But they do ! 1381: recommend the stronger and more complex Cipher Feedback (CFB) or ! 1382: Cipher Block Chaining (CBC) modes. 1.1.1.4 root 1383: 1384: Unfortunately, most of the commercial encryption packages I've looked 1385: at use ECB mode. When I've talked to the authors of a number of 1386: these implementations, they say they've never heard of CBC or CFB 1387: modes, and didn't know anything about the weaknesses of ECB mode. 1388: The very fact that they haven't even learned enough cryptography to 1.1.1.5 ! root 1389: know these elementary concepts is not reassuring. And they sometimes ! 1390: manage their DES keys in inappropriate or insecure ways. Also, these ! 1391: same software packages often include a second faster encryption ! 1392: algorithm that can be used instead of the slower DES. The author of ! 1393: the package often thinks his proprietary faster algorithm is as ! 1394: secure as the DES, but after questioning him I usually discover that ! 1395: it's just a variation of my own brilliant scheme from college days. ! 1396: Or maybe he won't even reveal how his proprietary encryption scheme ! 1397: works, but assures me it's a brilliant scheme and I should trust it. ! 1398: I'm sure he believes that his algorithm is brilliant, but how can I ! 1399: know that without seeing it? ! 1400: ! 1401: In all fairness I must point out that in most cases these terribly ! 1402: weak products do not come from companies that specialize in ! 1403: cryptographic technology. ! 1404: ! 1405: Even the really good software packages, that use the DES in the ! 1406: correct modes of operation, still have problems. Standard DES uses a ! 1407: 56-bit key, which is too small by today's standards, and may now be ! 1408: easily broken by exhaustive key searches on special high-speed ! 1409: machines. The DES has reached the end of its useful life, and so has ! 1410: any software package that relies on it. 1.1.1.4 root 1411: 1412: There is a company called AccessData (87 East 600 South, Orem, Utah 1413: 84058, phone 1-800-658-5199) that sells a package for $185 that 1414: cracks the built-in encryption schemes used by WordPerfect, Lotus 1415: 1-2-3, MS Excel, Symphony, Quattro Pro, Paradox, and MS Word 2.0. It 1416: doesn't simply guess passwords-- it does real cryptanalysis. Some 1417: people buy it when they forget their password for their own files. 1418: Law enforcement agencies buy it too, so they can read files they 1419: seize. I talked to Eric Thompson, the author, and he said his 1420: program only takes a split second to crack them, but he put in some 1421: delay loops to slow it down so it doesn't look so easy to the 1422: customer. He also told me that the password encryption feature of 1423: PKZIP files can often be easily broken, and that his law enforcement 1424: customers already have that service regularly provided to them from 1425: another vendor. 1426: 1427: In some ways, cryptography is like pharmaceuticals. Its integrity 1428: may be absolutely crucial. Bad penicillin looks the same as good 1429: penicillin. You can tell if your spreadsheet software is wrong, but 1430: how do you tell if your cryptography package is weak? The ciphertext 1431: produced by a weak encryption algorithm looks as good as ciphertext 1432: produced by a strong encryption algorithm. There's a lot of snake 1433: oil out there. A lot of quack cures. Unlike the patent medicine 1434: hucksters of old, these software implementors usually don't even know 1435: their stuff is snake oil. They may be good software engineers, but 1436: they usually haven't even read any of the academic literature in 1437: cryptography. But they think they can write good cryptographic 1438: software. And why not? After all, it seems intuitively easy to do 1439: so. And their software seems to work okay. 1440: 1441: Anyone who thinks they have devised an unbreakable encryption scheme 1.1.1.5 ! root 1442: either is an incredibly rare genius or is naive and inexperienced. ! 1443: Unfortunately, I sometimes have to deal with would-be cryptographers ! 1444: who want to make "improvements" to PGP by adding encryption ! 1445: algorithms of their own design. 1.1.1.4 root 1446: 1447: I remember a conversation with Brian Snow, a highly placed senior 1448: cryptographer with the NSA. He said he would never trust an 1449: encryption algorithm designed by someone who had not "earned their 1450: bones" by first spending a lot of time cracking codes. That did make 1451: a lot of sense. I observed that practically no one in the commercial 1452: world of cryptography qualified under this criterion. "Yes", he said 1453: with a self assured smile, "And that makes our job at NSA so much 1454: easier." A chilling thought. I didn't qualify either. 1455: 1456: The Government has peddled snake oil too. After World War II, the US 1457: sold German Enigma ciphering machines to third world governments. 1458: But they didn't tell them that the Allies cracked the Enigma code 1459: during the war, a fact that remained classified for many years. Even 1460: today many Unix systems worldwide use the Enigma cipher for file 1461: encryption, in part because the Government has created legal 1462: obstacles against using better algorithms. They even tried to 1463: prevent the initial publication of the RSA algorithm in 1977. And 1464: they have squashed essentially all commercial efforts to develop 1465: effective secure telephones for the general public. 1466: 1467: The principal job of the US Government's National Security Agency is 1468: to gather intelligence, principally by covertly tapping into people's 1469: private communications (see James Bamford's book, "The Puzzle 1470: Palace"). The NSA has amassed considerable skill and resources for 1471: cracking codes. When people can't get good cryptography to protect 1472: themselves, it makes NSA's job much easier. NSA also has the 1473: responsibility of approving and recommending encryption algorithms. 1474: Some critics charge that this is a conflict of interest, like putting 1475: the fox in charge of guarding the hen house. NSA has been pushing a 1476: conventional encryption algorithm that they designed, and they won't 1477: tell anybody how it works because that's classified. They want 1478: others to trust it and use it. But any cryptographer can tell you 1479: that a well-designed encryption algorithm does not have to be 1480: classified to remain secure. Only the keys should need protection. 1481: How does anyone else really know if NSA's classified algorithm is 1482: secure? It's not that hard for NSA to design an encryption algorithm 1483: that only they can crack, if no one else can review the algorithm. 1484: Are they deliberately selling snake oil? 1485: 1.1.1.5 ! root 1486: There are three main factors that have undermined the quality of ! 1487: commercial cryptographic software in the US. The first is the ! 1488: virtually universal lack of competence of implementors of commercial ! 1489: encryption software (although this is starting to change since the ! 1490: publication of PGP). Every software engineer fancies himself a ! 1491: cryptographer, which has led to the proliferation of really bad ! 1492: crypto software. The second is the NSA deliberately and ! 1493: systematically suppressing all the good commercial encryption ! 1494: technology, by legal intimidation and economic pressure. Part of ! 1495: this pressure is brought to bear by stringent export controls on ! 1496: encryption software which, by the economics of software marketing, ! 1497: has the net effect of suppressing domestic encryption software. The ! 1498: other principle method of suppression comes from the granting all the ! 1499: software patents for all the public key encryption algorithms to a ! 1500: single company, affording a single choke point to suppress the spread ! 1501: of this technology. The net effect of all this is that before PGP ! 1502: was published, there was almost no highly secure general purpose ! 1503: encryption software available in the US. ! 1504: 1.1.1.4 root 1505: I'm not as certain about the security of PGP as I once was about my 1506: brilliant encryption software from college. If I were, that would be 1507: a bad sign. But I'm pretty sure that PGP does not contain any 1.1.1.5 ! root 1508: glaring weaknesses (although it may contain bugs). The crypto ! 1509: algorithms were developed by people at high levels of civilian ! 1510: cryptographic academia, and have been individually subject to ! 1511: extensive peer review. Source code is available to facilitate peer ! 1512: review of PGP and to help dispel the fears of some users. It's ! 1513: reasonably well researched, and has been years in the making. And I ! 1514: don't work for the NSA. I hope it doesn't require too large a "leap ! 1515: of faith" to trust the security of PGP. ! 1516: ! 1517: ! 1518: Notice to Macintosh Users ! 1519: ========================= ! 1520: ! 1521: PGP was originally developed for MSDOS and Unix machines. There is ! 1522: also an Apple Macintosh version of PGP. This manual is written for ! 1523: the MSDOS/Unix versions of PGP, which use a command-line interface ! 1524: for all the PGP functions. On the Mac, all the PGP functions are ! 1525: accessed through pull-down menus and dialog boxes. There is also ! 1526: on-line help on the Mac for how to use MacPGP, and there should be ! 1527: some Mac-specific user documentation included in the MacPGP release ! 1528: package, in addition to this manual. ! 1529: ! 1530: Almost all good Mac software applications are written from scratch ! 1531: for the Mac, not simply ported there from other operating systems. ! 1532: Unfortunately, the current Mac version of PGP was not designed for ! 1533: the Mac from scratch. It was ported from the MSDOS/Unix version to ! 1534: the Mac by Zbigniew Fiedorwicz. Since the MSDOS/Unix version of PGP ! 1535: was not designed for a GUI (graphical user interface), porting to the ! 1536: Mac was not an easy task, and many bugs still remain. An all-new ! 1537: version of PGP is under development, designed for easy adaptation to ! 1538: a GUI. A new Mac version will be developed from this new PGP source ! 1539: code. It will be more Mac-like, and more reliable. Despite the bugs ! 1540: in the current version of MacPGP, it is important to note that if ! 1541: Zbigniew had waited for this all-new version of PGP to be developed ! 1542: before he ported PGP to the Mac, the world would have been deprived ! 1543: of a Mac version of PGP for far too long. 1.1.1.4 root 1544: 1545: 1546: PGP Quick Reference 1547: =================== 1548: 1549: Here's a quick summary of PGP commands. 1550: 1551: 1552: To encrypt a plaintext file with the recipient's public key: 1553: pgp -e textfile her_userid 1554: 1555: To sign a plaintext file with your secret key: 1556: pgp -s textfile [-u your_userid] 1557: 1558: To sign a plaintext ASCII text file with your secret key, producing a 1559: signed plaintext message suitable for sending via E-mail: 1560: pgp -sta textfile [-u your_userid] 1561: 1562: To sign a plaintext file with your secret key, and then encrypt it 1563: with the recipient's public key: 1564: pgp -es textfile her_userid [-u your_userid] 1565: 1566: To encrypt a plaintext file with just conventional cryptography, type: 1567: pgp -c textfile 1568: 1569: To decrypt an encrypted file, or to check the signature integrity of a 1570: signed file: 1571: pgp ciphertextfile [-o plaintextfile] 1572: 1573: To encrypt a message for any number of multiple recipients: 1574: pgp -e textfile userid1 userid2 userid3 1575: 1576: --- Key management commands: 1577: 1578: To generate your own unique public/secret key pair: 1579: pgp -kg 1580: 1581: To add a public or secret key file's contents to your public or 1582: secret key ring: 1583: pgp -ka keyfile [keyring] 1584: 1585: To extract (copy) a key from your public or secret key ring: 1586: pgp -kx userid keyfile [keyring] 1587: or: pgp -kxa userid keyfile [keyring] 1588: 1589: To view the contents of your public key ring: 1590: pgp -kv[v] [userid] [keyring] 1591: 1592: To view the "fingerprint" of a public key, to help verify it over 1593: the telephone with its owner: 1594: pgp -kvc [userid] [keyring] 1595: 1596: To view the contents and check the certifying signatures of your 1597: public key ring: 1598: pgp -kc [userid] [keyring] 1599: 1600: To edit the userid or pass phrase for your secret key: 1601: pgp -ke userid [keyring] 1602: 1603: To edit the trust parameters for a public key: 1604: pgp -ke userid [keyring] 1605: 1606: To remove a key or just a userid from your public key ring: 1607: pgp -kr userid [keyring] 1608: 1609: To sign and certify someone else's public key on your public key ring: 1610: pgp -ks her_userid [-u your_userid] [keyring] 1611: 1612: To remove selected signatures from a userid on a keyring: 1613: pgp -krs userid [keyring] 1614: 1615: To permanently revoke your own key, issuing a key compromise 1616: certificate: 1617: pgp -kd your_userid 1618: 1619: To disable or reenable a public key on your own public key ring: 1620: pgp -kd userid 1621: 1622: --- Esoteric commands: 1623: 1624: To decrypt a message and leave the signature on it intact: 1625: pgp -d ciphertextfile 1626: 1627: To create a signature certificate that is detached from the document: 1628: pgp -sb textfile [-u your_userid] 1629: 1630: To detach a signature certificate from a signed message: 1631: pgp -b ciphertextfile 1632: 1633: --- Command options that can be used in combination with other 1634: command options (sometimes even spelling interesting words!): 1635: 1636: To produce a ciphertext file in ASCII radix-64 format, just add the 1637: -a option when encrypting or signing a message or extracting a key: 1638: pgp -sea textfile her_userid 1639: or: pgp -kxa userid keyfile [keyring] 1640: 1641: To wipe out the plaintext file after producing the ciphertext file, 1642: just add the -w (wipe) option when encrypting or signing a message: 1643: pgp -sew message.txt her_userid 1644: 1645: To specify that a plaintext file contains ASCII text, not binary, and 1646: should be converted to recipient's local text line conventions, add 1647: the -t (text) option to other options: 1648: pgp -seat message.txt her_userid 1649: 1650: To view the decrypted plaintext output on your screen (like the 1651: Unix-style "more" command), without writing it to a file, use 1652: the -m (more) option while decrypting: 1653: pgp -m ciphertextfile 1654: 1655: To specify that the recipient's decrypted plaintext will be shown 1656: ONLY on her screen and cannot be saved to disk, add the -m option: 1657: pgp -steam message.txt her_userid 1658: 1659: To recover the original plaintext filename while decrypting, add 1660: the -p option: 1661: pgp -p ciphertextfile 1662: 1663: To use a Unix-style filter mode, reading from standard input and 1664: writing to standard output, add the -f option: 1665: pgp -feast her_userid <inputfile >outputfile 1666: 1667: 1668: 1669: Legal Issues 1670: ============ 1671: 1672: For detailed information on PGP(tm) licensing, distribution, 1673: copyrights, patents, trademarks, liability limitations, and export 1674: controls, see the "Legal Issues" section in the "PGP User's Guide, 1675: Volume II: Special Topics". 1676: 1677: PGP uses a public key algorithm claimed by U.S. patent #4,405,829. 1678: The exclusive licensing rights to this patent are held by a 1679: California company called Public Key Partners, and you may be 1680: infringing the patent if you use PGP in the USA without a license. 1681: These issues are detailed in the Volume II manual, and in the RSAREF 1682: license that comes with the freeware version of PGP. PKP has licensed 1683: others to practice the patent, including a company known as ViaCrypt, 1684: in Phoenix, Arizona. ViaCrypt sells a fully licensed version of PGP. 1685: ViaCrypt may be reached at 602-944-0773. 1686: 1687: PGP is "guerrilla" freeware, and I don't mind if you distribute it 1688: widely. Just don't ask me to send you a copy. Instead, you can look 1689: for it yourself on many BBS systems and a number of Internet FTP 1690: sites. But before you distribute PGP, it is essential that you 1691: understand the U.S. export controls on encryption software. 1692: 1693: 1694: 1695: Acknowledgments 1696: ================ 1697: 1698: Formidable obstacles and powerful forces have been arrayed to stop 1699: PGP. Dedicated people are helping to overcome these obstacles. PGP 1700: has achieved notoriety as "underground software", and bringing PGP 1701: "above ground" as fully licensed freeware has required patience and 1702: persistence. I'd especially like to thank Hal Abelson, Jeff 1703: Schiller, Brian LaMacchia, and Derek Atkins at MIT for their 1704: determined efforts. I'd also like to thank Jim Bruce and David 1705: Litster in the MIT administration and Bob Prior and Terry Ehling at 1706: the MIT Press. And I'd like to thank my entire legal defense team, 1707: whose job is not over yet. I used to tell a lot of lawyer jokes, 1708: before I encountered so many positive examples of lawyers in my legal 1709: defense team, most of whom work pro bono. 1710: 1711: The development of PGP has turned into a remarkable social 1712: phenomenon, whose unique political appeal has inspired the collective 1713: efforts of an ever-growing number of volunteer programmers. Remember 1714: that children's story called "Stone Soup"? 1715: 1716: I'd like to thank the following people for their contributions to the 1717: creation of Pretty Good Privacy. Although I was the author of PGP 1718: version 1.0, major parts of later versions of PGP were implemented by 1719: an international collaborative effort involving a large number of 1720: contributors, under my design guidance. 1721: 1722: Branko Lankester, Hal Finney and Peter Gutmann all contributed a huge 1723: amount of time in adding features for PGP 2.0, and ported it to Unix 1724: variants. 1725: 1726: Hugh Kennedy ported it to VAX/VMS, Lutz Frank ported it to the Atari 1727: ST, and Cor Bosman and Colin Plumb ported it to the Commodore Amiga. 1728: 1729: Translation of PGP into foreign languages was done by Jean-loup 1730: Gailly in France, Armando Ramos in Spain, Felipe Rodriquez Svensson 1731: and Branko Lankester in The Netherlands, Miguel Angel Gallardo in 1732: Spain, Hugh Kennedy and Lutz Frank in Germany, David Vincenzetti in 1733: Italy, Harry Bush and Maris Gabalins in Latvia, Zygimantas Cepaitis 1734: in Lithuania, Peter Suchkow and Andrew Chernov in Russia, and 1735: Alexander Smishlajev in Esperantujo. Peter Gutmann offered to 1736: translate it into New Zealand English, but we finally decided PGP 1737: could get by with US English. 1738: 1739: Jean-loup Gailly, Mark Adler, and Richard B. Wales published the ZIP 1740: compression code, and granted permission for inclusion into PGP. The 1741: MD5 routines were developed and placed in the public domain by Ron 1742: Rivest. The IDEA(tm) cipher was developed by Xuejia Lai and James L. 1743: Massey at ETH in Zurich, and is used in PGP with permission from 1744: Ascom-Tech AG. 1745: 1746: Charlie Merritt originally taught me how to do decent multiprecision 1747: arithmetic for public key cryptography, and Jimmy Upton contributed a 1748: faster multiply/modulo algorithm. Thad Smith implemented an even 1749: faster modmult algorithm. Zhahai Stewart contributed a lot of useful 1750: ideas on PGP file formats and other stuff, including having more than 1751: one user ID for a key. I heard the idea of introducers from Whit 1752: Diffie. Kelly Goen did most of the work for the initial electronic 1753: publication of PGP 1.0. 1754: 1755: Various contributions of coding effort also came from Colin Plumb, 1756: Derek Atkins, and Castor Fu. Other contributions of effort, coding 1757: or otherwise, have come from Hugh Miller, Eric Hughes, Tim May, 1758: Stephan Neuhaus, and too many others for me to remember right now. 1.1.1.5 ! root 1759: Zbigniew Fiedorwicz did the first Macintosh port. 1.1.1.4 root 1760: 1761: Since the release of PGP 2.0, many other programmers have sent in 1762: patches and bug fixes and porting adjustments for other computers. 1763: There are too many to individually thank here. 1764: 1765: Just as in the "Stone Soup" story, it is getting harder to peer 1766: through the thick soup to see the stone at the bottom of the pot that 1767: I dropped in to start it all off. 1768: 1769: 1770: 1771: About the Author 1772: ================ 1773: 1774: Philip Zimmermann is a software engineer consultant with 19 years 1775: experience, specializing in embedded real-time systems, cryptography, 1776: authentication, and data communications. Experience includes design 1777: and implementation of authentication systems for financial 1778: information networks, network data security, key management 1779: protocols, embedded real-time multitasking executives, operating 1780: systems, and local area networks. 1781: 1782: Custom versions of cryptography and authentication products and 1783: public key implementations such as the NIST DSS are available from 1784: Zimmermann, as well as custom product development services. His 1785: consulting firm's address is: 1786: 1787: Boulder Software Engineering 1788: 3021 Eleventh Street 1789: Boulder, Colorado 80304 USA 1790: Phone: 303-541-0140 (10:00am - 7:00pm Mountain Time) 1791: Fax: arrange by phone 1792: Internet: [email protected] 1793:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.