--- pgp/doc/pgpdoc2.txt 2018/04/24 16:39:43 1.1 +++ pgp/doc/pgpdoc2.txt 2018/04/24 16:43:57 1.1.1.5 @@ -1,42 +1,43 @@ + + Phil's Pretty Good Software Presents - === - PGP - === + ======= + PGP(tm) + ======= - Pretty Good Privacy + Pretty Good(tm) Privacy Public Key Encryption for the Masses ------------------------- - PGP User's Guide - Volume II: Special Topics + PGP(tm) User's Guide + Volume II: Special Topics ------------------------- - by Philip Zimmermann - Revised 6 Mar 93 + by Philip Zimmermann + Revised 31 August 94 - PGP Version 2.2 - 6 Mar 93 - Software by - Philip Zimmermann - with - Branko Lankester, Hal Finney, and Peter Gutmann + PGP Version 2.6.1 - 30 Aug 94 + Software by + Philip Zimmermann, and many others. -Synopsis: PGP uses public-key encryption to protect E-mail and data -files. Communicate securely with people you've never met, with no -secure channels needed for prior exchange of keys. PGP is well +Synopsis: PGP(tm) uses public-key encryption to protect E-mail and +data files. 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. -Software and documentation (c) Copyright 1990-1993 Philip Zimmermann. -For information on PGP licensing, distribution, copyrights, patents, -trademarks, liability limitations, and export controls, see the -"Legal Issues" section. +Software and documentation (c) Copyright 1990-1994 Philip Zimmermann. +All rights reserved. For information on PGP licensing, distribution, +copyrights, patents, trademarks, liability limitations, and export +controls, see the "Legal Issues" section. Distributed by the +Massachusetts Institute of Technology. Contents @@ -56,8 +57,9 @@ Special Topics Editing the Trust Parameters for a Public Key Checking If Everything is OK on Your Public Key Ring Verifying a Public Key Over the Phone + Handling Large Public Keyrings Using PGP as a Unix-style Filter - Suppressing Unneccessary Questions: BATCHMODE + Suppressing Unnecessary Questions: BATCHMODE Force "Yes" Answer to Confirmation Questions: FORCE PGP Returns Exit Status to the Shell Environmental Variable for Pass Phrase @@ -75,19 +77,22 @@ Special Topics MARGINALS_NEEDED - Number of Marginally Trusted Introducers Needed CERT_DEPTH - How Deep May Introducers Be Nested BAKRING - Filename for Backup Secret Keyring + PUBRING - Filename for Your Public Keyring + SECRING - Filename for Your Secret Keyring + RANDSEED - Filename for Random Number Seed PAGER - Selects Shell Command to Display Plaintext Output SHOWPASS - Echo Pass Phrase to User TZFIX - Timezone Adjustment CLEARSIG - Enable Signed Messages to be Encapsulated as Clear Text VERBOSE - Quiet, Normal, or Verbose Messages INTERACTIVE - Ask for Confirmation for Key Adds - Protecting Against Bogus Timestamps + NOMANUAL - Let PGP Generate Keys Without the Manual A Peek Under the Hood Random Numbers PGP's Conventional Encryption Algorithm Data Compression Message Digests and Digital Signatures - Compatibility with Previous Versions of PGP + Compatibility with Previous and Future Versions of PGP Vulnerabilities Compromised Pass Phrase and Secret Key Public Key Tampering @@ -97,20 +102,29 @@ Vulnerabilities Tempest Attacks Exposure on Multi-user Systems Traffic Analysis + Protecting Against Bogus Timestamps Cryptanalysis Legal Issues Trademarks, Copyrights, and Warranties Patent Rights on the Algorithms - Licensing and Distribution + Freeware Status and Restrictions + Restrictions on Commercial Use of PGP + Other Licensing Restrictions + Distribution Export Controls -Computer-Related Political Groups -Recommended Readings -To Contact the Author + Philip Zimmermann's Legal Situation +Other Sources of Information on PGP + Where to Get a Commercial Version of PGP + Reporting PGP Bugs + Fan Mail, Updates, and News + Computer-Related Political Groups + Recommended Readings + To Contact the Author Appendix A: Where to Get PGP Quick Overview -============= +============== Pretty Good(tm) Privacy (PGP), from Phil's Pretty Good Software, is a high security cryptographic software application for MSDOS, Unix, @@ -124,7 +138,8 @@ This volume II of the PGP User's Guide c PGP that were not covered in the "PGP User's Guide, Volume I: Essential Topics". You should first read the Essential Topics volume, or this manual won't make much sense to you. Reading this -Special Topics volume is optional. +Special Topics volume is optional, except for the legal issues +section, which everyone should read. @@ -328,7 +343,7 @@ Making a Message For Her Eyes Only ---------------------------------- To specify that the recipient's decrypted plaintext will be shown -ONLY on her screen and cannot be saved to disk, add the -m option: +ONLY on her screen and will not be saved to disk, add the -m option: pgp -sem message.txt her_userid @@ -345,6 +360,10 @@ feature was added at the request of a us intimate messages to his lover, but was afraid she might accidentally leave the decrypted messages on her husband's computer. +Note that this feature will not prevent a clever and determined +person from finding a way to save the decrypted plaintext to disk-- +it's to help prevent a casual user from doing it inadvertently. + Preserving the Original Plaintext Filename @@ -365,7 +384,7 @@ encrypts the plaintext. Normally, this discarded by PGP when it decrypts, but you can tell PGP you want to preserve the original plaintext filename and use it as the name of the decrypted plaintext output file. This is useful if PGP is used -to on files whose names are important to preserve. +on files whose names are important to preserve. To recover the original plaintext filename while decrypting, add the -p option, like so: @@ -391,12 +410,25 @@ you may be known by more than one name o title. PGP lets you attach more than one user ID to your key, any one of which may be used to look up your key on the key ring. -To edit your userid or pass phrase for your secret key: +To edit your own userid or pass phrase for your secret key: pgp -ke userid [keyring] PGP prompts you for a new user ID or a new pass phrase. +If you edit your user ID, PGP actually adds a new user ID, without +deleting the old one. If you want to delete an old user ID, you will +have to do that in a separate operation. + +The optional [keyring] parameter, if specified, must be a public +keyring, not a secret keyring. The userid field must be your own +userid, which PGP knows is yours because it appears on both your +public keyring and your secret keyring. Both keyrings will be +updated, even though you only specified the public keyring. + +The -ke command works differently depending on whether you use it on +a public or secret key. It can also be used to edit the trust +parameters for a public key. Editing the Trust Parameters for a Public Key @@ -412,6 +444,9 @@ To edit the trust parameters for a publi pgp -ke userid [keyring] +The optional [keyring] parameter, if specified, must be a public +keyring, not a secret keyring. + Checking If Everything is OK on Your Public Key Ring @@ -469,6 +504,65 @@ You can both verify each other's keys th each other's keys with confidence. This is a safe and convenient way to get the key trust network started for your circle of friends. +Note that sending a key fingerprint via E-mail is not the best way to +verify the key, because E-mail can be intercepted and modified. It's +best to use a different channel than the one that was used to send +the key itself. A good combination is to send the key via E-mail, +and the key fingerprint via a voice telephone conversation. Some +people distribute their key fingerprint on their business cards, +which looks really cool. + +For current versions of PGP, the key fingerprint is computed using +the MD5 hash function. A future version of PGP will optionally use a +new and different hash function, SHA, instead of MD5. + +If you don't know me, please don't call me to verify my key over the +phone-- I get too many calls like that. Since every PGP user has a +copy of my public key, no one could tamper with all the copies that +are out there. The discrepancy would soon be noticed by someone who +checked it from more than one source, and word would soon get out on +the Internet. + +For those of you who want to verify my public key (included in the +standard PGP release package), here are the particulars: + + UserID: "Philip R. Zimmermann " + Key Size: 1024 bits; Creation date: 21 May 1993; KeyID: C7A966DD + Key fingerprint: 9E 94 45 13 39 83 5F 70 7B E7 D8 ED C4 BE 5A A6 + +The information printed above conceivably could still be tampered +with in the electronic distribution of the PGP User's Guide. But if +you read this in the printed version of the manual, available in +bookstores from MIT Press, it's a safe bet that it really is my own +key's fingerprint. + + +Handling Large Public Keyrings +------------------------------ + +PGP was originally designed for handling small personal keyrings for +keeping all your friends on, like a personal rolodex. A couple +hundred keys is a reasonable size for such a keyring. But as PGP has +become more popular, people are now trying to add other large +keyrings to their own keyring. Sometimes this involves adding +thousands of keys to your keyring. PGP, in its present form, cannot +perform this operation in a reasonable period of time, while you wait +at your keyboard. Not for huge keyrings. + +You may want to add a huge "imported" keyring to your own keyring, +because you are only interested in a few dozen keys on the bigger +keyring you are bringing in. If that's all you want from the other +keyring, it would be more efficient if you extract the few keys you +need from the big foreign keyring, and then add just these few keys +to your own keyring. Use the -kx command to extract them from the +foreign keyring, specifying the keyring name on the command line. +Then add these extracted keys to your own keyring. + +The real solution is to improve PGP to use advanced database +techniques to manage large keyrings efficiently. We are working on +this, and should have it done Real Soon Now. Until this happens, you +will just have to use smaller keyrings, or be patient. + Using PGP as a Unix-style Filter @@ -497,12 +591,11 @@ pass phrase, so that you won't be prompt feature is explained below. - -Suppressing Unneccessary Questions: BATCHMODE +Suppressing Unnecessary Questions: BATCHMODE ---------------------------------------------- With the BATCHMODE flag enabled on the command line, PGP will not ask -any unneccessary questions or prompt for alternate filenames. Here +any unnecessary questions or prompt for alternate filenames. Here is an example of how to set this flag: pgp +batchmode cipherfile @@ -593,6 +686,15 @@ it in an environment where someone else machine. Someone could come along and simply ask your computer to display the contents of PGPPASS. +Sometimes you want to pass the pass phrase into PGP from another +application, such as an E-mail package. In some cases, it may not +always be desirable to use the PGPPASS variable for that purpose. +There is another way to pass your pass phrase into PGP from another +application. Use the "-z" command line option. This option is +designed primarily for invoking PGP from inside an E-mail package. +The pass phrase follows the -z option on the command line. There are +risks associated with using this approach, similar to those risks +described above for using the PGPPASS variable. Setting Configuration Parameters: CONFIG.TXT @@ -722,7 +824,9 @@ before encrypting it. Canonical text ha linefeed at the end of each line of text. This mode will be automatically turned off if PGP detects that the -plaintext file contains what it thinks is non-text binary data. +plaintext file contains what it thinks is non-text binary data. If +you intend to use PGP primarily for E-mail purposes, you should turn +TEXTMODE=ON. For VAX/VMS systems, the current version of PGP defaults TEXTMODE=ON. @@ -776,8 +880,8 @@ line option. If enabled, it causes PGP ASCII Radix-64 format suitable for transporting through E-mail channels. Output files are named with the ".asc" extension. -If you tend to use PGP mostly for E-mail, it may be a good idea to -enable this parameter. +If you intend to use PGP primarily for E-mail purposes, you should +turn ARMOR=ON. For further details, see the section "Sending Ciphertext Through E-mail Channels: Radix-64 Format" in the Essential Topics volume. @@ -800,7 +904,7 @@ The configuration parameter ARMORLINES s of lines to make each chunk in a multipart ".asc" file sequence. If you set it to zero, PGP will not break up the file into chunks. -Fidonet email files usually have an upper limit of about 32K bytes, +Fidonet E-mail files usually have an upper limit of about 32K bytes, so 450 lines would be appropriate for Fidonet environments. For further details, see the section "Sending Ciphertext Through @@ -919,6 +1023,58 @@ from Tampering" and "How Does PGP Keep T Valid?" in the Essential Topics volume. +PUBRING - Filename for Your Public Keyring +------------------------------------------ + +Default setting: PUBRING = "$PGPPATH/pubring.pgp" + +You may want to keep your public keyring in a directory separate from +your config.txt file in the directory specified by your $PGPPATH +environmental variable. You may specify the full path and filename +for your public keyring by setting the PUBRING parameter. For +example, on an MSDOS system, you might want to keep your public +keyring on a floppy disk by: + + PUBRING = "a:pubring.pgp" + +This feature is especially handy for specifying an alternative +keyring on the command line. + + +SECRING - Filename for Your Secret Keyring +------------------------------------------ + +Default setting: SECRING = "$PGPPATH/secring.pgp" + +You may want to keep your secret keyring in a directory separate from +your config.txt file in the directory specified by your $PGPPATH +environmental variable. This comes in handy for putting your secret +keyring in a directory or device that is more protected than your +public keyring. You may specify the full path and filename for your +secret keyring by setting the SECRING parameter. For example, on an +MSDOS system, you might want to keep your secret keyring on a floppy +disk by: + + SECRING = "a:secring.pgp" + + +RANDSEED - Filename for Random Number Seed +------------------------------------------ + +Default setting: RANDSEED = "$PGPPATH/randseed.bin" + +You may want to keep your random number seed file (for generation of +session keys) in a directory separate from your config.txt file in +the directory specified by your $PGPPATH environmental variable. +This comes in handy for putting your random number seed file in a +directory or device that is more protected than your public keyring. +You may specify the full path and filename for your random seed file +by setting the RANDSEED parameter. For example, on an MSDOS system, +you might want to keep it on a floppy disk by: + + RANDSEED = "a:randseed.bin" + + PAGER - Selects Shell Command to Display Plaintext Output --------------------------------------------------------- @@ -1019,25 +1175,33 @@ For Aukland: SET TZ=NZT-13 CLEARSIG - Enable Signed Messages to be Encapsulated as Clear Text ------------------------------------------------------------------ -Default setting: CLEARSIG = off +Default setting: CLEARSIG = on Normally, unencrypted PGP signed messages have a signature -certificate prepended in binary form. To send this through a 7-bit -E-mail channel, radix-64 ASCII armor is applied (see the ARMOR -parameter), rendering the message unreadable to casual human eyes, -even though the message is not actually encrypted. The recipient -must use PGP to strip the armor off before reading the message. +certificate prepended in binary form. Also, the signed message is +compressed, rendering the message unreadable to casual human eyes, +even though the message is not actually encrypted. To send this +binary data through a 7-bit E-mail channel, radix-64 ASCII armor is +applied (see the ARMOR parameter). Even if PGP didn't compress the +message, the ASCII armor would still render the message unreadable to +human eyes. The recipient must use PGP to strip the armor off and +decompress it before reading the message. If the original plaintext message is in text (not binary) form, there -is a way to send it through an E-mail channel in such a way that the -ASCII armor is applied only to the binary signature certificate, but -not to the plaintext message. This makes it possible to read the -signed message with human eyes, without the aid of PGP. Of course, -you still need PGP to actually check the signature. - -To enable this feature, set CLEARSIG=ON, and set ARMOR=ON (or use -the -a option), and set TEXTMODE=ON (or use the -t option). For -example, you can set CLEARSIG directly from the command line: +is a way to send a signed message through an E-mail channel in such a +way that the signed message is not compressed and the ASCII armor is +applied only to the binary signature certificate, but not to the +plaintext message. The CLEARSIG flag provides this useful feature, +making it possible to generate a signed message that can be read with +human eyes, without the aid of PGP. Of course, you still need PGP to +actually check the signature. + +The CLEARSIG flag is preset to "on" beginning with PGP version 2.5. +To enable the full CLEARSIG behavior, the ARMOR and TEXTMODE flags +must also be turned on. Set ARMOR=ON (or use the -a option), and set +TEXTMODE=ON (or use the -t option). If your config file has CLEARSIG +turned off, you can turn it back on again directly on the command +line, like so: pgp -sta +clearsig=on message.txt @@ -1087,52 +1251,34 @@ multiple keys to your key ring, PGP will each key before adding it to your key ring. - -Protecting Against Bogus Timestamps -=================================== +NOMANUAL - Let PGP Generate Keys Without the Manual +--------------------------------------------------- -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. +Default Setting: NOMANUAL = off -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. +It is important that the freeware version of PGP not be distributed +without the user documentation, which normally comes with it in the +standard release package. This manual contains important information +for using PGP, as well as important legal notices. But some people +have distributed previous versions of PGP without the manual, causing +a lot of problems for a lot of people who get it. To discourage the +distribution of PGP without the required documentation, PGP has been +changed to require the PGP User's Guide to be found somewhere on your +computer (like in your PGP directory) before PGP will let you generate +a key pair. However, some users like to use PGP on tiny palmtop +computers with limited storage capacity, so they like to run PGP +without the documentation present on their systems. To satisfy these +users, PGP can be made to relax its requirement that the manual be +present, by enabling the NOMANUAL flag on the command line during key +generation, like so: + + pgp -kg +nomanual + +The NOMANUAL flag can only be set on the command line, not in the +config file. Since you must read this manual to learn how to enable +this override feature, I hope this will still be effective in +discouraging the distribution of PGP without the manual. -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. A Peek Under the Hood @@ -1186,19 +1332,38 @@ conventional session key and then switch cryptography. So let's talk about this conventional encryption algorithm. It isn't the DES. -The Federal Data Encryption Standard (DES) 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 massive numbers of DES -chips. Also, Biham and Shamir have had some success recently on -attacking the full 16-round DES. +The Federal Data Encryption Standard (DES) used to be a good +algorithm for most commercial applications. But the Government never +did trust the DES to protect its own classified data, because the DES +key length is only 56 bits, short enough for a brute force attack. +Also, the full 16-round DES has been attacked with some success by +Biham and Shamir using differential cryptanalysis, and by Matsui +using linear cryptanalysis. + +The most devastating practical attack on the DES was described at the +Crypto '93 conference, where Michael Wiener of Bell Northern Research +presented a paper on how to crack the DES with a special machine. He +has fully designed and tested a chip that guesses 50 million DES keys +per second until it finds the right one. Although he has refrained +from building the real chips so far, he can get these chips +manufactured for $10.50 each, and can build 57000 of them into a +special machine for $1 million that can try every DES key in 7 hours, +averaging a solution in 3.5 hours. $1 million can be hidden in the +budget of many companies. For $10 million, it takes 21 minutes to +crack, and for $100 million, just two minutes. With any major +government's budget for examining DES traffic, it can be cracked in +seconds. This means that straight 56-bit DES is now effectively dead +for purposes of serious data security applications. + +A possible successor to DES may be a variation known as "triple DES", +which uses two DES keys to encrypt three times, achieving an +effective key space of 112 bits. But this approach is three times +slower than normal DES. A future version of PGP may support triple +DES as an option. PGP does not use the DES as its conventional single-key algorithm to encrypt messages. Instead, PGP uses a different conventional -single-key block encryption algorithm, called IDEA(tm). A future -version of PGP may support the DES as an option, if enough users -ask for it. But I suspect IDEA is better than DES. +single-key block encryption algorithm, called IDEA(tm). For the cryptographically curious, the IDEA cipher has a 64-bit block size for the plaintext and the ciphertext. It uses a key size of 128 @@ -1215,36 +1380,56 @@ the algorithm called it IPES (Improved P but they later changed the name to IDEA (International Data Encryption Algorithm). So far, IDEA has resisted attack much better than other ciphers such as FEAL, REDOC-II, LOKI, Snefru and Khafre. -And preliminary evidence suggests that IDEA may be more resistant -than the DES to Biham & Shamir's highly successful differential -cryptanalysis attack. Biham and Shamir have been examining the IDEA -cipher for weaknesses, without success. Academic cryptanalyst groups -in Belgium, England, and Germany are also attempting to attack it, as +And recent evidence suggests that IDEA is more resistant than the DES +to Biham & Shamir's highly successful differential cryptanalysis +attack. Biham and Shamir have been examining the IDEA cipher for +weaknesses, without success. Academic cryptanalyst groups in +Belgium, England, and Germany are also attempting to attack it, as well as the military services from several European countries. As this new cipher continues to attract attack efforts from the most formidable quarters of the cryptanalytic world, confidence in IDEA is growing with the passage of time. -A famous hockey player once said, "I try to skate to where I think -the puck will be." A lot of people are starting to feel that the -days are numbered for the DES. I'm skating toward IDEA. +Every once in a while, I get a letter from someone who has just +learned the awful truth that PGP does not use pure RSA to encrypt +bulk data. They 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. They demand an explanation for this apparent "compromise" in +the strength of PGP. This may be because they have been caught up in +the public's reverence and awe for the strength and mystique of RSA, +mistakenly believing that RSA is intrinsically stronger than any +conventional cipher. Well, it's not. + +People who work in factoring research say that the workload to +exhaust all the possible 128-bit keys in the IDEA cipher would +roughly equal the factoring workload to crack a 3100-bit RSA key, +which is quite a bit bigger than the 1024-bit RSA key size that most +people use for high security applications. Given this range of key +sizes, and assuming there are no hidden weaknesses in the +conventional cipher, the weak link in this hybrid approach is in the +public key algorithm, not the conventional cipher. 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. +encrypt and decrypt long messages. A 1024-bit RSA key would decrypt +messages about 4000 times slower than the IDEA cipher. Absolutely no +one does it that way in the real world. Many people less experienced +in cryptography do not realize that 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. + +Not only is RSA too slow to use on bulk data, but it even has certain +weaknesses that can be exploited in some special cases of particular +kinds of messages that are fed to the RSA cipher, even for large +keys. These special cases can be avoided by using the hybrid +approach of using RSA to encrypt random session keys for a +conventional cipher, like PGP does. So the bottom line is this: +Using pure RSA on bulk data is the wrong approach, period. It's too +slow, it's not stronger, and may even be weaker. If you find a +software application that uses pure RSA on bulk data, it probably +means the implementor does not understand these issues, which could +imply he doesn't understand other important concepts of cryptography. @@ -1377,31 +1562,82 @@ based on MD5 and the RSA public-key cryp -Compatibility with Previous Versions of PGP -=========================================== +Compatibility with Previous and Future Versions of PGP +====================================================== -I'm sorry, PGP version 2.0 is not compatible with PGP version 1.0. -If you have keys generated with version 1.0, you will have to -generate new keys to use with this version. This version of PGP uses -all new algorithms for conventional cryptography, compression, and -message digests, as well as using a much better approach to key -management. There were just too many changes to make it compatible -with the old format messages, signatures, and keys. Perhaps we could -have provided a special conversion utility to convert old keys into -new keys, but we were all tired and wanted to get the new release out -the door. Besides, converting the old keys into new keys would -probably create more problems than it would solve, because we have -changed to a new recommended uniform style for the user ID that -includes the full name and E-mail address in a particular syntax. - -There is compatibility from version 2.0 to higher versions. Because -new features are added, older versions may not always be able to -handle some files created with newer versions. - -We made some effort to design the internal data structures of this -version of PGP to be adaptable to future changes, so that hopefully -you will not be required to discard and regenerate your keys in future -versions. +PGP version 2.6 can read anything produced by versions 2.3 through +2.7. However, because of a negotiated agreement between MIT and RSA +Data Security, PGP 2.6 will change its behavior slightly on 1 +September 1994, triggered by a built-in software timer. On that +date, version 2.6 will start producing a new and slightly different +data format for messages, signatures and keys. PGP 2.6 will still be +able to read and process messages, signatures, and keys produced +under the old format, but it will generate the new format. This +change is intended to discourage people from continuing to use the +older (2.3a and earlier) versions of PGP, which Public Key Partners +contends infringes its RSA patent (see the section on Legal Issues). +ViaCrypt PGP (see the section Where to Get a Commercial Version of +PGP), versions 2.4 and 2.7, avoids questions of infringement through +Viacrypt's license arrangement with Public Key Partners. PGP 2.5 and +2.6 avoid questions of infringement by using the RSAREF(TM) +Cryptographic Toolkit, under license from RSA Data Security, Inc. + +Outside the United States, the RSA patent is not in force, so PGP +users there are free to use implementations of PGP that do not rely +on RSAREF and its restrictions. See the notes on foreign versions in +the Legal Issues section later in this manual. It seems likely that +any versions of PGP prepared outside the US will follow the new +format, whose detailed description is available from MIT. If +everyone upgrades before September 1994, or soon thereafter, there +will be little interoperability problems. + +This format change beginning with 2.6 is similar to the process that +naturally happens when new features are added, causing older versions +of PGP to be unable to read stuff from the newer PGP, while the newer +version can still read the old stuff. The only difference is that +this is a "legal upgrade", instead of a technical one. It's a +worthwhile change, if it can achieve peace in our time. + +According to ViaCrypt, which sells a commercial version of PGP, +ViaCrypt PGP will evolve to maintain interoperability with new +freeware versions of PGP. + +There is a another change that effects interoperability with earlier +versions of PGP. Unfortunately, due to data format limitations +imposed by RSAREF, PGP 2.5 and 2.6 cannot interpret any messages or +signatures made with PGP version 2.2 or earlier. Since we had no +choice but to use the new data formats, because of the need to switch +to RSAREF, we can't do anything about this problem. + +Beginning with version 2.4 (which was ViaCrypt's first version) +through at least 2.6, PGP does not allow you to generate RSA keys +bigger than 1024 bits. The upper limit was always intended to be +1024 bits -- there had to be some kind of upper limit, for +performance and interoperability reasons. But because of a bug in +earlier versions of PGP, it was possible to generate keys larger than +1024 bits. These larger keys caused interoperability problems +between different older versions of PGP that used different +arithmetic algorithms with different native word sizes. On some +platforms, PGP choked on the larger keys. In addition to these older +key size problems, the 1024-bit limit is now enforced by RSAREF. A +1024-bit key is very likely to be well out of reach of attacks by +major governments. In a future version, PGP will support bigger keys. + +In general, there is compatibility from version 2.0 upwards through +2.4. Because new features are added, older versions may not always be +able to handle some files created with newer versions. Because of +massive changes to all the algorithms and data structures, PGP version +2.0 (and later) is not even slightly compatible with PGP version 1.0, +which no one uses anymore anyway. + +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. We will endeavor to make future versions +handle keys, signatures, and messages from this version, but this is +not guaranteed. Future releases may provide conversion utilities to +convert old keys, but you may have to dispose of old messages created +with the old PGP. Also, this current version may not be able to read +stuff produced from all future versions. Vulnerabilities @@ -1568,6 +1804,18 @@ as to compromise its own ability to chec assumes that you have a good trusted copy of the public key that you use to check the signature on the PGP executable. +I recommend you not trust your copy of PGP unless it was originally +distributed by MIT or ViaCrypt, or unless it comes with a digitally +signed endorsement from me. Every new version comes with one or more +digital signatures in the distribution package, signed by the +originator of that release package. This is usually someone +representing MIT or ViaCrypt, or whoever released that version. +Check the signatures on the version that you get. I have actually +seen several bogus versions of PGP distribution packages, even from +apparantly reliable freeware distribution channels such as CD-ROM +distributors and Compuserve. Always check the signature when you get +a new version. + Physical Security Breach ------------------------ @@ -1643,7 +1891,7 @@ using sophisticated measures to read you being used. You will just have to recognize these risks on multi-user systems, and adjust your expectations and behavior accordingly. Perhaps your situation is such that you should consider -only running PGP on an isolated single-user system under your direct +running PGP only on an isolated single-user system under your direct physical control. That's what I do, and that's what I recommend. @@ -1664,6 +1912,61 @@ analysis in your communication environme cryptographic assistance. +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. + +I think this problem of falsified timestamps in digital signatures is +no worse than it is already in handwritten signatures. Anyone may +write a date next to their handwritten signature on a contract with +any date they choose, yet no one seems to be alarmed over this state +of affairs. In some cases, an "incorrect" date on a handwritten +signature might not be associated with actual fraud. The timestamp +might be when the signator asserts that he signed a document, or +maybe when he wants the signature to go into effect. + +In situations where it is critical that a signature be trusted to +have the actual correct date, people can simply use notaries to +witness and date a handwritten signature. The analog to this in +digital signatures is to get a trusted third party to sign a +signature certificate, applying a trusted timestamp. No exotic or +overly formal protocols are needed for this. Witnessed signatures +have long been recognized as a legitimate way of determining when a +document was signed. + +A trustworthy Certifying Authority or notary could create notarized +signatures with a trustworthy timestamp. This would 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. When a notary signs other people's +signatures, it creates a signature certificate of a signature +certificate. This would serve as a witness to the signature the same +way real notaries now witness handwritten signatures. The notary +could enter the detached signature certificate (without the actual +whole document that was signed) into a special log controlled by the +notary. Anyone can read this log. The notary's signature would have +a trusted timestamp, which might have greater credibility or more +legal significance than the timestamp in the original signature. + +There is a good treatment of this topic in Denning's 1983 article in +IEEE Computer (see references). Future enhancements to PGP might +have features to easily manage notarized signatures of signatures, +with trusted timestamps. + + Cryptanalysis ------------- @@ -1685,8 +1988,8 @@ Still, some optimism seems justified. T are among the best cryptographers in Europe. It has had extensive security analysis and peer review from some of the best cryptanalysts in the unclassified world. It appears to have some design advantages -over the DES in withstanding differential cryptanalysis, which has -been used to crack the DES. +over the DES in withstanding differential and linear cryptanalysis, +which have both been used to crack the DES. Besides, even if this algorithm has some subtle unknown weaknesses, PGP compresses the plaintext before encryption, which should greatly @@ -1721,202 +2024,524 @@ 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-1993. Philip Zimmermann -also holds the copyright for the PGP User's Manual, as well as any -foreign language translations of the manual or the software. +"PGP", "Pretty Good Privacy", "Phil's Pretty Good Software", and the +"Pretty Good" label for computer software and hardware products are +all trademarks of Philip R. Zimmermann. + +PGP is (c) Copyright Philip R. Zimmermann, 1990-1994. All rights +reserved. The PGP User's Guide is also copyright Philip Zimmermann, +1990-1994. All rights reserved. These rights include but are not +limited to any foreign language translations of the manual or the +software, and all derivative works of both. + +MIT may have a copyright on the particular software distribution +package that they distribute from the MIT FTP site. This copyright +on the "compilation" of the distribution package in no way implies +that MIT has a copyright on PGP itself, or its user documentation. 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. +provided "as is" without express or implied warranty of any kind. +Because certain actions may delete files or render them +unrecoverable, the author assumes no responsibility for the loss or +modification of any data. + Patent Rights on the Algorithms ------------------------------- -When I first released PGP, I half-expected to encounter some form of -legal harassment 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, 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 helped provide 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 no plans -to ever license the RSA algorithm to PGP users, and denied ever -implying that he would. Meanwhile, I have continued to refrain from -distributing PGP, although I continue to update the PGP User's Guide, -and have provided the design guidance for new revisions of PGP. -Ironically, all this legal controversy from PKP has imparted a -forbidden flavor to PGP that has only served to amplify its universal -popularity. - -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. +The RSA public key cryptosystem was developed at MIT, which holds a +patent on it (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. MIT distributes a freeware version of PGP under the +terms of the RSAREF license from RSA Data Security, Inc. (RSADSI). + +Non-US users of earlier versions of PGP should note that the RSA +patent does not apply outside the US, and at least at the time of +this writing, the author is not aware of any RSA patent in any other +country. Federal agencies may use the RSA algorithm, because the +Government paid for the development of RSA with grants from the +National Science Foundation and the Navy. But despite the fact of +Government users having free access to the RSA algorithm, Government +use of PGP has additional restrictions imposed by the agreement I +have with ViaCrypt, as explained later. + +I wrote my PGP software from scratch, with my own independently +developed implementation of the RSA algorithm. Before publishing PGP +in 1991, 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. 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 do. The second release of PGP -was a joint effort of an international team of software engineers, -implementing enhancements to the original PGP with design guidance -from me. It was released by Branko Lankester in The Netherlands and -Peter Gutmann in New Zealand, out of reach of US patent law. -Although released only in Europe and New Zealand, it spontaneously -spread to the USA without help from me or the PGP development team. +cryptosystem, but they also acquired the exclusive rights to three +other patents covering other public key schemes invented by others at +Stanford University, also developed with federal funding. This +one company claims to have 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. I find such a comprehensive monopoly troubling, +because I think public key cryptography is destined to become a +crucial technology in the protection of our civil liberties and +privacy in our increasingly connected society. At the very least, +it places these vital tools at risk by affording to the Government +a single pressure point of influence. + +Beginning with PGP version 2.5 (distributed by MIT, the holders of +the original RSA patent), the freeware version of PGP uses the RSAREF +subroutine library to perform its RSA calculations, under the RSAREF +license, which allows noncommercial use in the USA. RSAREF is a +subroutine package from RSA Data Security Inc, that implements the +RSA algorithm. The RSAREF subroutines are used instead of PGP's +original subroutines to implement the RSA functions in PGP. See the +RSAREF license for terms and conditions of use of RSAREF +applications. + +PGP 2.5 was released by MIT for a brief test period in May, 1994 +before releasing 2.6. PGP 2.5 was released under the 16 March, 1994 +RSAREF license, which is a perpetual license, so it may legally be +used forever in the US. But it would be better for PGP's legal and +political future for users in the United States to upgrade to version +2.6 or later to facilitate the demise of PGP 2.3a and earlier +versions. Also, PGP 2.5 has bugs that are corrected in 2.6, and 2.5 +will not read the new data format after September 1, 1994. (See the +section on Compatibility with Previous and Future Versions of PGP.) + +The PGP 2.0 release was a joint effort of an international team of +software engineers, implementing enhancements to the original PGP +with design guidance from me. It was released by Branko Lankester in +The Netherlands and Peter Gutmann in New Zealand, out of reach of US +patent law. Although released only in Europe and New Zealand, it +spontaneously spread to the USA without help from me or the PGP +development team. The IDEA(tm) conventional block cipher used by PGP is covered by a patent in Europe, held by ETH and a Swiss company called Ascom-Tech -AG. The patent number is PCT/CH91/00117. International patents are -pending. IDEA(tm) is a trademark of Ascom-Tech AG. There is no -license fee required for noncommercial use of IDEA. Ascom Tech AG -has granted permission for PGP to use the IDEA cipher, and places no -restrictions on using PGP for any purpose, including commercial use. -You may not extract the IDEA cipher from PGP and put it in another -commercial product without a license. Commercial users of IDEA may -obtain licensing details from Dieter Profos, Ascom Tech AG, Solothurn -Lab, Postfach 151, 4502 Solothurn, Switzerland, Tel +41 65 242885, -Fax +41 65 235761. +AG. The US Patent number is 5,214,703, and the European patent +number is EP 0 482 154 B1. IDEA(tm) is a trademark of Ascom-Tech AG. +There is no license fee required for noncommercial use of IDEA. +Commercial users of IDEA may obtain licensing details from Dieter +Profos, Ascom Tech AG, Teleservices Section, Postfach 151, 4502 +Solothurn, Switzerland, Tel +41 65 242885, Fax +41 65 235761. + +Ascom-Tech AG has granted permission for the freeware version PGP to +use the IDEA cipher in non-commercial uses, everywhere. In the US +and Canada, all commercial or Government users must obtain a licensed +version from ViaCrypt, who has a license from Ascom-Tech for the IDEA +cipher. + +Ascom-Tech has recently been changing its policies regarding the use +of IDEA in PGP for commercial use outside the US, and that policy +still seems to be in flux. They tell me that their current thinking +is as follows: They will allow commercial users of PGP outside the +US or Canada to use IDEA in PGP without paying royalties to +Ascom-Tech, because it is not currently possible for commercial users +to buy a licensed version of PGP outside the US or Canada. If the +legal situation in the USA changes in the future, so that users +outside the US or Canada can buy a licensed version of PGP (either +from ViaCrypt, or from me, or from a foreign enterprise licensed by +me), then Ascom-Tech will begin enforcing its patent licensing +policies on commercial users who are in a position to buy a licensed +version of PGP. To get a more up-to-date report on this, contact +Ascom-Tech AG. The ZIP compression routines in PGP come from freeware source code, with the author's permission. I'm not aware of any patents on the -ZIP algorithm, but you're welcome to check into that question -yourself. If there are any obscure patent claims that apply to ZIP, -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." - - -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. 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) Although the FSF General Public License allows non-proprietary - derivative products, it prohibits proprietary derivative products. - 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 2.2 executable object release package for MSDOS -contains the PGP executable software, documentation, sample key rings -including my own public key, and signatures for the software and this -manual, all in one PKZIP compressed file called PGP22.ZIP. The PGP -source release package for MSDOS contains all the C source files in -one PKZIP compressed file called PGP22SRC.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. +compression algorithms used in the ZIP routines. + + +Freeware Status and Restrictions +-------------------------------- + +PGP is not shareware, it's freeware. Published as a community +service. Giving PGP away for free will encourage far more people to +use it, which will have a greater social impact. Feel free to +disseminate the complete unmodified PGP release package as widely as +possible, but be careful not to violate U.S. export controls if you +live in the USA. Give it to all your friends. If you have access to +any electronic Bulletin Board Systems, please upload the complete PGP +executable object release package to as many BBS's as possible. + +You may also disseminate the source code release package. PGP's +source code is published to assist public scrutiny of PGP to show that +it has no hidden weaknesses or back doors, and to help people to find +bugs and report them. Recompile it and port it to new target +machines. Experiment with the code and learn from it. + +I place no restraints on your modifying the source code for your own +use. However, do not distribute a modified version of PGP under the +name "PGP" without first getting permission from me. Please respect +this restriction. PGP's reputation for cryptographic integrity +depends on maintaining strict quality control on PGP's cryptographic +algorithms and protocols. Beyond that, ad hoc "improvements" to PGP +can affect interoperability, which creates user confusion and +compatability problems that could damage PGP's (and my own) +reputation and undermine the good will earned by the PGP trademark. + +This has already started to happen, which is why I'm making a point +of it here. This creates technical support headaches, and I get +phone calls from confused users who run into problems either because +they have a mutant strain of PGP, or are trying to process a key, +signature, or message that came from an incompatible mutant strain of +PGP. The source code to PGP was not published to help spawn these +mutant strains. + +If you want to distribute a modified version of PGP, or use a modified +version to send messages to other people, you should name the program +in such a way that no one could mistake it for PGP. The messages, +signatures, and keys it produces must also be labeled in such a way +that no one could mistake them for material produced by PGP. If you +feel you must modify your copy of PGP, and there is any chance that +the modified version could escape into the environment, please contact +me first to discuss some easy methods for how to prevent people from +confusing your version with the standard PGP. Perhaps we'll even +decide that your changes are appropriate for incorporating into the +standard PGP release. + +Also, you should note that official executable versions of PGP are +always released signed by the PGP developers, so you can verify their +authenticity. If you find a corrupted copy of PGP, or notice one +being distributed, please contact the people doing the distribution +and suggest that they replace this with an authentic version. + +Some older versions of PGP were published under the terms of the +General Public License (GPL), a license designed by the Free Software +Foundation to protect the status of free software. Newer freeware +versions of PGP are no longer published under the GPL. The RSAREF +licensing terms are more stringent than those of the GPL. But even +if a version of PGP is published without RSAREF, in a situation or +place where the RSA patent does not apply, I still do not want the +GPL to apply to PGP, for a variety of reasons, not the least of which +is because the GPL is not optimal for protecting PGP from being +republished with ad-hoc "improvements". + +Outside the United States, the RSA patent is not in force, so PGP +users there are free to use implementations of PGP that do not rely +on RSAREF and its restrictions. Canadians may use PGP without using +RSAREF, and there are legal ways to export PGP to Canada. In Canada, +where RSAREF is not needed, it is easy to modify and recompile the +current PGP source code to perform the RSA calculations without using +the RSAREF library, just as it was done in PGP 2.3a. In such a case, +this modified PGP may be re-released under the identical licensing +terms as the current official freeware PGP release, but without the +RSAREF-specific restrictions. It may not be re-released under the +GPL, as certain older versions were. And this manual must accompany +it. That modified version of PGP may not be used in environments +where RSAREF would be needed. + + +Restrictions on Commercial Use of PGP +------------------------------------- + +The freeware version of PGP is for personal, non-commercial use. For +commercial use in the USA or Canada, contact ViaCrypt in Phoenix, +Arizona (phone 602 944-0773, or email viacrypt@acm.org). + +I made an agreement with ViaCrypt in the summer of 1993 to license the +exclusive commercial rights to PGP, so that there would be a way for +corporations to use PGP without risk of a patent infringement lawsuit +from PKP. For PGP to succeed in the long term as a viable industry +standard, the legal stigma associated with the RSA patent rights had +to be resolved. ViaCrypt had already obtained a patent license from +PKP to make, use, and sell products that practice the RSA patents. +ViaCrypt offered a way out of the patent quagmire for PGP to penetrate +the corporate environment. They could sell a fully-licensed version +of PGP, but only if I licensed it to them under these terms. So we +entered into an agreement to do that, opening the door for PGP's +future in the commercial sector, which was necessary for PGP's +long-term political future. + +Therefore, regardless of the complexities and partially overlapping +restrictions from all the other terms and conditions imposed by the +various patent and copyright licenses (RSA, RSAREF, and IDEA) from +various third parties, an additional overriding restriction on PGP +usage is imposed by my own agreement with ViaCrypt: The freeware +version of PGP is only for personal, non-commercial use -- all other +users in the USA and Canada must obtain a fully licensed version of +PGP from ViaCrypt. The restrictions imposed by my agreement with +ViaCrypt do not apply outside the USA or Canada. + +Finally, if you want to turn PGP into a commercial product and make +money selling it, then we must agree on a way for me to also make +money on it. If you use PGP in such a manner that you must pay +patent royalties or any other software licensing fees to the patent +holders for any cryptographic algorithms used by PGP, then we must +agree on a way for me to also be paid in some manner. Buying PGP +from ViaCrypt is one way to meet this requirement. + + +Other Licensing Restrictions +---------------------------- + +Under no circumstances may PGP be distributed without the PGP +documentation, including this PGP User's Guide. And, assuming this is +an RSAREF version of PGP, the RSAREF license agreement must be kept +with it. You must also keep the copyright, patent, and trademark +notices on PGP and its documentation. + +The standard freeware PGP release is primarily distributed in +electronic form, as a single compressed archive file, containing a +collection of files in a "shrink-wrapped" package. This package +should not be broken up and the components separately distributed -- +in the interests of quality control, we want to make it difficult for +users to obtain PGP without getting the full release package. + + +Distribution +------------ + +In the USA, PGP is available for free from the Massachusetts Institute +of Technology, under the restrictions described above. + +The primary release site for PGP is the Massachusetts Institute of +Technology, at their FTP site "net-dist.mit.edu", in the /pub/PGP +directory. You may obtain free copies or updates to PGP from this +site, or any other Internet FTP site or BBS that PGP has spread to. +Don't ask me for a copy directly from me, especially if you live +outside the US or Canada. I recommend that you not use any modified +version of PGP that comes from any other source, other than MIT, +ViaCrypt, or me, unless it is accompanied by a signed endorsement +from me personally. You can get the official release software from +many other distribution sites "downstream" from MIT. Hopefully, all +these other sites are adhering to US export controls. + +The PGP version 2.6.1 executable object release package for MSDOS +contains the PGP executable software, documentation, RSAREF license, +sample key rings including my own public key, and signatures for the +software and this manual, all in one PKZIP compressed file called +pgp261.zip. The PGP source release package for MSDOS contains all +the C source files in one PKZIP compressed file called pgp261s.zip. +The filename for the release package is derived from the version +number of the release. + + +Export Controls +--------------- + +The U.S. Government has made it illegal in most cases to export good +cryptographic technology, and that may include PGP. They regard this +kind of software just like they regard munitions. This is determined +not by legislation, but by administrative policies of the State +Department, Defense Department and Commerce Department. + +The U.S. Government is using export restrictions as a means of +suppressing both domestic and foreign availability of cryptographic +technology. In particular, it is trying to suppress the emergence of +an international standard for cryptographic protocols, until it can +establish the Escrowed Encryption Standard (the Clipper chip) as the +dominant standard. + +Any export restrictions on PGP are imposed by the US Government. +This does not imply that I or MIT agree with these restrictions. We +just comply with them. We do not impose additional licensing +restrictions of our own on the use of PGP outside of the US, other +than those restrictions that already apply inside the US. PGP may be +subject to export controls. Anyone wishing to export it should first +consult the State Department's Office of Defense Trade Controls. + +I will not export this software out of the US or Canada in cases when +it is illegal to do so under US controls, and I urge other people not +to export it on their own. If you live outside the US or Canada, I +urge you not to violate US export laws by getting any version of PGP +in a way that violates those laws. Since thousands of domestic users +got the first version after its initial publication, it somehow +leaked out of the US and spread itself widely abroad, like dandelion +seeds blowing in the wind. + +Starting with PGP version 2.0 through version 2.3a, the release point +of the software has been outside the US, on publicly-accessible +computers in Europe. Each release was electronically sent back into +the US and posted on publicly-accessible computers in the US by PGP +privacy activists in foreign countries. There are some restrictions +in the US regarding the import of munitions, but I'm not aware of any +cases where this was ever enforced for importing cryptographic +software into the US. I imagine that a legal action of that type +would be quite a spectacle of controversy. + +ViaCrypt PGP is sold in the United States and Canada and is not for +export. The following language was supplied by the US Government to +ViaCrypt for inclusion in the ViaCrypt PGP documentation: "PGP is +export restricted by the Office of Export Administration, United +States Department of Commerce and the Offices of Defense Trade +Controls and Munitions Control, United States Department of State. +PGP cannot be exported or reexported, directly or indirectly, (a) +without all export or reexport licenses and governmental approvals +required by any applicable laws, or (b) in violation of any +prohibition against the export or reexport of any part of PGP." The +Government may take the position that the freeware PGP versions are +also subject to those controls. + +The freeware PGP versions 2.5 and 2.6 were released through a posting +on a controlled FTP site maintained by MIT. This site has +restrictions and limitations which have been used on other FTP sites +to comply with export control requirements with respect to other +encryption software such as Kerberos and software from RSA Data +Security, Inc. I urge you not to do anything which would weaken +those controls or facilitate any improper export of PGP. + +Although PGP has become a worldwide de facto standard for E-mail +encryption, and is widely available overseas, I still get calls from +people outside the US who ask me if it is legal to use it in their +own country, for versions that are already available there. Please +don't contact me to ask me if it is legal to use PGP in your country +if you live outside the US. That question is not up to me. I've got +enough legal problems of my own with export control issues, without +getting involved in giving you legal advice over my phone. It might +even put me at some legal risk to simply answer a question like that +for a foreigner. If this question concerns you, ask someone else, +like a lawyer. + +You may have a need to use PGP in a commercial application outside +the US or Canada. Unfortunately, at the time of this writing, there +is no current commercial source for PGP outside the US or Canada. I +am trying to find a US-legal way to make a commercially licensed +version available abroad, but right now the US export restrictions +make that difficult without putting me at legal risk. This situation +may change. + +Some foreign governments impose serious penalties on anyone inside +their country for merely using encrypted communications. In some +countries they might even shoot you for that. But if you live in +that kind of country, perhaps you need PGP even more. + + + +Philip Zimmermann's Legal Situation +----------------------------------- + +At the time of this writing, I am the target of a US Customs criminal +investigation in the Northern District of California. A criminal +investigation is not a civil lawsuit. Civil lawsuits do not involve +prison terms. My defense attorney has been told by the Assistant US +Attorney that the area of law of interest to the investigation has to +do with the export controls on encryption software. The federal +mandatory sentencing guidelines for this offense are 41 to 51 months +in a federal prison. US Customs appears to be taking the position +that electronic domestic publication of encryption software is the +same as exporting it. The prosecutor has issued a number of federal +grand jury subpoenas. It may be months before a decision is reached +on whether to seek indictment. This situation may change at any +time, so this description may be out of date by the time you read +it. Watch the news for further developments. If I am indicted and +this goes to trial, it will be a major test case. + +I have a legal defense fund set up for this case. So far, no other +organization is doing the fundraising for me, so I am depending on +people like you to contribute directly to this cause. If you care +about the future of your civil liberties in the information age, then +perhaps you will care about this case. The legal fees are expensive, +the meter is running, and I need your help. The fund is run by my +lead defense attorney, Phil Dubois, here in Boulder. Please send +your contributions to: + + Philip L. Dubois, Lawyer + 2305 Broadway + Boulder, Colorado 80304 USA + Phone (303) 444-3885 + E-mail: dubois@csn.org + +You can also phone in your donation and put it on Mastercard or Visa. +If you want to be really cool, you can use Internet E-mail to send in +your contribution, encrypting your message with PGP so that no one +can intercept your credit card number. Include in your E-mail +message your Mastercard or Visa number, expiration date, name on the +card, and amount of donation. Then sign it with your own key and +encrypt it with Phil Dubois's public key (his key is included in the +standard PGP distribution package, in the "keys.asc" file). Put a +note on the subject line that this is a donation to my legal defense +fund, so that Mr. Dubois will decrypt it promptly. Please don't send +a lot of casual encrypted E-mail to him -- I'd rather he use his +valuable time to work on my case. + +If you want to read some press stories to find out why this is an +important case, see the following references: + + 1) William Bulkeley, "Cipher Probe", Wall Street Journal, Thursday + 28 April 1994, front page. + 2) John Cary, "Spy vs. Computer Nerd: The Fight Over Data + Security", Business Week, 4 Oct 1993, page 43. + 3) Jon Erickson, "Cryptography Fires Up the Feds", Dr. Dobb's + Journal, December 1993, page 6. + 4) John Markoff, "Federal Inquiry on Software Examines Privacy + Programs", New York Times, Tuesday 21 Sep 1993, page C1. + 5) Kurt Kleiner, "Punks and Privacy", Mother Jones Magazine, + Jan/Feb 1994, page 17. + 6) Steven Levy, "Battle of the Clipper Chip", New York Times + Magazine, Sunday 12 Jun 1994, page 44. + 7) Steven Levy, "Crypto Rebels", WIRED, May/Jun 1993, page 54. + 8) John Markoff, "Cyberspace Under Lock and Key", New York Times, + Sunday 13 Feb 1994. + 9) Philip Elmer-DeWitt, "Who Should Keep the Keys", Time, 14 Mar + 1994, page 90. + +There are a great many other articles on PGP from around the world. +I'm keeping a scrapbook. + + +Other Sources of Information on PGP +=================================== + + +Where to Get a Commercial Version of PGP +---------------------------------------- + +To get a fully licensed version of PGP for use in the USA or Canada, +contact: + + ViaCrypt + 9033 North 24th Avenue, Suite 7 + Phoenix, Arizona 85021 USA + Phone: (602) 944-0773, or (800) 536-2664 + Fax: (602) 943-2601 + E-mail: viacrypt@acm.org + +ViaCrypt has a version of PGP for MSDOS, and a number of Unix +platforms. They also have a Windows shell version, and other +versions are under development, including Macintosh. If you have a +need to use PGP in a commercial or Government setting, and ViaCrypt +has a version of PGP for your hardware platform, you should get +ViaCrypt PGP. + +ViaCrypt has obtained all the necessary licenses from PKP, Ascom-Tech +AG, and Philip Zimmermann to sell PGP for use in commercial or +government environments. ViaCrypt PGP is every bit as secure as the +freeware PGP, and is entirely compatible in both directions with the +freeware version of PGP. ViaCrypt PGP is the perfect way to get a +fully licensed version of PGP into your corporate environment. + +If you work in a large company and you are a fan of PGP, I urge you +to try to persuade your company to buy lots of copies of PGP from +ViaCrypt. Not just because that will earn royalties for me. If +ViaCrypt can make PGP a commercial success, it will go a long way +toward cementing PGP's political future as an unstoppable standard +for E-mail encryption in the corporate world. The corporate world is +where the money is, and that affects public policy like nothing +else. And that includes Government policy to suppress strong +cryptography. + + + +Reporting PGP Bugs +------------------ + +Bugs in PGP should be reported via E-mail to MIT, the official +distribution site of PGP. The E-mail address for bug reports is +pgp-bugs@mit.edu. MIT will forward a copy of your bug report to me. +When you report bugs, be sure to specify what machine and operating +system you are using and what version of PGP you have, and provide +enough detail to reproduce the problem. It would also be a good idea +to find out if you have the latest version of PGP, in case the bug +has already been fixed. Also, it's a good idea to make sure it +really is a bug before you report it. RTFM. + + + +Fan Mail, Updates, and News +--------------------------- 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 @@ -1925,38 +2550,38 @@ suggestions for enhancing PGP are welcom 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 +alive. This means you usually won't get 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. +self-addressed envelope. But I often 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, and even then I might not return your +call. If you need any significant amount of my time, I am available +on a paid consulting basis, and I always 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 ($50 might be worth -my time if I were actually selling this stuff). 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 -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. Isn't it enough that the software is free? It -would be nicer if people could try to get PGP from any of the myriad -other sources. If you don't have a modem, ask a friend to get it for -you. If you can't find it yourself, I don't mind answering a quick -phone call. +to send me a few dollars asking me for a copy of PGP. I don't send +it to them because I'd rather avoid any legal problems with PKP. Or +worse, sometimes these requests are from foreign countries, and I +would be risking a violation of US 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. +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 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. Isn't it enough that +the software is free? It would be nicer if people could try to get +PGP from any of the myriad other sources. If you don't have a modem, +ask a friend to get it for you. 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 @@ -1977,147 +2602,123 @@ software. These kits include translated LANGUAGE.TXT, PGP.HLP, and the PGP User's Guide. If you want to produce a translation for your own native language, contact me first to get the latest information and standard guidelines, and to find -out if it's been translated to your language already. Colin Plumb -(colin@nyx.cs.du.edu) maintains a comprehensive collection of foreign -language kits from other translators. - -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, but you may have to dispose -of old messages created with the old PGP. +out if it's been translated to your language already. To find out +where to get a foreign language kit for your language, you might +check on the Internet newsgroups, or get it from Mike Johnson +(mpj@csn.org). If you have access to the Internet, watch for announcements of new releases of PGP on the Internet newsgroups "sci.crypt" and PGP's own -newsgroup, "alt.security.pgp". There is also an interest group -mailing list called info-pgp, which is intended for users without -access to the "alt.security.pgp" newsgroup. Info-pgp is moderated by -Hugh Miller, and you may subscribe to it by writing him a letter at -info-pgp-request@lucpul.it.luc.edu. Include your name and Internet -address. If you want to know where to get PGP, Hugh can send you a -list of Internet FTP sites and BBS phone numbers. Hugh may also be -reached at hmiller@lucpul.it.luc.edu. - - - -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, like -dandelion seeds blowing in the wind. 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. - -It seems to some legal observers I've talked with, that the framers of -the US export controls never envisioned that they would ever apply to -cryptographic freeware that has been published and scattered to the -winds. It's hard to imagine a US attorney trying to build a real -case against someone for the "export" of software published freely in -the US. As far as anyone I've talked to knows, it's never been done, -despite numerous examples of export violations. I'm not a lawyer and -I'm not giving you legal advice-- I'm just trying to point out what -seems like common sense. - -Starting with PGP version 2.0, the release point of the software has -been outside the US, on publicly-accessible computers in Europe. -Each release is electronically sent back into the US and posted on -publicly-accessible computers in the US by PGP privacy activists in -foreign countries. There are some restrictions in the US regarding -the import of munitions, but I'm not aware of any cases where this -was ever enforced for importing cryptographic software into the US. -I imagine that a legal action of that type would be quite a spectacle -of controversy. - -Some foreign governments impose serious penalties on anyone inside -their country for merely using encrypted communications. In some -countries they might even shoot you for that. But if you live in -that kind of country, perhaps you need PGP even more. +newsgroup, "alt.security.pgp". If you want to know where to get PGP, +MIT is the primary FTP distribution site (net-dist.mit.edu). Or ask +Mike Johnson (mpj@csn.org) for a list of Internet FTP sites and BBS +phone numbers. Computer-Related Political Groups -================================= +--------------------------------- PGP is a very political piece of software. It seems appropriate to mention here some computer-related activist groups. Full details on these groups, and how to join them, is provided in a separate document file in the PGP release package. -The Electronic Frontier Foundation (EFF) was founded in July, 1990, -to assure freedom of expression in digital media, with a particular -emphasis on applying the principles embodied in the Constitution and -the Bill of Rights to computer-based communication. They can be -reached at: Electronic Frontier Foundation, 238 Main Street, -Cambridge, MA 02142, USA. - -The League for Programming Freedom (LPF) is a grass-roots organization -of professors, students, businessmen, programmers and users dedicated -to bringing back the freedom to write programs. They regard patents -on computer algorithms as harmful to the US software industry. They -can be reached at (617) 433-7071, or send Internet mail to -lpf@uunet.uu.net +The Electronic Privacy Information Center (EPIC) is a public interest +research center in Washington, DC. It was established in 1994 to +focus public attention on emerging privacy issues relating to the +National Information Infrastructure, such as the Clipper Chip, the +Digital Telephony proposal, medical record privacy, and the sale of +consumer data. EPIC is sponsored by the Fund for Constitutional +Government and Computer Professionals for Social Responsibility. +EPIC publishes the EPIC Alert and EPIC Reports, pursues Freedom of +Information Act litigation, and conducts policy research on emerging +privacy issues. For more information email info@epic.org, or write +EPIC, 666 Pennsylvania Ave., SE, Suite 301, Washington, DC 20003. ++1 202 544 9240 (tel), +1 202 547 5482 (fax). + +The Electronic Frontier Foundation (EFF) was founded in 1990 to +assure freedom of expression in digital media, with a particular +emphasis on applying the principles embodied in the US Constitution +and the Bill of Rights to computer-based communication. They can be +reached in Washington DC, at (202) 347-5400. Internet E-mail address: +eff@eff.org. Computer Professionals For Social Responsibility (CPSR) empowers computer professionals and computer users to advocate for the responsible use of information technology and empowers all who use computer technology to participate in public policy debates on the impacts of computers on society. They can be reached at: -415-322-3778 in Palo Alto, E-mail address cpsr@csli.stanford.edu. +(415) 322-3778 in Palo Alto, E-mail address cpsr@csli.stanford.edu. + +The League for Programming Freedom (LPF) is a grass-roots +organization of professors, students, businessmen, programmers and +users dedicated to bringing back the freedom to write programs. They +regard patents on computer algorithms as harmful to the US software +industry (and so do I!). They can be reached at (617) 433-7071. +E-mail address: lpf@uunet.uu.net. For more details on these groups, see the accompanying document in the PGP release package. - -Recommended Introductory Readings -================================= -1) Dorothy Denning, "Cryptography and Data Security", Addison-Wesley, + +Recommended Readings +-------------------- + + +Introductory Readings + +1) Bruce Schneier, "Applied Cryptography: Protocols, Algorithms, and + Source Code in C", John Wiley & Sons, 1993 + (This book is a watershed work on the subject.) +2) Dorothy Denning, "Cryptography and Data Security", Addison-Wesley, Reading, MA 1982 -2) Dorothy Denning, "Protecting Public Keys and Signature Keys", +3) Dorothy Denning, "Protecting Public Keys and Signature Keys", IEEE Computer, Feb 1983 -3) Martin E. Hellman, "The Mathematics of Public-Key Cryptography," +4) Martin E. Hellman, "The Mathematics of Public-Key Cryptography," Scientific American, Aug 1979 +5) Steven Levy, "Crypto Rebels", WIRED, May/Jun 1993, page 54. + (A "must-read" article on PGP and other related topics.) +6) Steven Levy, "Battle of the Clipper Chip", New York Times + Magazine, Sunday 12 Jun 1994, page 44. (Great article, great + photos.) +7) William Bulkeley, "Cipher Probe", Wall Street Journal, 28 April + 1994, front page. (An article on PGP and Zimmermann.) + Other Readings -============== -4) Ronald Rivest, "The MD5 Message Digest Algorithm", MIT Laboratory +8) Ronald Rivest, "The MD5 Message Digest Algorithm", MIT Laboratory for Computer Science, 1991 -5) Xuejia Lai, "On the Design and Security of Block Ciphers", - Institute for Signal and Information Processing, ETH-Zentrum, - Zurich, Switzerland, 1992 -6) Xuejia Lai, James L. Massey, Sean Murphy, "Markov Ciphers and - Differential Cryptanalysis", Advances in Cryptology- EUROCRYPT'91 -7) Philip Zimmermann, "A Proposed Standard Format for RSA +9) Xuejia Lai, "On the Design and Security of Block Ciphers", + ETH Series on Information Processing (Ed. J. L. Massey), + Vol. 1, Hartung-Gorre Verlag, Konstanz, Switzerland, 1992 +10) Philip Zimmermann, "A Proposed Standard Format for RSA Cryptosystems", Advances in Computer Security, Vol III, edited by Rein Turn, Artech House, 1988 -8) Paul Wallich, "Electronic Envelopes", Scientific American, Feb - 1993, pages 30-32. (This is an article on PGP) +11) Paul Wallich, "Electronic Envelopes", Scientific American, Feb + 1993, page 30. (An article on PGP) +12) William Stallings, "Pretty Good Privacy", BYTE, July 1994, page + 193 +13) Philip Zimmermann, "The Official PGP User's Guide", MIT Press, + 1994 (in press) +14) Philip Zimmermann, "PGP Source Code and Internals", MIT Press, + 1994 (in press) + To Contact the Author -===================== +--------------------- Philip Zimmermann may be reached at: Boulder Software Engineering 3021 Eleventh Street Boulder, Colorado 80304 USA -Phone 303-541-0140 (voice or FAX) (10:00am - 7:00pm Mountain Time) -Internet: prz@sage.cgd.ucar.edu - +Internet: prz@acm.org +Phone (303) 541-0140 (voice) (10:00am - 7:00pm Mountain Time) +Fax available, if you arrange it via voice line. Appendix A: Where to Get PGP @@ -2127,107 +2728,63 @@ The following describes how to get the f cryptographic software PGP (Pretty Good Privacy) from an anonymous FTP site on Internet, or from other sources. +PGP has become a worldwide de facto standard for E-mail encryption. 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. -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. Also, 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 outside the US, you're probably not violating US export -law if you pick it up from a source outside of the US. - -What follows is a small sample of places that allegedly have PGP, as -of 2 March 1993. This information is not guaranteed to be correct. -Some US sites have occasionally withdrawn PGP because of fear of -legal intimidation from the RSA patent holders. - -There are two compressed archive files in the PGP 2.2 MSDOS release. -You must get pgp22.zip which contains the MSDOS binary executable and -the PGP User's Guide, and you can optionally get pgp22src.zip which -contains the source files. These files can be decompressed with the -MSDOS shareware archive decompression utility PKUNZIP.EXE, version -1.1 or later. For Unix users who lack an implementation of UNZIP, -the source code can also be found in the compressed tar file -pgp22src.tar.Z. +The Massachusetts Institute of Technology is the distributor of PGP +version 2.6, for distribution in the USA only. It is available from +"net-dist.mit.edu," a controlled FTP site that has restrictions and +limitations, similar to those used by RSA Data Security, Inc., to comply +with export control requirements. The software resides in the directory +/pub/PGP. A reminder: Set mode to binary or image when doing an FTP transfer. And when doing a kermit download to your PC, specify 8-bit binary -mode at both ends. Here are some Internet sites that have PGP via -anonymous FTP: - -Finland: nic.funet.fi (128.214.6.100) - Directory: /pub/unix/security/crypt/ - -Italy: ghost.dsi.unimi.it (149.132.2.1) - Directory: /pub/security/ - -UK: src.doc.ic.ac.uk - Directory: /computing/security/software/PGP - -For those lacking FTP connectivity to the net, nic.funet.fi also -offers the files via email. Send the following mail message to -mailserv@nic.funet.fi: - - ENCODER uuencode - SEND pub/unix/security/crypt/pgp22src.zip - SEND pub/unix/security/crypt/pgp22.zip - -This will deposit the two zipfiles, as (about) 15 batched messages in -your mailbox within about 24 hours. Save and uudecode. - -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 BBS's you might try. - -The GRAPEVINE BBS in Little Rock Arkansas has set up a special -account for people to download PGP for free. The SYSOP is Jim Wenzel, -at jim.wenzel@grapevine.lrk.ar.us. The following phone numbers are -applicable and should be dialed in the order presented (i.e., the -first one is the highest speed line): (501) 753-6859, (501) -753-8121, (501) 791-0124. When asked to login use the following -information: - - name: PGP USER ('PGP' is 1st name, 'USER' is 2nd name) - password: PGP - -The Northern Lights BBS in Troy, NY, has PGP for free download. It -is run by Daniel Ray. Call (518) 237-2163 at 300-2400 bps 8N1. Then -login directly to the pgp account as follows: - - tnllogin: pgp - Password: key - -In Colorado, try this single-line BBS: 303 443-8292. It is often -busy, so keep trying. Log in with your own name. - -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 New Zealand, try this (supposedly free) dial-up BBS system: - Kappa Crucis: +64 9 817-3714, -3725, -3324, -8424, -3094, -3393 - -For information on PGP implementations on the Apple Macintosh, -Commodore Amiga, or Atari ST, or any other questions about where to -get PGP for any other platform, contact Hugh Miller at -hmiller@lucpul.it.luc.edu. +mode at both ends. + +There are two compressed archive files in the standard release, with +the file name derived from the release version number. For PGP +version 2.6.1, you must get pgp261.zip which contains the MSDOS +binary executable and the PGP User's Guide, and you can optionally +get pgp261s.zip which contains all the source code. These files can +be decompressed with the MSDOS shareware archive decompression +utility PKUNZIP.EXE, version 1.10 or later. For Unix users who lack +an implementation of UNZIP, the source code can also be found in the +compressed tar file pgp261s.tar.Z. + +If you don't have any local BBS phone numbers handy, here is a BBS +you might try. The Catacombs BBS, operated by Mike Johnson in +Longmont, Colorado, has PGP available for download by people in the US +or Canada only. The BBS phone number is 303-772-1062. Mike +Johnson's voice phone number is 303 772-1773, and his E-mail address +is mpj@csn.org. Mike also has PGP available on an Internet FTP site +for users in the US or Canada only; the site name is csn.org, in +directory /mpj/, and you must read the README.MPJ file to get it. + +To get a fully licensed version of PGP for use in the USA or Canada, +contact ViaCrypt in Phoenix, Arizona. Their phone number is +602-944-0773. ViaCrypt has obtained all the necessary licenses from +PKP, Ascom-Tech AG, and Philip Zimmermann to sell PGP for use in +commercial or Government environments. ViaCrypt PGP is every bit as +secure as the freeware PGP, and is entirely compatible in both +directions with the freeware version of PGP. ViaCrypt PGP is the +perfect way to get a fully licensed version of PGP into your +corporate or Government environment. -Here are a few people and their email addresses or phone numbers you +Here are a few people and their E-mail addresses or phone numbers you can contact in some countries to get information on local PGP -availability: +availability for versions earlier than 2.5: 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 +branko@hacktic.nl gallardo@batman.fi.upm.es +31 2159 42242 (341) 474 38 09 The Netherlands Spain