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