PGPGUIDE.TXT Thursday, April 30, 1992 7:43 am Page 1 Phil's Pretty Good Software presents === PGP === Pretty Good Privacy RSA Public Key Cryptography for the Masses Version 1.0 - 5 Jun 91 PGP User's Guide Revised 30 Apr 92 (c) Copyright 1990 Philip Zimmermann Software and Documentation Written by Philip Zimmermann Synopsis: PGP uses public-key encryption to protect E-mail. Communicate securely with people you've never met, with no secure channels needed for prior exchange of keys. PGP is well featured and fast, with sophisticated key management, digital signatures, data compression, and good ergonomic design. For information on PGP licensing, distribution, copyrights, patents, trademarks, liability limitations, and export controls, see the "Legal Issues" section later in this document. PGPGUIDE.TXT Thursday, April 30, 1992 7:43 am Page 2 Contents ======== Quick Overview Why Do You Need PGP? How it Works Installing PGP How to Use PGP To See a Usage Summary Encrypting a Message Signing a Message Signing and then Encrypting Using Just Conventional Encryption Decrypting and Checking Signatures Managing Keys RSA Key Generation Adding a Key to Your Key Ring Removing a Key from Your Key Ring Viewing the Contents of Your Key Ring How to Protect Public Keys from Tampering How to Protect Secret Keys from Disclosure Advanced Topics Separating Signatures from Messages Sending Ciphertext Through E-mail Channels: Uuencode Format Leaving No Traces of Plaintext on the Disk Environmental Variable for Path Name Protecting Against Bogus Timestamps A Peek Under the Hood Random Numbers PGP's Conventional Encryption Algorithm Data Compression Message Digests and Digital Signatures Vulnerabilities Compromised Pass Phrase and Secret Key Public Key Tampering "Not Quite Deleted" Files Viruses and Trojan Horses Physical Security Breach Tempest Attacks Traffic Analysis Cryptanalysis Trusting Snake Oil PGP Quick Reference Legal Issues Trademarks, Copyrights, and Warranties Patent Rights on the Algorithms Licensing and Distribution Export Controls Acknowledgements Recommended Readings About the Author Appendix A: Where to Get PGP PGPGUIDE.TXT Thursday, April 30, 1992 7:43 am Page 3 Quick Overview ============== Pretty Good(tm) Privacy (PGP), from Phil's Pretty Good Software, is a high security cryptographic software application for MSDOS. PGP allows people to exchange files or messages with privacy, authentication, and convenience. Privacy means only those intended to receive a message can read it. Authentication means messages that appear to be from a particular person can only have originated from that person. Convenience means that privacy and authentication are provided without the hassles of managing keys associated with conventional cryptographic software. No secure channels are needed to exchange keys between users, which makes PGP much easier to use. This is because PGP is based on a powerful new technology called "public key" cryptography. PGP combines the convenience of the Rivest-Shamir-Adleman (RSA) public key cryptosystem with the speed of conventional cryptography, message digests for digital signatures, data compression before encryption, good ergonomic design, and sophisticated key management. And PGP performs the RSA functions faster than most other software implementations. PGP is RSA public key cryptography for the masses. PGP does not provide any built-in modem communications capability. You must use a separate product such as TELIX or PROCOMM for that. This document only explains how to use PGP without explaining the underlying technology details of cryptographic algorithms and data structures. PGPGUIDE.TXT Thursday, April 30, 1992 7:43 am Page 4 Why Do You Need PGP? ==================== It's personal. It's private. And it's no one's business but yours. You may be planning a political campaign, discussing your taxes, or having an illicit affair. Or you may be doing something that you feel shouldn't be illegal, but is. Whatever it is, you don't want your private electronic mail (E-mail) or confidential documents read by anyone else. There's nothing wrong with asserting your privacy. Privacy is as apple-pie as the Constitution. Perhaps you think your E-mail is legitimate enough that encryption is unwarranted. If you really are a law-abiding citizen with nothing to hide, then why don't you always send your paper mail on postcards? Why not submit to drug testing on demand? Why require a warrant for police searches of your house? Are you trying to hide something? You must be a subversive or a drug dealer if you hide your mail inside envelopes. Or maybe a paranoid nut. Do law-abiding citizens have any need to encrypt their E-mail? What if everyone believed that law-abiding citizens should use postcards for their mail? If some brave soul tried to assert his privacy by using an envelope for his mail, it would draw suspicion. Perhaps the authorities would open his mail to see what he's hiding. Fortunately, we don't live in that kind of world, because everyone protects most of their mail with envelopes. So no one draws suspicion by asserting their privacy with an envelope. There's safety in numbers. Analogously, it would be nice if everyone routinely used encryption for all their E-mail, innocent or not, so that no one drew suspicion by asserting their E-mail privacy with encryption. Think of it as a form of solidarity. If the Government wants to violate the privacy of ordinary citizens, it has to expend a certain amount of expense and labor to intercept and steam open and read paper mail, and listen to and possibly transcribe spoken telephone conversation. This kind of labor- intensive monitoring is not practical on a large scale. This is only done in important cases when it seems worthwhile. More and more of our private communications are going to be routed through electronic channels. Electronic mail will gradually replace conventional paper mail. E-mail messages are just too easy to intercept and scan for interesting keywords. This can be done easily, routinely, automatically, and undetectably on a grand scale. International cablegrams are already scanned this way on a large scale by the NSA. We are moving toward a future when the nation will be crisscrossed with high capacity fiber optic data networks linking together all our increasingly ubiquitous personal computers. E-mail will be the norm for everyone, not the novelty it is today. Perhaps the Government will protect our E-mail with Government-designed encryption algorithms. Probably most people will trust that. But perhaps some people will prefer their own protective measures. PGPGUIDE.TXT Thursday, April 30, 1992 7:43 am Page 5 Senate Bill 266, a 1991 omnibus anti-crime bill, had an unsettling measure buried in it. If this nonbinding resolution became real law, it would force manufacturers of secure communications equipment to insert special "trap doors" in their products, so that the Government can read anyone's encrypted messages. It reads: "It is the sense of Congress that providers of electronic communications services and manufacturers of electronic communications service equipment shall insure that communications systems permit the Government to obtain the plain text contents of voice, data, and other communications when appropriately authorized by law." This measure was defeated after rigorous protest from civil libertarians and industry groups. But the Government has since introduced other legislation to work toward similar objectives. If privacy is outlawed, only outlaws will have privacy. Intelligence agencies have access to good cryptographic technology. So do the big arms and drug traffickers. So do defense contractors, oil companies, and other corporate giants. But ordinary people and grassroots political organizations mostly have not had access to affordable "military grade" public-key cryptographic technology. PGP enables people to take their privacy into their own hands. There's a growing social need for it. That's why I wrote it. PGPGUIDE.TXT Thursday, April 30, 1992 7:43 am Page 6 How it Works ============ It would help if you were already familiar with the concept of cryptography in general and public key cryptography in particular. Nonetheless, here are a few introductory remarks about public key cryptography. In conventional cryptosystems, such as the Federal Data Encryption Standard (DES), a single key is used for both encryption and decryption. This means that keys must be initially transmitted via secure channels so that both parties can know them before encrypted messages can be sent over insecure channels. This may be inconvenient. If you have a secure channel for exchanging keys, then why do you need cryptography in the first place? In public key cryptosystems, everyone has two related complimentary keys, a publicly revealed key and a secret key. Each key unlocks the code that the other key makes. Knowing the public key does not help you deduce the corresponding secret key. The public key can be published and widely disseminated across a communications network. This protocol provides privacy without the need for the same kind of secure channels that a conventional cryptosystem requires. Anyone can use a recipient's public key to encrypt a message to that person, and that recipient uses her own corresponding secret key to decrypt that message. No one but the recipient can decrypt it, because no one else has access to that secret key. Not even the person who encrypted the message can decrypt it. Message authentication is also provided. The sender's own secret key can be used to encrypt a message, thereby "signing" it. This creates a digital signature of a message, which the recipient (or anyone else) can check by using the sender's public key to decrypt it. This proves that the sender was the true origin of the message, and that the message has not been subsequently altered by anyone else, because the sender alone possesses the secret key that made that signature. Forgery of a signed message is infeasible, and the sender cannot later disavow his signature. These two processes can be combined to provide both privacy and authentication by first signing a message with your own secret key, then encrypting the signed message with the recipient's public key. The recipient reverses these steps by first decrypting the message with her own secret key, then checking the enclosed signature with your public key. These steps are done automatically by the recipient's software. Because the RSA public key encryption algorithm is so slow, encryption is better accomplished by using a high-quality fast conventional encryption algorithm to encipher the message. This original unenciphered message is called "plaintext". In a process invisible to the user, a temporary random key, created just for this one "session", is used to conventionally encipher the plaintext file. Then the recipient's RSA public key is used to encipher this PGPGUIDE.TXT Thursday, April 30, 1992 7:43 am Page 7 temporary random conventional key. This RSA-enciphered conventional "session" key is sent along with the enciphered text (called "ciphertext") to the recipient. The recipient uses her own RSA secret key to recover this temporary session key, and then uses that key to run the fast conventional algorithm to decipher the large ciphertext message. RSA keys are kept in "key certificates" that include the key owner's user ID (which is that person's name), a timestamp of when the key pair was generated, and the actual key material. A key file, or "key ring" contains one or more of these key certificates. Public key certificates contain the public key material, while secret key certificates contain the secret key material. Public key rings contain only public keys, and secret key rings contain just secret keys. Secret keys are cryptographically protected by their own password. The keys are also internally referenced by a "key ID", which is an "abbreviation" of the public key (the least significant 64 bits of the large public key). When this key ID is displayed, only the lower 24 bits are shown for further brevity. While many keys may share the same user ID, for all practical purposes no two keys share the same key ID. PGP uses "message digests" to form signatures. A message digest is a 128-bit cryptographically strong one-way hash function of the message. It is somewhat analogous to a "checksum" or CRC error checking code, in that it compactly "represents" the message and is used to detect changes in the message. Unlike a CRC, however, it is computationally infeasible for an attacker to devise a substitute message that would produce an identical message digest. The message digest gets encrypted by the RSA secret key to form a signature. Documents are signed by prefixing them with signature certificates, which contain the key ID of the key that was used to sign it, an RSA-signed message digest of the document, and a timestamp of when the signature was made. The key ID is used by the receiver to look up the sender's public key to check the signature. The receiver's software automatically looks up the sender's public key and user ID in the receiver's public key ring. Encrypted files are prefixed by the key ID of the public key used to encrypt them. The receiver uses this key ID message prefix to look up the secret key needed to decrypt the message. The receiver's software automatically looks up the necessary secret decryption key in the receiver's secret key ring. These two types of key rings are the principal method of storing and managing public and secret keys. Rather than keep individual keys in separate key files, they are collected in key rings to facilitate the automatic lookup of keys either by key ID or by user ID. Each user keeps his own pair of key rings. An individual public key is temporarily kept in a separate file long enough to send to your friend who will then add it to her key ring. An individual key file is no different from a key ring that contains only one key. PGPGUIDE.TXT Thursday, April 30, 1992 7:43 am Page 8 Installing PGP ============== To install PGP on your MSDOS system, you just have to copy it into a suitable directory on your hard disk (like C:\PGP), and use the shareware PKUNZIP utility to decompress it from the compressed archive PGP release file, called PGP10.ZIP. For best results, you will also modify your AUTOEXEC.BAT file, as described elsewhere in this manual, but you can do that later, after you've played with PGP a bit and read more of this manual. For further details on installation, see the separate PGP Installation Guide, in the MSDOS file SETUP.DOC included with this release. It fully describes how to set up the PGP directory and how to use PKUNZIP to install it, and also describes how to detect virus infections of PGP releases. How to Use PGP ============== To See a Usage Summary ---------------------- To see a quick command usage summary for PGP, just type: pgp This will display a usage summary for the most essential commands only. The commands described in the Advanced Topics section are not displayed. Encrypting a Message -------------------- To encrypt a plaintext file with the recipent's public key, type: pgp -e textfile her_userid This command produces a ciphertext file called textfile.ctx. A specific example is: pgp -e letter.txt Alice_S This will search your public key ring file "keyring.pub" for any public key certificates that contain the string "Alice S" anywhere in the user ID field. The search is not case-sensitive. Note that underlines get changed to spaces. That's because you can't use real spaces in the user ID on the command line. If it finds a matching public key, it uses it to encrypt the plaintext file "letter.txt", PGPGUIDE.TXT Thursday, April 30, 1992 7:43 am Page 9 producing a ciphertext file called "letter.ctx". PGP will attempt to compress the plaintext before encrypting it, thereby greatly enhancing resistance to cryptanalysis. Thus the ciphertext file will likely be smaller than the plaintext file. If you want to send this encrypted message through E-mail channels, convert it into printable ASCII "uuencode" format by adding the -u option, as described later. Signing a Message ----------------- To sign a plaintext file with your secret key, type: pgp -s textfile your_userid This command produces a signed file called textfile.ctx. A specific example is: pgp -s letter.txt Bob This will search your secret key ring file "keyring.sec" for any secret key certificates that contain the string "Bob" anywhere in the user ID field. The search is not case-sensitive. Note that underlines get changed to spaces. If it finds a matching secret key, it uses it to sign the plaintext file "letter.txt", producing a signature file called "letter.ctx". Signing and then Encrypting --------------------------- To sign a plaintext file with your secret key, and then encrypt it with the recipent's public key: pgp -es textfile her_userid your_userid This example produces a nested ciphertext file called textfile.ctx. Your secret key to create the signature is automatically looked up in your secret key ring via your_userid. Her public encryption key is automatically looked up in your public keyring via her_userid. If you leave these user ID fields off the command line, you will be prompted for them. Note that PGP will attempt to compress the plaintext before encrypting it. If you want to send this encrypted message through E-mail channels, convert it into printable ASCII "uuencode" format by adding the -u option, as described later. PGPGUIDE.TXT Thursday, April 30, 1992 7:43 am Page 10 Using Just Conventional Encryption ---------------------------------- Sometimes you just need to encrypt a file the old-fashioned way, with conventional single-key cryptography. This approach is useful for protecting archive files that will be stored but will not be sent to anyone else. Since the same person that encrypted the file will also decrypt the file, public key cryptography is not really necessary. To encrypt a plaintext file with just conventional cryptography, type: pgp -c textfile This example encrypts the plaintext file called textfile, producing a ciphertext file called textfile.ctx, without using public key cryptography, key rings, user IDs, or any of that stuff. It prompts you for a pass phrase to use as a conventional key to encipher the file. Note that PGP will attempt to compress the plaintext before encrypting it. You may be interested to know that it is not likely that PGP would encrypt the same plaintext the same way twice, even if you used the same pass phrase every time. Decrypting and Checking Signatures ---------------------------------- To decrypt an encrypted file, or to check the signature integrity of a signed file: pgp ciphertextfile [plaintextfile] Note that [brackets] denote an optional field, so don't actually type real brackets. The ciphertext file name is assumed to have a default extension of ".ctx". The optional plaintext file name specifies where to put processed plaintext output. If no name is specified, the ciphertext filename is used, with no extension. If a signature is nested inside of an encrypted file, it is automatically decrypted and the signature integrity is checked. The full user ID of the signer is displayed. Note that the "unwrapping" of the ciphertext file is completely automatic, regardless of whether the ciphertext file is just signed, just encrypted, or both. PGP uses the key ID prefix in the ciphertext file to automatically find the appropriate secret decryption key on your secret key ring. If there is a nested signature, PGP will then use the key ID prefix in the nested signature to automatically find the appropriate public key on your public key ring to check the signature. If all the right keys are already present on your key rings, no user intervention is required, except that you will be prompted for your password for your secret key if necessary. If the ciphertext file was conventionally PGPGUIDE.TXT Thursday, April 30, 1992 7:43 am Page 11 encrypted without public key cryptography, PGP will recognize this and will prompt you for the pass phrase to decrypt it. PGPGUIDE.TXT Thursday, April 30, 1992 7:43 am Page 12 Managing Keys ============= Since the time of Julius Caesar, key management has always been the hardest part of cryptography. One of the principal distinguishing features of PGP is its sophisticated key management. RSA Key Generation ------------------ To generate your own unique public/secret key pair of a specified size, type: pgp -k The software will prompt you for a filename for the pair of keys, which will be written to filename.pub and filename.sec. It will also give you a menu of recommended key sizes (casual grade, commercial grade, or military grade) and prompt you for what size key you want, up to around a thousand bits. The bigger the key, the more security you get, but you pay a price in speed. It also asks for a user ID, which means your name. It's a good idea to use your full name as your user ID, because then there is less risk of other people using the wrong public key to encrypt messages to you. Spaces and punctuation are allowed in the user ID. Also, if you put your last name first it would facilitate producing lists of public keys sorted by user ID. It would also help if you put your E-mail address after your name, like so: Smith, Robert M. - rms@xyzcorp.com If you don't have an E-mail address, use your phone number or some other unique information that would help ensure that your user ID is unique. PGP will also ask for a "pass phrase" to protect your RSA secret key in case it falls into the wrong hands. Nobody can use your secret key file without this pass phrase. The pass phrase is like a password, except that it can be a whole phrase or sentence with many words, spaces, punctuation, or anything else you want in it. Don't lose this pass phrase, there's no way to recover it if you do lose it. This pass phrase will be needed later every time you use your RSA secret key. The pass phrase is case-sensitive, and should not be too short or easy to guess. It is never displayed on the screen. Don't leave it written down anywhere where someone else can see it, and don't store it on your computer. If you don't want a pass phrase (ill-advised), just press return (or enter) at the pass phrase prompt. The RSA key pair is derived from large truly random numbers derived from measuring the intervals between your keystrokes with a fast timer. PGPGUIDE.TXT Thursday, April 30, 1992 7:43 am Page 13 Note that RSA key generation is a VERY lengthy process. It may take a few seconds for a small key on a fast processor, or many minutes for a large key, or maybe an hour for a large key on an old IBM PC/XT. The public keyfile can be sent to your friends for inclusion in their public key rings. Naturally, you keep your secret key file to yourself, and you should include it on your secret key ring. Each secret key on a key ring is individually protected with its own pass phrase. Never give you secret key to anyone else. For the same reason, don't make key pairs for your friends. Everyone should make their own key pair. Always keep physical control of your secret key, and don't risk exposing it by storing it on a remote timesharing computer. Keep it on your own personal computer. Adding a Key to Your Key Ring ----------------------------- To add a public or secret key file's contents to your public or secret key ring (note that [brackets] denote an optional field): pgp -a keyfile [keyring] The keyfile extension defaults to ".pub", implying a public key. The optional keyring file name is assumed to be literally "keyring.pub" or "keyring.sec", depending on whether the keyfile name had a ".pub" or ".sec" extension. You may specify a different key ring file name. The default key ring extension is ".pub". If the key is already on your keyring, PGP will not add it again. All of the keys in the keyfile will be added to the keyring. Note that the keyfile should only contain one key, because PGP only checks the first key in the keyfile for duplicates on the keyring. Removing a Key from Your Key Ring --------------------------------- To remove a key from your public key ring: pgp -r userid [keyring] This will search for the specified user ID in your keyring, and will remove it if it finds a match. Remember that any fragment of the user ID will suffice for a match. The optional keyring file name is assumed to be literally "keyring.pub". It can be omitted, or you can specify "keyring.sec" if you want to remove a secret key. You may specify a different key ring file name. The default key ring extension is ".pub". Viewing the Contents of Your Key Ring ------------------------------------- PGPGUIDE.TXT Thursday, April 30, 1992 7:43 am Page 14 To view the contents of your public key ring: pgp -v [userid] [keyring] This will list any keys in the key ring that match the specified user ID substring. If you omit the user ID, all of the keys in the key ring will be listed. The optional keyring file name is assumed to be literally "keyring.pub". It can be omitted, or you can specify "keyring.sec" if you want to list secret keys. If you want to specify a different key ring file name, you can. The default key ring extension is ".pub". If you want to specify a particular key ring file name, but want to see all the keys in it, try this alternative approach: pgp keyfile.sec Using this approach requires that the key ring name be fully qualified with the extension of ".pub" or ".sec", because if you don't specify a file extension, ".ctx" is assumed. How to Protect Public Keys from Tampering ----------------------------------------- In a public key cryptosystem, you don't have to protect public keys from exposure. In fact, it's better if they are widely disseminated. But it is important to protect public keys from tampering, to make sure that a public key really belongs to whom it appears to belong. This may be the most important vulnerability of a public-key cryptosystem. Let's first look at a potential disaster, then at how to safely avoid it with PGP. Suppose you wanted to send a private message to Alice. You download Alice's public key certificate from an electronic bulletin board system (BBS). You encrypt your letter to Alice with this public key and send it to her through the BBS's E-mail facility. Unfortunately, unbeknownst to you or Alice, another user named Charlie has infiltrated the BBS and generated a public key of his own with Alice's user ID attached to it. He covertly substitutes his bogus key in place of Alice's real public key. You unwittingly use this bogus key belonging to Charlie instead of Alice's public key. All looks normal because this bogus key has Alice's user ID. Now Charlie can decipher the message intended for Alice because he has the matching secret key. He may even re-encrypt the deciphered message with Alice's real public key and send it on to her so that no one suspects any wrongdoing. Furthermore, he can even make apparantly good signatures from Alice with this secret key because everyone will use the bogus public key to check Alice's signatures. The only way to prevent this disaster is to prevent anyone from tampering with public keys. If you got Alice's public key directly from Alice, this is no problem. But that may be difficult if Alice is a thousand miles away, or is currently unreachable. Perhaps you PGPGUIDE.TXT Thursday, April 30, 1992 7:43 am Page 15 could get Alice's public key from a mutual trusted friend David who knows he has a good copy of Alice's public key. David could sign Alice's public key, vouching for the integrity of Alice's public key. David would create this signature in the usual way, with his own secret key. This would create a signed public key certificate, and would show that Alice's key had not been tampered with. This requires you have a known good copy of David's public key to check his signature. Perhaps David could provide Alice with a signed copy of your public key also. David is thus serving as an "introducer" between you and Alice. This signed public key certificate for Alice could be uploaded by David or Alice to the BBS, and you could download it later. You could then check the signature via David's public key and thus be assured that this is really Alice's public key. No imposter can fool you into accepting his own bogus key as Alice's because no one else can forge signatures made by David. A widely trusted person could even specialize in providing this service of "introducing" users to each other by providing signatures for their public key certificates. This trusted person could be regarded as a "key server", or as a "Certifying Authority". Any public key certificates bearing the key server's signature could be trusted as truly belonging to whom they appear to belong to. All users who wanted to participate would need a known good copy of just the key server's public key, so that the key server's signatures could be verified. A trusted centralized key server or Certifying Authority is especially appropriate for large impersonal centrally-controlled corporate or government institutions. Some institutional environments use hierarchies of Certifying Authorities. For more decentralized grassroots "guerilla style" environments, allowing all users to act as a trusted introducers for their friends would probably work better than a centralized key server. PGP tends to emphasize this organic decentralized non-institutional approach. It better reflects the natural way humans interact on a personal social level, and allows people to better choose who they can trust for key management. You should add a new public key to your key ring only after you are sure that it is a good public key that has not been tampered with and actually belongs to the person it claims to. You can be sure of this if you got this public key certificate directly from its owner, or if it bears the signature of someone else that you trust, from whom you already have a good public key. Also, the user ID should have the full name of the key's owner, not just her first name. Now listen to me: No matter how tempted you are-- and you will be tempted-- never, NEVER give in to expediency and trust a public key you downloaded from a bulletin board, unless it is signed by someone you trust. That unsigned public key could have been tampered with by anyone, maybe even by the system administrator of the bulletin board. PGPGUIDE.TXT Thursday, April 30, 1992 7:43 am Page 16 If you are asked to sign someone else's public key certificate, make certain that it really belongs to that person named in the user ID of that public key certificate. This is because your signature on her public key certificate is a promise by you that this public key really belongs to her. Other people who trust you will accept her public key because it bears your signature. Bear in mind that your signature on a public key certificate does not vouch for the integrity of that person, but only vouches for the integrity (the ownership) of that person's public key. Trust is not necessarily transferable; if I trust Alice's signature on a key, and Alice trusts Charlie's signature on a key, that does not imply that I have to trust Charlie's signature on a key. Maybe I think Charlie is a lying scoundrel, and Alice is honest, but naive because she trusts Charlie. If I get Charlie's key bearing Alice's signature, I'll trust that key belongs to Charlie because Alice says so. But if I later get Bob's key bearing Charlie's signature, maybe I won't believe that key belongs to Bob, even though I trust the integrity of Charlie's key because it bore Alice's signature. Trusting the ownership of a key is different from trusting a person. If I get Bob's key bearing Alice's signature, then I'll trust that key. I would hope Alice got that key directly from Bob before she signed it and asked me to accept her promise that the key belongs to Bob. If she did not get that key directly from Bob, but trusted it just because it had Charlie's signature, then maybe it's okay for her to trust Bob's key for her own purposes only. Perhaps Charlie can be trusted sometimes to vouch for the keys of his friends, but not of his adversaries. It may be ill-advised for Alice to stake her own reputation on her faith in Charlie, and sign the key herself just because Charlie told her it was from Bob. Then she would be asking me and anyone else who trusts her signature to believe her own promise that the key belongs to Bob. While all this may sound complicated, it's really just common-sense rules about trust that people use in everyday human affairs. You may want to keep your own public key around with signatures from a variety of "introducers" in the hopes that most people will trust at least one of the introducers who vouch for your own public key's integrity. If you sign someone else's public key, return the signature to them so that they can use it as a credential for their own public key. Make sure no one else can tamper with your own public key ring. Checking a new signed public key certificate must ultimately depend on the integrity of the public keys that are already on your own public key ring. Maintain physical control of your public key ring, preferably on your own personal computer rather than on a remote timesharing system, just as you would do for your secret key. This is to protect it from tampering, not from disclosure. Keep a trusted backup copy of your public key ring on write-protected media, and check it once in a while against the working copy. One somewhat complicated way to protect your own public key ring from tampering is to sign the whole ring with your own secret key. You could do this by making a detached signature certificate of the public key ring, by signing the ring with the "-sb" options (see the PGPGUIDE.TXT Thursday, April 30, 1992 7:43 am Page 17 section called "Separating Signatures from Messages"). Unfortunately, you would still have to keep a separate trusted copy of your own public key around to check the signature you made. You couldn't rely on your own public key stored on your public key ring to check the signature you made for the whole ring, because that is part of what you're trying to check. Perhaps a future version of PGP will have features to facilitate this approach. How to Protect Secret Keys from Disclosure ------------------------------------------ Protect your own secret key and your pass phrase carefully. Really, really carefully. If your secret key is ever compromised, you'd better get the word out quickly to all interested parties (good luck) before someone else uses it to make signatures in your name. For example, they could use it to sign bogus public key certificates, which could create problems for many people, especially if your signature is widely trusted. And of course, a compromise of your own secret key could expose all messages sent to you. The decentralized non-institutional approach PGP has of using introducers to manage public keys has its benefits, but more refinements are required to deal with the problems of trying to contain the damage of a secret key compromise. To protect your secret key, you can start by always keeping physical control of your secret key. Keeping it on your personal computer at home is OK, or keep it in your laptop or notebook computer that you can carry with you. If you must use an office computer that you don't always have physical control of, then keep your public and secret key rings on a write-protected removable floppy disk, and don't leave it behind when you leave the office. It wouldn't be a good idea to allow your secret key to reside on a remote timesharing computer, such as a remote dial-in Unix system. Someone could eavesdrop on your modem line and capture your pass phrase, and then obtain your actual secret key from the remote system. You should only use your secret key on a machine that you have physical control over. Don't store your pass phrase anywhere on the computer that has your secret key file. Storing both the secret key and the pass phrase on the same computer is as dangerous as keeping your PIN in the same wallet as your Automatic Teller Machine bank card. You don't want somebody to get their hands on your disk containing both the pass phrase and the secret key file. It would be most secure if you just memorize your pass phrase and don't store it anywhere but your brain. If you feel you must write down your pass phrase, keep it well protected, perhaps even more well protected than the secret key file. And keep backup copies of your secret key ring-- remember, you have the only copy of your secret key, and losing it will render useless all the copies of your public key that you have spread throughout the world. PGPGUIDE.TXT Thursday, April 30, 1992 7:43 am Page 18 Advanced Topics =============== Separating Signatures from Messages ----------------------------------- Normally, signature certificates are prepended (attached) to the text they sign. This makes it convenient in simple cases to check signatures. It is desirable in some circumstances to have signature certificates stored separately from the messages they sign. It is possible to generate signature certificates that are detached from the text they sign. To do this, combine the 'b' (break) option with the 's' (sign) option. For example: pgp -sb letter.txt your_userid This example produces an isolated signature certificate in a file called "letter.ctx". The contents of letter.txt are not appended to the signature certificate. After creating the signature certificate file (letter.ctx in the above example), send it along with the original text file to the recipient. The recipient must have both files to check the signature integrity. When the recipient attempts to process the signature file, PGP will notice that there is no text in the same file with the signature and will prompt the user for the filename of the text. Only then will PGP be able to properly check the signature integrity. If the recipient knows in advance that the signature is detached from the text file, she can specify both filenames on the command line: pgp letter.ctx letter.txt or: pgp letter letter.txt PGP will not have to prompt for the text file name in this case. A detached signature certificate is useful if you want to keep the signature certificate in a separate certificate log. A detached signature of an executable program is also useful for detecting a subsequent virus infection. It is also useful if more than one party must sign a document such as a legal contract, without nesting signatures. Each person's signature is independent. Sending Ciphertext Through E-mail Channels: Uuencode Format ----------------------------------------------------------- For all you Unix fans out there: PGP supports uuencode format for ciphertext messages. This special format represents binary data by using only printable ASCII characters, so it is useful for transmitting binary encrypted data through 7-bit channels or for sending binary encrypted data as normal E-mail text. PGPGUIDE.TXT Thursday, April 30, 1992 7:43 am Page 19 Uuencode format converts the plaintext by expanding groups of 3 binary 8-bit bytes into 4 printable ASCII characters, so the file will grow by about 35%. But this expansion isn't so bad when you consider that the file probably was compressed more than that by PGP before it was encrypted. To produce a ciphertext file in uuencode format, just add the "u" option when encrypting or signing a message, like so: pgp -esu message.txt her_userid your_userid This example produces a ciphertext file called "message.ctx" that contains data in Unix uuencode format. This file can be easily uploaded into a text editor through 7-bit channels for transmission as normal E-mail on Internet or any other E-mail network. Decrypting the uuencode-formatted message is no different than a normal decrypt. For example: pgp message PGP will automatically recognize that the file "message.ctx" is in uuencode format and will uudecode it before processing as it normally does. The output file will be in normal plaintext form, just as it was in the original file "message.txt". During decryption, after PGP uudecodes the ".ctx" file, it leaves it in binary ciphertext form. In other words, the ".ctx" file is no longer in uuencode format when PGP is done processing it. PGP produces a decrypted plaintext file, and also produces as a by-product a uudecoded ciphertext file in binary form. If you want to send a public key or key ring to someone else in uuencode format, you don't really need to use a separate uuencode utility. You could just do one of the following: 1) Have someone else act as an introducer by signing your key with the "-su" options to create a ".ctx" file with the signed key in uuencode format. This is probably the best way to distribute your public key through E-mail channels. 2) Sign it yourself with the -su options. While it may seem cryptographically pointless to use a key to sign itself, at least it creates a uuencoded .ctx file with your public key. Leaving No Traces of Plaintext on the Disk ------------------------------------------ After PGP makes a ciphertext file for you, you can have PGP automatically overwrite the plaintext file and delete it, leaving no trace of plaintext on the disk so that no one can recover it later using a disk block scanning utility. This is useful if the plaintext file contains sensitive information that you don't want to keep around. PGPGUIDE.TXT Thursday, April 30, 1992 7:43 am Page 20 To wipe out the plaintext file after producing the ciphertext file, just add the "w" (wipe) option when encrypting or signing a message, like so: pgp -esw message.txt her_userid your_userid This example will create the ciphertext file "message.ctx", and the plaintext file "message.txt" will be destroyed beyond recovery. Obviously, you should be careful with this option. Also note that this will not wipe out any fragments of plaintext that your word processor might have created on the disk while you were editing the message before running PGP. Most word processors create backup files, scratch files, or both. Also, it overwrites the file only once, which is enough to thwart conventional disk recovery efforts, but not enough to withstand a determined and sophisticated effort to recover the faint magnetic traces of the data using special disk recovery hardware. Environmental Variable for Path Name ------------------------------------ The standard key ring files "keyring.pub" and "keyring.sec" can be kept in any directory, by setting the environmental variable "PGPPATH" to the desired pathname. For example, the MSDOS shell command: SET PGPPATH=C:\PGP will make PGP assume the key ring filenames "C:\PGP\keyring.pub" and "C:\PGP\keyring.sec". Assuming, of course, this directory exists. Use your favorite text editor to modify your MSDOS AUTOEXEC.BAT file to automatically set up this variable whenever you start up your system. If PGPPATH remains undefined, these special files are assumed to be in the current directory. PGPGUIDE.TXT Thursday, April 30, 1992 7:43 am Page 21 Protecting Against Bogus Timestamps =================================== A somewhat obscure vulnerability of PGP involves dishonest users creating bogus timestamps on their own public key certificates and signatures. You can skip over this section if you are a casual user and aren't deeply into obscure public key protocols. There's nothing to stop a dishonest user from altering the date and time setting of his own system's clock, and generating his own public key certificates and signatures that appear to have been created at a different time. He can make it appear that he signed something earlier or later than he actually did, or that his public/secret key pair was created earlier or later. This may have some legal or financial benefit to him, for example by creating some kind of loophole that might allow him to repudiate a signature. A remedy for this could involve some trustworthy Certifying Authority or notary that would create notarized signatures with a trustworthy timestamp. This might not necessarily require a centralized authority. Perhaps any trusted introducer or disinterested party could serve this function, the same way real notary publics do now. A public key certificate could be signed by the notary, and the trusted timestamp in the notary's signature would have some legal significance. The notary could enter the signed certificate into a special certificate log controlled by the notary. Anyone can read this log. The notary could also sign other people's signatures, creating a signature certificate of a signature certificate. This would serve as a witness to the signature the same way real notaries do now with paper. Again, the notary could enter the detached signature certificate (without the actual whole document that was signed) into a log controlled by the notary. The notary's signature would have a trusted timestamp, which might have greater credibility than the timestamp in the original signature. A signature becomes "legal" if it is signed and logged by the notary. This problem of certifying signatures with notaries and trusted timestamps warrants further discussion. This can of worms will not be fully covered here now. There is a good treatment of this topic in Denning's 1983 article in IEEE Computer (see references). There is much more detail to be worked out in these various certifying schemes. This will develop further as PGP usage increases and other public key products develop their own certifying schemes. PGPGUIDE.TXT Thursday, April 30, 1992 7:43 am Page 22 A Peek Under the Hood ===================== Let's take a look at a few internal features of PGP. Random Numbers -------------- PGP uses a cryptographically strong pseudorandom number generator for creating temporary conventional session keys. The seed file for this is called "randseed.pgp". It too can be kept in whatever directory is indicated by the PGPPATH environmental variable. If this random seed file does not exist, it will be automatically created and seeded with truly random numbers derived from timing your keystroke latencies. This generator reseeds the disk file each time it is used with new key material partially derived with the time of day and other truly random sources. It uses the conventional encryption algorithm as an engine for the random number generator. The seed file contains both random seed material and random key material to key the conventional encryption engine for the random generator. If you are a security fanatic and distrust any algorithmically derived random number source however strong, you can defeat this feature by creating an empty file named "randseed.pgp". This file must be empty or nearly empty to turn off this pseudorandom generator. In that case, every encryption session key will require a bothersome request to the user to type some text in at the keyboard to measure the keystroke intervals with a high speed timer. It would be more convenient and not that unsafe to use the strong pseudorandom generator. PGP's Conventional Encryption Algorithm --------------------------------------- As described earlier, PGP "bootstraps" into a conventional encryption algorithm by using RSA to encipher the conventional session key and then switching to fast conventional cryptography. So let's talk about this conventional encryption algorithm. It isn't the DES. The Federal Data Encryption Standard is a good algorithm for most commercial applications. However, the Government does not trust the DES to protect its own classified data. Perhaps this is because the DES key length is 56 bits, short enough for a brute force attack with a special purpose machine built from a million or so DES chips. Also, Biham and Shamir have had some success recently on attacking the DES. PGP does not use the DES as its conventional single-key algorithm to encrypt messages. Instead, PGP uses a custom conventional single-key block encryption algorithm. A future version of PGP may support the DES as an option, because some users have asked for it. PGPGUIDE.TXT Thursday, April 30, 1992 7:43 am Page 23 For the cryptographically curious, PGP's conventional block cipher has a 256-byte block size for the plaintext and the ciphertext. It also uses a key size of up to 256 bytes. Permutation and substitution are used on all the bits throughout the block in each round, rapidly building intersymbol dependance between the ciphertext and both the plaintext and the key. It can be configured to run from 1 to 8 rounds. It compares well with software implementations of the DES in speed. Like the DES, it can be used in cipher feedback (CFB) and cipher block chaining (CBC) modes. PGP uses it in CFB mode. The DES may be so well designed that it might only be crackable by exhausting the 56-bit key space, requiring about 2^56 operations. PGP's conventional encryption algorithm may not be as carefully designed, so some sophisticated cryptanalytic attacks may require a lot less work to crack it than exhausting its 2000-bit key space, perhaps requiring only 2^100 or so operations. The work factor for cracking it is still a matter of speculation. PGP's conventional encryption algorithm is based in large part on an algorithm developed by Charles Merritt. Merritt's algorithm does have something of a track record; derivatives of it have been used for some secure US military communications. Merritt's original designs were refined by Zhahai Stewart and myself to improve security and to improve performance in a portable C implementation. The algorithm has not yet (in 1991) been through a formal security review and has had only limited peer review. A full discussion of the architecture is beyond the scope of this user documentation. Interested parties can get design details from me or from the published source code. It is not ergonomically practical to use pure RSA with large keys to encrypt and decrypt long messages. Absolutely no one does it that way in the real world. But perhaps you are concerned that the whole package is weakened if we use a hybrid public-key and conventional scheme just to speed things up. After all, a chain is only as strong as its weakest link. Many people less experienced in cryptography mistakenly believe that RSA is intrinsically stronger than any conventional cipher. It's not. RSA can be made weak by using weak keys, and conventional ciphers can be made strong by choosing good algorithms. It's usually difficult to tell exactly how strong a good conventional cipher is, without actually cracking it. A really good conventional cipher might possibly be harder to crack than even a "military grade" RSA key. The attraction of public key cryptography is not because it is intrinsically stronger than a conventional cipher-- its appeal is because it helps you manage keys more conveniently. Data Compression ---------------- PGP normally compresses the plaintext before encrypting it. It's too late to compress it after it has been encrypted; encrypted data is incompressible. Data compression saves modem transmission time and disk space and more importantly strengthens cryptographic security. Most cryptanalysis techniques exploit redundancies found in the PGPGUIDE.TXT Thursday, April 30, 1992 7:43 am Page 24 plaintext to crack the cipher. Data compression reduces this redundancy in the plaintext, thereby greatly enhancing resistance to cryptanalysis. It seems to take longer to compress the plaintext than to encrypt it, but from a security point of view it seems worth the extra time, at least in my cautious opinion. Files that are too short to compress or just don't compress well are not compressed by PGP. If you prefer, you can use PKZIP to compress the plaintext before encrypting it. PKZIP is a widely-available and effective MSDOS shareware compression utility from PKWare, Inc (9025 N Deerwood Dr, Brown Deer, WI 53223). Unlike PGP's built-in compression algorithm, PKZIP has the nice feature of compressing multiple files into a single compressed file, which is reconstituted again into separate files when decompressed. PKZIP also compresses faster than the internal compression algorithm used in PGP. PGP will not try to compress a plaintext file that has already been compressed by PKZIP. After decrypting, the recipient can decompress the plaintext with PKUNZIP. If the decrypted plaintext is a PKZIP compressed file, PGP will automatically recognize this and will advise the recipient that the decrypted plaintext appears to be a PKZIP file. For the technically curious readers, PGP uses the public domain LZHuf compression routines written in Japan by Haruyasu Yoshizaki, based on the original LZSS compression routines by Haruhiko Okumura. Yoshizaki added the adaptive Huffman algorithm and used the LZHuf routines to develop the LHarc archiver. This compression software was selected for PGP mainly because of its public domain portable C source code availability, and because it has a good compression ratio. Message Digests and Digital Signatures -------------------------------------- To create a digital signature, PGP encrypts with your secret key. But PGP doesn't actually encrypt your entire message with your secret key-- that would take too long. Instead, PGP encrypts a "message digest". The message digest is a compact (128 bit) "distillate" of your message, similar in concept to a checksum. You can also think of it as a "fingerprint" of the message. The message digest "represents" your message, such that if the message were altered in any way, a different message digest would be computed from it. This makes it possible to detect any changes made to the message by a forger. A message digest is computed using a cryptographically strong one-way hash function of the message. It would be computationally infeasible for an attacker to devise a substitute message that would produce an identical message digest. In that respect, a message digest is much better than a checksum, because it is easy to devise a different message that would produce the same checksum. But like a checksum, you can't derive the original message from its message digest. A message digest alone is not enough to authenticate a message. The message digest algorithm is publicly known, and does not require PGPGUIDE.TXT Thursday, April 30, 1992 7:43 am Page 25 knowledge of any secret keys to calculate. If all we did was attach a message digest to a message, then a forger could alter a message and simply attach a new message digest calculated from the new altered message. To provide real authentication, the sender has to encrypt (sign) the message digest with his secret key. A message digest is calculated from the message by the sender. The sender's secret key is used to encrypt the message digest and an electronic timestamp, forming a digital signature, or signature certificate. The sender sends the digital signature along with the message. The receiver receives the message and the digital signature, and recovers the original message digest from the digital signature by decrypting it with the sender's public key. The receiver computes a new message digest from the message, and checks to see if it matches the one recovered from the digital signature. If it matches, then that proves the message was not altered, and it came from the sender who owns the public key used to check the signature. A potential forger would have to either produce an altered message that produces an identical message digest (which is infeasible), or he would have to create a new digital signature from a different message digest (also infeasible, without knowing the true sender's secret key). Digital signatures prove who sent the message, and that the message was not altered either by error or design. It also provides non-repudiation, which means the sender cannot easily disavow his signature on the message. Using message digests to form digital signatures has other advantages besides being faster than directly signing the entire actual message with the secret key. Using message digests allows signatures to be of a standard small fixed size, regardless of the size of the actual message. It also allows the software to check the message integrity automatically, in a manner similar to using checksums. And it allows signatures to be stored separately from messages, perhaps even in a public archive, without revealing sensitive information about the actual messages, because no one can derive any message content from a message digest. The message digest algorithm used here is the MD4 Message Digest Algorithm, placed in the public domain by RSA Data Security, Inc. MD4's designer, Ronald Rivest, writes this about MD4: "It is conjectured that the difficulty of coming up with two messages having the same message digest is on the order of 2^64 operations, and that the difficulty of coming up with any message having a given message digest is on the order of 2^128 operations. The MD4 algorithm has been carefully scrutinized for weaknesses. It is, however, a relatively new algorithm and further security analysis is of course justified, as is the case with any new proposal of this sort. The level of security provided by MD4 should be sufficient for implementing very high security hybrid digital signature schemes based on MD4 and the RSA public-key cryptosystem." PGPGUIDE.TXT Thursday, April 30, 1992 7:43 am Page 26 Vulnerabilities =============== No data security system is inpenetrable. PGP can be circumvented in a variety of ways. In any data security system, you have to ask yourself if the information you are trying to protect is valuable enough to your attacker that the cost of the attack is less than the value of the information. This should lead you to protecting yourself from the cheapest attacks, while not worrying about the more expensive attacks. Some of the discussion that follows may seem unduly paranoid, but such an attitude is appropriate for a reasonable discussion of vulnerability issues. Compromised Pass Phrase and Secret Key -------------------------------------- Probably the simplest attack is if you leave your pass phrase for your secret key written down somewhere. If someone gets it and gets your secret key file, they can read your messages and make signatures in your name. Also, don't use obvious passwords that can be easily guessed, such as the names of your kids or spouse. For further details, see the section "How to Protect Secret Keys from Disclosure". Public Key Tampering -------------------- A major vulnerability exists if public keys are tampered with. This may be the most crucially important vulnerability of a public key cryptosystem, in part because most novices don't immediately recognize it. The importance of this vulnerability, and appropriate hygienic countermeasures, are detailed in this document in the section "How to Protect Public Keys from Tampering". To summarize: When you use someone's public key, make certain it has not been tampered with, before you add it to your own public key ring. A new public key from someone else should be trusted only if you got it directly from its owner, or if it has been signed by someone you trust. Make sure no one else can tamper with your own public key ring. Maintain physical control of both your public key ring and your secret key ring, preferably on your own personal computer rather than on a remote timesharing system. Keep a backup copy of both key rings. "Not Quite Deleted" Files ------------------------- Another potential security problem is caused by how most operating systems delete files. When you encrypt a file and then delete the original plaintext file, the operating system doesn't actually physically erase the data. It merely marks those disk blocks as deleted, allowing the space to be reused later. It's sort of like PGPGUIDE.TXT Thursday, April 30, 1992 7:43 am Page 27 discarding sensitive paper documents in the paper recycling bin instead of the paper shredder. The disk blocks still contain the original sensitive data you wanted to erase, and will probably eventually be overwritten by new data at some point in the future. If an attacker reads these deleted disk blocks soon after they have been deallocated, he could recover your plaintext. In fact this could even happen accidentally, if for some reason something went wrong with the disk and some files were accidentally deleted or corrupted. A disk recovery program may be run to recover the damaged files, but this often means some previously deleted files are resurrected along with everything else. Your confidential files that you thought were gone forever could then reappear and be inspected by whomever is attempting to recover your damaged disk. Even while you are creating the original message with a word processor or text editor, the editor may be creating multiple temporary copies of your text on the disk, just because of its internal workings. These temporary copies of your text are deleted by the word processor when it's done, but these sensitive fragments are still on your disk somewhere. Let me tell you a true horror story. I had a friend, married with young children, who once had a brief and not very serious affair. She wrote a letter to her lover on her word processor, and deleted the letter after she sent it. Later, after the affair was over, the floppy disk got damaged somehow and she had to recover it because it contained other important documents. She asked her husband to salvage the disk, which seemed perfectly safe because she knew she had deleted the incriminating letter. Her husband ran a commercial disk recovery software package to salvage the files. It recovered the files alright, including the deleted letter. He read it, which set off a tragic chain of events. The only way to prevent the plaintext from reappearing is to somehow cause the deleted plaintext files to be overwritten. Unless you know for sure that all the deleted disk blocks will soon be reused, you must take positive steps to overwrite the plaintext file, and also any fragments of it on the disk left by your word processor. You can overwrite the original plaintext file after encryption by using the PGP -w (wipe) option. You can take care of any fragments of the plaintext left on the disk by using any of the disk utilities available that can overwrite all of the unused blocks on a disk. For example, the Norton Utilities for MSDOS can do this. Viruses and Trojan Horses ------------------------- Another attack could involve a specially-tailored hostile computer virus or worm that might infect PGP or your operating system. This hypothetical virus could be designed to capture your pass phrase or secret key or deciphered messages, and covertly write the captured information to a file or send it through a network to the virus's owner. Or it might alter PGP's behavior so that signatures are not properly checked. This attack is cheaper than cryptanalytic attacks. PGPGUIDE.TXT Thursday, April 30, 1992 7:43 am Page 28 Defending against this falls under the catagory of defending against viral infection generally. There are some moderately capable anti-viral products commercially available, and there are hygienic procedures to follow that can greatly reduce the chances of viral infection. A complete treatment of anti-viral and anti-worm countermeasures is beyond the scope of this document. PGP has no defenses against viruses, and assumes your own personal computer is a trustworthy execution environment. If such a virus or worm actually appeared, hopefully word would soon get around warning everyone. Another similar attack involves someone creating a clever imitation of PGP that behaves like PGP in most respects, but doesn't work the way it's supposed to. For example, it might be deliberately crippled to not check signatures properly, allowing bogus key certificates to be accepted. This "Trojan horse" version of PGP is not hard for an attacker to create, because PGP source code is widely available, so anyone could modify the source code and produce a lobotomized zombie imitation PGP that looks real but does the bidding of its diabolical master. This Trojan horse version of PGP could then be widely circulated, claiming to be from me. How insidious. To help protect against viral infection of PGP or later Trojan horse copies of PGP, I included a signature certificate file called PGP.CTX in the MSDOS release of PGP. It bears my signature for the MSDOS executable file PGP.EXE, to assure that PGP.EXE has not been subsequently infected with a virus. To run this self-test of PGP to check its own integrity with my signature certificate, type: pgp pgp.ctx pgp.exe PGP should report a good signature from Philip R. Zimmermann on the PGP.EXE executable program file, which, in theory, indicates your copy of PGP software has no virus infection and has not been tampered with. This will not help at all if your operating system is infected, nor will it detect if your original copy of PGP.EXE has been maliciously altered in such a way as to compromise its own ability to check signatures. This test also assumes that no one has tampered with your copy of my public key. You should try to get at least your first copy of PGP from a trusted reliable source, so that you can use it to check my signature on subsequent releases of PGP. You can keep the older trusted version of PGP around on a write-protected backup floppy, along with a trusted copy of my public key to check signatures on future PGP releases. You'd also have to somehow make sure that my public key (also included in the PGP release) actually belongs to me, so it can be trusted to verify my signature. Make sure that you use this trusted copy of my public key, and not rely on a public key included with a newer release of PGP that may be suspect. Just for good measure, I also included a signature certificate for this document, called PGPGUIDE.CTX. I also included a signature certificate for all the PGP source files in the source release. Be advised that if I'm threatened with legal harrassment to suppress my own participation in future releases of PGP, some PGP users PGPGUIDE.TXT Thursday, April 30, 1992 7:43 am Page 29 (possibly from outside the US) may take it upon themselves to improve PGP and produce a new release of PGP on their own. Thus it is possible that someone else's digital signature will be used instead of mine to certify the new release. In that case, you'll just have to use your own best judgement in deciding whether to trust that person's signature. My own opinion will probably be available as to the quality and integrity of that new release of PGP. Physical Security Breach ------------------------ A physical security breach may allow someone to physically acquire your plaintext files or printed messages. A determined opponent might accomplish this through burglery, trash-picking, unreasonable search and seizure, or bribery, blackmail or infiltration of your staff. Some of these attacks may be especially feasible against grassroots political organizations that depend on a largely volunteer staff. It has been widely reported in the press that the FBI's COINTELPRO program used burglery, infiltration, and illegal bugging against antiwar and civil rights groups. And look what happened at the Watergate Hotel. Don't be lulled into a false sense of security just because you have a cryptographic tool. Cryptographic techniques protect data only while it's encrypted-- direct physical security violations can still compromise plaintext data or written or spoken information. This kind of attack is cheaper than cryptanalytic attacks. Tempest Attacks --------------- Another kind of attack that has been used by well-equipped opponents involves the remote detection of the electromagnetic signals from your computer. This expensive and somewhat labor-intensive attack is probably still cheaper than direct cryptanalytic attacks. An appropriately instrumented van can park near your office and remotely pick up all of your keystrokes and messages displayed on your computer video screen. This would compromise all of your passwords, messages, etc. This attack can be thwarted by properly shielding all of your computer equipment and network cabling so that it does not emit these signals. This shielding technology is known as "Tempest", and is used by some Government agencies and defense contractors. There are hardware vendors who supply Tempest shielding commercially, although it may be subject to some kind of Government licensing. Now why do you suppose the Government would restrict access to Tempest shielding? Traffic Analysis ---------------- Even if the attacker cannot read the contents of your encrypted messages, he may be able to infer at least some useful information by observing where the messages come from and where they are going, the PGPGUIDE.TXT Thursday, April 30, 1992 7:43 am Page 30 size of the messages, and the time of day the messages are sent. This is analogous to the attacker looking at your long distance phone bill to see who you called and when and for how long, even though the actual content of your calls is unknown to the attacker. This is called traffic analysis. PGP alone does not protect against traffic analysis. Solving this problem would require specialized communication protocols designed to reduce exposure to traffic analysis in your communication environment, possibly with some cryptographic assistance. Cryptanalysis ------------- An expensive and formidible cryptanalytic attack could possibly be mounted by someone with vast supercomputer resources, such as a Government intelligence agency. They might crack your RSA key by using some new secret factoring breakthrough. Perhaps so, but it is noteworthy that the US Government trusts the RSA algorithm enough in some cases to use it to protect its own nuclear weapons, according to Ron Rivest. Perhaps the Government has some classified methods of cracking the conventional encryption algorithm used in PGP. This is every cryptographer's worst nightmare. There can be no absolute security guarantees in practical cryptographic implementations. Still, some optimism seems justified. Widely accepted cryptographic design principles were followed in the design of this algorithm. The source code and design are publicly available to facilitate peer review. Even if this algorithm has some subtle unknown weaknesses, the data compression of the plaintext before encryption should greatly reduce those weaknesses. The computational workload to crack it is likely to be more expensive than the value of the message. If your situation justifies worrying about very formidible attacks of this caliber, then perhaps you should contact a data security consultant for some customized data security approaches tailored to your special needs. Boulder Software Engineering, whose address and phone are given at the end of this document, can provide such services. In summary, without good cryptographic protection of your data communications, it may have been practically effortless and perhaps even routine for an opponent to intercept your messages, especially those sent through a modem or E-mail system. If you use PGP and follow reasonable precautions, the attacker will have to expend far more effort and expense to violate your privacy. If you protect yourself against the simplest attacks, and you feel confident that your privacy is not going to be violated by a determined and highly resourceful attacker, then you'll probably be safe using PGP. PGP gives you Pretty Good Privacy. PGPGUIDE.TXT Thursday, April 30, 1992 7:43 am Page 31 Trusting Snake Oil ================== When examining a cryptographic software package, the question always remains, why should you trust this product? Even if you examined the source code yourself, not everyone has the cryptographic experience to judge the security. Even if you are an experienced cryptographer, subtle weaknesses in the algorithms could still elude you. When I was in college in the early seventies, I devised what I believed was a brilliant encryption scheme. A simple pseudorandom number stream was added to the plaintext stream to create ciphertext. This would seemingly thwart any frequency analysis of the ciphertext, and would be uncrackable even to the most resourceful Government intelligence agencies. I felt so smug about my achievement. So cock-sure. Years later, I discovered this same scheme in several introductory cryptography texts and tutorial papers. How nice. Other cryptographers had thought of the same scheme. Unfortunately, the scheme was presented as a simple homework assignment on how to use elementary cryptanalytic techniques to trivially crack it. So much for my brilliant scheme. From this humbling experience I learned how easy it is to fall into a false sense of security when devising an encryption algorithm. Most people don't realize how fiendishly difficult it is to devise an encryption algorithm that can withstand a prolonged and determined attack by a resourceful opponent. Many mainstream software engineers have developed equally naive encryption schemes (often even the very same encryption scheme), and some of them have been incorporated into commercial encryption software packages and sold for good money to thousands of unsuspecting users. This is like selling automotive seat belts that look good and feel good, but snap open in even the slowest crash test. Depending on them may be worse than not wearing seat belts at all. No one suspects they are bad until a real crash. Depending on weak cryptographic software may cause you to unknowingly place sensitive information at risk. You might not otherwise have done so if you had no cryptographic software at all. Perhaps you may never even discover your data has been compromised. Sometimes commercial packages use the Federal Data Encryption Standard (DES), a good conventional algorithm recommended by the Government for commercial use (but not for classified information, oddly enough-- hmmm). There are several "modes of operation" the DES can use, some of them better than others. The Government specifically recommends not using the weakest simplest mode for messages, the Electronic Codebook (ECB) mode. But they do recommend the stronger and more complex Cipher Feedback (CFB) or Cipher Block Chaining (CBC) modes. Unfortunately, most of the commercial encryption packages I've looked at use ECB mode. When I've talked to the authors of a number of PGPGUIDE.TXT Thursday, April 30, 1992 7:43 am Page 32 these implementations, they say they've never heard of CBC or CFB modes, and didn't know anything about the weaknesses of ECB mode. The very fact that they haven't even learned enough cryptography to know these elementary concepts is not reassuring. These same software packages often include a second faster encryption algorithm that can be used instead of the slower DES. The author of the package often thinks his proprietary faster algorithm is as secure as the DES, but after questioning him I usually discover that it's just a variation of my own brilliant scheme from college days. Or maybe he won't even reveal how his proprietary encryption scheme works, but assures me it's a brilliant scheme and I should trust it. I'm sure he believes that his algorithm is brilliant, but how can I know that without seeing it? In all fairness I must point out that in most cases these products do not come from companies that specialize in cryptographic technology. There is a company called AccessData (87 East 600 South, Orem, Utah 84058, phone 1-800-658-5199) that sells a package for $185 that will crack the built-in encryption schemes used by WordPerfect, Lotus 1-2-3, MS Excel, Symphony, Quattro Pro, Paradox, and MS Word 2.0. It doesn't simply guess passwords-- it does real cryptanalysis. Some people buy it when they forget their password for their own files. Law enforcement agencies buy it too, so they can read files they seize. I talked to Eric Thompson, the author, and he said his program only takes a split second to crack them, but he put in some delay loops to slow it down so it doesn't look so easy to the customer. He also told me that the password encryption feature of PKZIP files can be easily broken, and that his law enforcement customers already have that service regularly provided to them from another vendor. In some ways, cryptography is like pharmaceuticals. Its integrity may be absolutely crucial. Bad penicillin looks the same as good penicillin. You can tell if your spreadsheet software is wrong, but how do you tell if your cryptography package is weak? The ciphertext produced by a weak encryption algorithm looks as good as ciphertext produced by a strong encryption algorithm. There's a lot of snake oil out there. A lot of quack cures. Unlike the patent medicine hucksters of old, these software implementors usually don't even know their stuff is snake oil. They may be good software engineers, but they usually haven't even read any of the academic literature in cryptography. But they think they can write good cryptographic software. And why not? After all, it seems intuitively easy to do so. And their software seems to work okay. Anyone who thinks they have devised an unbreakable encryption scheme either is an incredibly rare genius or is naive and inexperienced. I remember a conversation with Brian Snow, a highly placed senior cryptographer with the NSA. He said he would never trust an encryption algorithm designed by someone who had not "earned their bones" by first spending a lot of time cracking codes. That did make a lot of sense. I observed that practically no one in the commercial world of cryptography qualified under this criterion. "Yes", he said with a self assured smile, "And that makes our job at NSA so much PGPGUIDE.TXT Thursday, April 30, 1992 7:43 am Page 33 easier." A chilling thought. I didn't qualify either. The Government has peddled snake oil too. After World War II, the US sold German Enigma ciphering machines to third world governments. But they didn't tell them that the Allies cracked the Enigma code during the war, a fact that remained classified for many years. Even today many Unix systems worldwide use the Enigma cipher for file encryption, in part because the Government has created legal obstacles against using better algorithms. They even tried to prevent the initial publication of the RSA algorithm in 1977. And they have squashed essentially all commercial efforts to develop effective secure telephones for the general public. The principle job of the US Government's National Security Agency is to gather intelligence, principally by covertly tapping into people's private communications (see James Bamford's book, "The Puzzle Palace"). The NSA has amassed considerable skill and resources for cracking codes. When people can't get good cryptography to protect themselves, it makes NSA's job much easier. NSA also has the responsibility of approving and recommending encryption algorithms. Some critics charge that this is a conflict of interest, like putting the fox in charge of guarding the henhouse. NSA has been pushing a conventional encryption algorithm that they designed, and they won't tell anybody how it works because that's classified. They want others to trust it and use it. But any cryptographer can tell you that a well-designed encryption algorithm does not have to be classified to remain secure. Only the keys should need protection. How does anyone else really know if NSA's classified algorithm is secure? It's not that hard for NSA to design an encryption algorithm that only they can crack, if no one else can review the algorithm. Are they deliberately selling snake oil? I'm not as cock-sure about the security of PGP as I once was about my brilliant encryption software from college. If I were, that would be a bad sign. But I'm pretty sure that PGP does not contain any glaring weaknesses. Source code is available to facilitate peer review and to help dispel the fears of some users. It's reasonably well researched. It's based on the work of a number of reputable cryptographers. It's been years in the making. And I don't work for the NSA. I hope it doesn't require a large "leap of faith" to trust the security of PGP. PGPGUIDE.TXT Thursday, April 30, 1992 7:43 am Page 34 PGP Quick Reference =================== Here's a quick summary of PGP commands. To encrypt a plaintext file with the recipent's public key: pgp -e textfile her_userid To sign a plaintext file with your secret key: pgp -s textfile your_userid To sign a plaintext file with your secret key, and then encrypt it with the recipent's public key: pgp -es textfile her_userid your_userid To encrypt a plaintext file with just conventional cryptography, type: pgp -c textfile To decrypt an encrypted file, or to check the signature integrity of a signed file: pgp ciphertextfile [plaintextfile] To generate your own unique public/secret key pair: pgp -k To add a public or secret key file's contents to your public or secret key ring: pgp -a keyfile [keyring] To remove a key from your public key ring: pgp -r userid [keyring] To view the contents of your public key ring: pgp -v [userid] [keyring] To create a signature certificate that is detached from the document: pgp -sb textfile your_userid To produce a ciphertext file in Unix uuencode format, just add the "u" option when encrypting or signing a message: pgp -esu textfile her_userid your_userid To wipe out the plaintext file after producing the ciphertext file, just add the "w" (wipe) option when encrypting or signing a message: pgp -esw message.txt her_userid your_userid PGPGUIDE.TXT Thursday, April 30, 1992 7:43 am Page 35 Legal Issues ============ Trademarks, Copyrights, and Warranties -------------------------------------- "Pretty Good Privacy", "Phil's Pretty Good Software", and the "Pretty Good" label for computer software and hardware products are all trademarks of Philip Zimmermann and Phil's Pretty Good Software. PGP is (c) Copyright Philip R. Zimmermann, 1990. The author assumes no liability for damages resulting from the use of this software, even if the damage results from defects in this software, and makes no representations concerning the merchantability of this software or its suitability for any specific purpose. It is provided "as is" without express or implied warranty of any kind. Patent Rights on the Algorithms ------------------------------- When I first released PGP, I half-expected to encounter some form of legal harrassment from the Government. Indeed, there has been legal harrassment, but it hasn't come from the Government-- it has come from a private corporation. The RSA public key cryptosystem was developed at MIT with Federal funding from grants from the National Science Foundation and the Navy. It is patented by MIT (U.S. patent #4,405,829, issued 20 Sep 1983). A company in California called Public Key Partners (PKP) holds the exclusive commercial license to sell and sub-license the RSA public key cryptosystem. The author of this software implementation of the RSA algorithm is providing this implementation for educational use only. Licensing this algorithm from PKP is the responsibility of you, the user, not Philip Zimmermann, the author of this software implementation. The author assumes no liability for any patent infringement that may result from the unlicensed use by the user of the underlying RSA algorithm used in this software. Foreign users should note that the RSA patent does not apply outside the US, and there is no RSA patent in any other country. Federal agencies may use it because the Government paid for the development of RSA. Unfortunately, PKP is not offering any licensing of their RSA patent to end users of PGP. This essentially makes PGP contraband in the USA. Jim Bidzos, president of PKP, has threatened to take legal action against me unless I stop distributing PGP, until they can devise a licensing scheme for it. I agreed to this, since PGP is already in wide circulation and waiting a while for a licensing arrangement from PKP seemed reasonable. Mr. Bidzos assured me (he even used the word "promise") several times since the initial 5 June 91 release of PGP that they were working on a licensing scheme for PGP. Apparently, my release of PGP provided the impetus for them to offer some sort of a freeware-style license for noncommercial use of the RSA algorithm. However, in December 1991 Mr. Bidzos said he had PGPGUIDE.TXT Thursday, April 30, 1992 7:43 am Page 36 no plans to ever license the RSA algorithm to PGP users. He denies ever implying that he would. Meanwhile, I have continued to refrain from distributing PGP. I wrote my PGP software from scratch, with my own implementation of the RSA algorithm. I didn't steal any software from PKP. Before publishing PGP, I got a formal written legal opinion from a patent attorney with extensive experience in software patents. I'm convinced that publishing PGP the way I did does not violate patent law. However, it is a well known axiom in the US legal system that regardless of the law, he with the most money and lawyers prevails, if not by actually winning then by crushing the little guy with legal expenses. Not only did PKP acquire the exclusive patent rights for the RSA cryptosystem, which was developed with your tax dollars, but they also somehow acquired the exclusive rights to three other patents covering rival public key schemes invented by others, also developed with your tax dollars. This essentially gives one company a legal lock in the USA on nearly all practical public key cryptosystems. They even appear to be claiming patent rights on the very concept of public key cryptography, regardless of what clever new original algorithms are independently invented by others. And you thought patent law was designed to encourage innovation! PKP does not actually develop any software-- they don't even have an engineering department-- they are essentially a litigation company. Public key cryptography is destined to become a crucial technology in the protection of our civil liberties and privacy in our increasingly connected society. Why should the Government try to limit access to this key technology, when a single monopoly can do it for them? It appears certain that there will be future releases of PGP, regardless of the outcome of licensing problems with Public Key Partners. If PKP does not license PGP, then future releases of PGP might not come from me. There are countless fans of PGP outside the US, and many of them are software engineers who want to improve PGP and promote it, regardless of what I want to do. I am told by many foreign users that if it seems necessary to them, future releases of PGP will come from outside the US, out of reach of US patent laws, and there's nothing I can do to stop it. The LZHuf compression routines in PGP come from public domain source code. I'm not aware of any patents on the LZHuf algorithm, but I've heard that a related compression algorithm, LZW, has some patent claims from Unisys Corporation. LZHuf is different from LZW, and might not be affected by this patent. If you're interested, you're welcome to look into this murky issue yourself. If there are any patent claims that apply to LZHuf, then sorry, you'll have to take care of the patent licensing, not me. All this patent stuff reminds me of a Peanuts cartoon I saw in the newspaper where Lucy showed Charlie Brown a fallen autumn leaf and said "This is the first leaf to fall this year." Charlie Brown said, "How do you know that? Leaves have been falling for weeks." Lucy replied, "I had this one notarized." PGPGUIDE.TXT Thursday, April 30, 1992 7:43 am Page 37 Licensing and Distribution -------------------------- In the USA PKP controls, through US patent law, the licensing of the RSA algorithm. But I have no objection to anyone freely using or distributing my PGP software, without payment of fees to me (except as provided below). You must keep the copyright notices on PGP and keep this documentation with it. However, if you live in the USA, this may not satisfy any legal obligations you may have to PKP for using the RSA algorithm as mentioned above. In fact, if you live in the USA, and you are not a Federal agency, you shouldn't actually run PGP on your computer, because Public Key Partners wants to forbid you from running my software. PGP is contraband. Of course, I can't give any assurances, but my guess is that it seems unlikely that PKP would waste their time pursuing PGP end users for patent infringement. There are just too many PGP users to go after. And why would they single you out? But I certainly wouldn't want to imply that you do anything improper-- if PKP were offering licenses, I would urge you to obtain one. But since they aren't, well, I guess you should just refrain from using PGP if you live in the USA. PGP is not shareware, it's freeware. Forbidden freeware. Published as a community service. If I sold PGP for money, then I would get sued by PKP for using their RSA algorithm. More importantly, giving PGP away for free will encourage far more people to use it, which hopefully will have a greater social impact. This could lead to widespread awareness and use of the RSA public key cryptosystem, which will probably make more money for PKP in the long run. If only they could see that. All the source code for PGP is available for free under the "Copyleft" General Public License from the Free Software Foundation (FSF). A copy of the FSF General Public License is included in the source release package of PGP. Regardless of and perhaps contrary to some provisions of the FSF General Public License, the following terms apply: 1) Written discussions of PGP in magazines or books may include fragments of PGP source code and documentation, without restrictions. 2) If somehow PKP ever licenses their patent to PGP users for a fee, and you are able and willing to pay PKP a license fee for the RSA algorithm, then I guess that sort of makes PGP not exactly free, doesn't it? If you decide to do that, then I'm asking for a matching donation (or $50, whichever is less) from each end user that pays PKP a license fee. 3) Although the FSF General Public License allows non-proprietary derivative products, it prohibits proprietary derivative products. PGPGUIDE.TXT Thursday, April 30, 1992 7:43 am Page 38 Despite this, I may grant you a special license if you want to derive a proprietary commercial product from some of PGP's parts. There may or may not be a fee depending on what kind of a deal you plan to pursue with PKP. Retaining my copyright notice and attribution might suffice in some cases. Give me a call and we'll discuss it. I'm real easy to please. Feel free to disseminate the complete PGP release package as widely as possible. Give it to all your friends. If you have access to any electronic Bulletin Boards Systems, please upload the complete PGP executable object release package to as many BBS's as possible. You may disseminate the PGP source release package too, if you've got it. The PGP version 1.0 executable object release package for MSDOS contains the PGP executable software, documentation, sample keyrings including my own public key, and signatures for the software and this manual, all in one PKZIP compressed file called PGP10.ZIP. The PGP source release package for MSDOS contains all the C source files in one PKZIP compressed file called PGP10SRC.ZIP. You may obtain free copies or updates to PGP from thousands of BBS's worldwide or from other public sources such as Internet FTP sites. Don't ask me for a copy directly from me, since I'd rather avoid further legal problems with PKP at this time. I might be able to tell you where you can get it, however. After all this work I have to admit I wouldn't mind getting some fan mail for PGP, to gauge its popularity. Let me know what you think about it and how many of your friends use it. Bug reports and suggestions for enhancing PGP are welcome, too. Perhaps a future PGP release will reflect your suggestions. This project has not been funded and the project has nearly eaten me alive. This means you can't count on a reply to your mail, unless you only need a short written reply and you include a stamped self-addressed envelope. But I do reply to E-mail. Please keep it in English, as my foreign language skills are weak. If you call and I'm not in, it's best to just try again later. I usually don't return long distance phone calls, unless you leave a message that I can call you collect. If you need any significant amount of my time, I am available on a paid consulting basis, and I do return those calls. The most inconvenient mail I get is for some well-intentioned person to send me a few dollars asking me for a copy of PGP. I can't send it to them because of the legal threats from PKP (or worse-- sometimes these requests are from foreign countries, and I would be risking violating cryptographic export control laws). Even if there were no legal hassles involved in sending PGP to them, they usually don't send enough money to make it worth my time, because I'm just not set up as a low cost low volume mail order business. I can't just ignore the request and keep the money, because they probably regard the money as a fee for me to fulfill their request. If I return the money, I might have to get in my car and drive down to the post office and buy some postage stamps, because these requests rarely include a stamped self-addressed envelope. And I have to take the time to write a polite reply that I can't do it. If I postpone the reply and set the letter down on my desk, it might be buried within PGPGUIDE.TXT Thursday, April 30, 1992 7:43 am Page 39 minutes and won't see the light of day again for months. Multiply these minor inconveniences by the number of requests I get, and you can see the problem. It would be nicer if people could try to get PGP from any of the myriad other sources. If you can't find it yourself, I don't mind answering a quick phone call. If anyone wants to volunteer to improve PGP, please let me know. It could certainly use some more work. Some features were deferred to get it out the door. A number of PGP users have since donated their time to port PGP to Unix on Sun SPARCstations, to Ultrix, to VAX/VMS, to OS/2, to the Amiga, and to the Atari ST. Perhaps you can help port it to some new environments, such as the Apple Macintosh, MS Windows, X windows, or XVT. But please let me know if you plan to port PGP, to avoid duplication of effort, and to avoid starting with an obsolete version of the source code. This is the first release of PGP. Future versions of PGP may have to change the data formats for messages, signatures, keys and key rings, in order to provide important new features. This may cause backward compatibility problems with this version of PGP. Future releases may provide conversion utilities to convert old keys if this is practical, but you may have to generate new keys and dispose of old messages created with the old PGP. Such a conversion effort hopefully will have to be done only once, if at all. Export Controls --------------- The Government has made it illegal in many cases to export good cryptographic technology, and that may include PGP. They regard this kind of software as munitions. This is determined by volatile State Department policies, not fixed laws. I will not export this software out of the US or Canada in cases when it is illegal to do so under US State Department policies, and I assume no responsibility for other people exporting it on their own. If you live outside the US or Canada, I advise you not to violate US State Department policies by getting PGP from a US source. Since thousands of domestic users got it after its initial publication, it somehow leaked out of the US and spread itself widely abroad. If PGP has already found its way into your country, then I don't think you're violating US export law if you pick it up from a source outside of the US. Many foreign governments impose serious penalties on anyone inside their country using encrypted communications. In some countries they might even shoot you for that. Acknowledgements ================ PGPGUIDE.TXT Thursday, April 30, 1992 7:43 am Page 40 I'd like to thank the following people for their contributions to the creation of Pretty Good Privacy. Charlie Merritt designed the prototypic conventional encryption algorithm and taught me how to do decent multiprecision arithmetic. Zhahai Stewart wrote some 8086 assembly primitives and gave many helpful suggestions on PGP file formats and on the conventional encryption algorithm. Allan Hoeltje integrated the LZHuf compression routines into PGP. These were developed and placed in the public domain by Haruyasu Yoshizaki and Haruhiko Okumura. The MD4 routines were developed and placed in the public domain by Ron Rivest. The idea of introducers came from Whit Diffie. Kelly Goen did most of the work for the initial electronic publication of PGP. Charlie Merritt can be reached at PO Box 317, West Fork, AR 72774. Zhahai Stewart can be reached at 6521 Old Stage Rd, Boulder, CO 80302. Allan Hoeltje can be reached at PO Box 18045, Boulder, CO 80308. PGPGUIDE.TXT Thursday, April 30, 1992 7:43 am Page 41 Recommended Readings ==================== 1) Dorothy Denning, "Cryptography and Data Security", Addison-Wesley, Reading, MA 1982 2) Dorothy Denning, "Protecting Public Keys and Signature Keys", IEEE Computer, Feb 1983 3) Philip Zimmermann, "A Proposed Standard Format for RSA Cryptosystems", IEEE Computer, Sep 1986 4) Ronald Rivest, "The MD4 Message Digest Algorithm", MIT Laboratory for Computer Science, 1990 About the Author ================ Philip Zimmermann is a software engineer consultant with 17 years experience, specializing in embedded real-time systems, cryptography, authentication, and data communications. Experience includes design and implementation of authentication systems for financial information networks, network data security, key management protocols, embedded real-time multitasking executives, operating systems, and local area networks. Custom versions of public key implementations are available from Zimmermann, as well as other cryptography and authentication products and custom product development services. His consulting firm's address is: Boulder Software Engineering 3021 Eleventh Street Boulder, Colorado 80304 USA Phone 303-444-4541 (10:00am - 7:00pm Mountain Time) FAX 303-444-4541 ext 10 Internet: prz@sage.cgd.ucar.edu PGPGUIDE.TXT Thursday, April 30, 1992 7:43 am Page 42 Appendix A: Where to Get PGP ============================= From: Philip Zimmermann, prz@sage.cgd.ucar.edu To: People interested in PGP (Pretty Good Privacy) Re: Where to get PGP This memo describes how to get the freeware public key cryptographic software PGP (Pretty Good Privacy) from an anonymous FTP site on Internet, or from any other source. PGP has sophisticated key management, an RSA/conventional hybrid encryption scheme, message digests for digital signatures, data compression before encryption, and good ergonomic design. PGP is well featured and fast, and has excellent user documentation. Source code is free. What follows is a sample of places that allegedly have PGP. This information is not guaranteed to be correct. If you care to set up any additional reliable FTP sites, please let me know about it, including the host name and directory. PGP uses the RSA cryptosystem which is claimed by a US patent held by a company called Public Key Partners. PGP users outside the US take note that there is no RSA patent outside the US. Bear in mind that there are US and Canadian export laws prohibiting anyone inside the US and Canada from exporting cryptographic software like this. If you live in another country, you are advised not to violate US export laws by copying these files from a US source. Since thousands of US users got it, it has somehow leaked out of the US and spread itself worldwide. If PGP has already found its way into your country, then you're probably not violating US export law if you pick it up from a source outside of the US. For those of you who need to obtain PGP from sources outside the US, some foreign sources are listed. There are two compressed achive files in the PGP MSDOS release. You must get pgp10.zip which contains the binary executable and the PGP User's Guide, and you can optionally get pgp10src.zip which contains only the source files, with no user documentation. These files can be decompressed with the MSDOS shareware archive decompression utility PKUNZIP.EXE. A reminder: Set mode to binary or image when doing an FTP transfer. Here are some FTP sites that have both pgp10.zip and pgp10src.zip: HOST DIRECTORY USA: uunet.uu.net (137.39.1.2) /tmp pc.usl.edu (130.70.40.3) /pub/msdos/crypto gatekeeper.dec.com (16.1.0.2) /pub/micro/msdos/pgp ucbarpa.berkeley.edu (128.32.130.11) /pub New Zealand: kauri.vuw.ac.nz /pub/ms-dos/Encryption PGPGUIDE.TXT Thursday, April 30, 1992 7:43 am Page 43 Here are some FTP sites that have pgp10.zip: Finland: garbo.uwasa.fi (128.214.87.1) /pc/fileutil Australia: sol.deakin.oz.au (128.184.1.1) /pub/PC/chyde/fileutil PGP is also available on PeaceNet and EcoNet, run by IGC in San Francisco. Log in and check the "micro" conference. The Web in Canada also has it. It's also available on Compuserve. PGP is also widely available on Fidonet, a large informal network of PC-based bulletin board systems interconnected via modems. Check your local bulletin board systems. It is available on many foreign and domestic Fidonet BBS sites. In the US, PGP may be found on God knows how many BBS systems, far too many to list here. Still, if you don't have any local BBS phone numbers handy, here are some free little BBS's in Colorado you might try: 303 443-8292, or 303 652-3595, or 303 231-0990. In Toronto Canada, try this BBS: 416 798-4786 In New Zealand, try these (supposedly free) dial-up BBS systems: Amstrad BBS: +64 9 445-3619 Infoboard: +64 9 833-8788 Kappa Crucis: +64 9 817-3714, -3725, -3324, -8424, -3094, -3393 In the Netherlands there is a BBS called Operation Hacker Storm that is pushing PGP pretty heavily. The phone number is: +31 22 3060551 Here are a few people and their email addresses or phone numbers you can contact in some countries to get information on local PGP availability: Peter Gutmann Hugh Kennedy pgut1@cs.aukuni.ac.nz 70042.710@compuserve.com New Zealand Germany Branko Lankester Miguel Angel Gallardo lankeste@fwi.uva.nl gallardo@batman.fi.upm.es +31 2159 42242 (341) 474 38 09 The Netherlands Spain Patrick Oonk Jean-loup Gailly patrick@utopia.hacktic.nl jloup@chorus.fr The Netherlands France Michael Weiner Hugh Miller mweiner@bene.co.at hmiller@lucpul.it.luc.edu Fidonet: 2:310/11.123 (312) 508-2727 Austria USA