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