--- pgp/doc/pgpdoc2.txt 2018/04/24 16:39:43 1.1.1.1 +++ pgp/doc/pgpdoc2.txt 2018/04/24 16:42:44 1.1.1.4 @@ -1,42 +1,42 @@ + 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 + PGP(tm) User's Guide Volume II: Special Topics ------------------------- by Philip Zimmermann - Revised 6 Mar 93 + Revised 22 May 94 - PGP Version 2.2 - 6 Mar 93 + PGP Version 2.6 - 22 May 94 Software by - Philip Zimmermann - with - Branko Lankester, Hal Finney, and Peter Gutmann + 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 +56,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,13 +76,16 @@ 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 @@ -95,6 +99,7 @@ Vulnerabilities Viruses and Trojan Horses Physical Security Breach Tempest Attacks + Protecting Against Bogus Timestamps Exposure on Multi-user Systems Traffic Analysis Cryptanalysis @@ -103,6 +108,9 @@ Legal Issues Patent Rights on the Algorithms Licensing and Distribution Export Controls + Philip Zimmermann's Legal Situation + Where to Get a Commercial Version of PGP + Reporting PGP Bugs Computer-Related Political Groups Recommended Readings To Contact the Author @@ -110,7 +118,7 @@ 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 +132,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 +337,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 +354,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 +378,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 +404,21 @@ 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. +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 +434,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 +494,48 @@ 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. + +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. + + + +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. Until this happens, +you will just have to use smaller keyrings, or be patient. + Using PGP as a Unix-style Filter @@ -498,11 +565,11 @@ 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 @@ -722,7 +789,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 +845,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. @@ -919,6 +988,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 +1140,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 +1216,34 @@ multiple keys to your key ring, PGP will each key before adding it to your key ring. - -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. +NOMANUAL - Let PGP Generate Keys 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. +Default Setting: NOMANUAL = off -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. +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 do +enable this override feature, I hope this will still be effective in +discouraging the distribution of PGP without the manual. -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 +1297,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 +1345,54 @@ 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 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. These special +cases can be avoided by using the hybrid approach of using RSA to +encrypt random session keys for a conventional cipher. 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. @@ -1380,28 +1528,68 @@ based on MD5 and the RSA public-key cryp Compatibility with Previous 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, 2.3a, 2.4, +or 2.5. 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 incompatible +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). +PGP 2.4, distributed by Viacrypt (see the section Where to Get a +Commercial Version of PGP) avoids infringement through Viacrypt's +license arrangement with Public Key Partners. PGP 2.5 and 2.6 avoid +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. Hopefully, implementors of PGP versions +outside the US will also switch to the new format, whose detailed +description is available from MIT. If everyone upgrades before 1 +September 1994, no one will experience any discontinuity in +interoperability. + +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 legal +requirement 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. 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 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. Vulnerabilities @@ -1611,6 +1799,53 @@ why do you suppose the Government would shielding? +Protecting Against Bogus Timestamps +----------------------------------- + +A somewhat obscure vulnerability of PGP involves dishonest users +creating bogus timestamps on their own public key certificates and +signatures. You can skip over this section if you are a casual user +and aren't deeply into obscure public key protocols. + +There's nothing to stop a dishonest user from altering the date and +time setting of his own system's clock, and generating his own public +key certificates and signatures that appear to have been created at a +different time. He can make it appear that he signed something +earlier or later than he actually did, or that his public/secret key +pair was created earlier or later. This may have some legal or +financial benefit to him, for example by creating some kind of +loophole that might allow him to repudiate a signature. + +A remedy for this could involve some trustworthy Certifying Authority +or notary that would create notarized signatures with a trustworthy +timestamp. This might not necessarily require a centralized +authority. Perhaps any trusted introducer or disinterested party +could serve this function, the same way real notary publics do now. +A public key certificate could be signed by the notary, and the +trusted timestamp in the notary's signature would have some legal +significance. The notary could enter the signed certificate into a +special certificate log controlled by the notary. Anyone can read +this log. + +The notary could also sign other people's signatures, creating a +signature certificate of a signature certificate. This would serve +as a witness to the signature the same way real notaries do now with +paper. Again, the notary could enter the detached signature +certificate (without the actual whole document that was signed) into +a log controlled by the notary. The notary's signature would have a +trusted timestamp, which might have greater credibility than the +timestamp in the original signature. A signature becomes "legal" if +it is signed and logged by the notary. + +This problem of certifying signatures with notaries and trusted +timestamps warrants further discussion. This can of worms will not +be fully covered here now. There is a good treatment of this topic +in Denning's 1983 article in IEEE Computer (see references). There +is much more detail to be worked out in these various certifying +schemes. This will develop further as PGP usage increases and other +public key products develop their own certifying schemes. + + Exposure on Multi-user Systems ------------------------------ @@ -1643,7 +1878,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. @@ -1724,199 +1959,182 @@ 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. +is (c) Copyright Philip R. Zimmermann, 1990-1994. All rights +reserved. 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, and all derivative works. All rights +reserved. + +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, 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 +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. 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. Although 2.5 was released under the 16 March, +1994 RSAREF license, which is a perpetual license, it would be better +for users in the United States to upgrade to version 2.6 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 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 US005214703, 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. 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." +compression algorithms used in the ZIP routines, but you're welcome to +check into that question yourself. 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 +In the USA, PGP 2.6 is available from the Massachusetts Institute of +Technology, under the terms of the RSAREF license. I have no +objection to anyone freely using or distributing the freeware version +of PGP, without payment of fees to me, as long as it is for personal +non-commercial use. For commercial use, contact ViaCrypt in Phoenix, +Arizona (phone 602-944-0773). You must keep the copyright, patent, +and trademark notices on PGP and keep all the documentation with it. + +NOTE: 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, noncommercial use -- all other +users in the USA and Canada must obtain a fully licensed version of +PGP from ViaCrypt. + +I had to make an agreement with ViaCrypt in the summer of 1993 to +license the exclusive commercial rights to PGP, so that there would +be a legally safe 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. + +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 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. +widespread awareness and use of the RSA public key cryptosystem. 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. +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 Boards Systems, please upload the +complete PGP executable object release package to as many BBS's as +possible. The freeware version of PGP is available in source code +form, and you may disseminate the source release package too, if you've +got it. NOTE: Under no circumstances should PGP be distributed +without the PGP documentation, including this PGP User's Guide and the +RSAREF license agreement. + +The PGP version 2.6 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 pgp26.zip. The +PGP source release package for MSDOS contains all the C source files in +one PKZIP compressed file called pgp26src.zip. The filename for the +release package is derived from the version number of the release. + +The primary release site for PGP is the Massachusetts Institute of +Technology, at their FTP site "net-dist.mit.edu", in their /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. 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 @@ -1927,36 +2145,36 @@ release will reflect your suggestions. This project has not been funded and the project has nearly eaten me alive. This means you can't count on a reply to your mail, unless you only need a short written reply and you include a stamped -self-addressed envelope. But I do reply to E-mail. Please keep it in -English, as my foreign language skills are weak. If you call and I'm -not in, it's best to just try again later. I usually don't return -long distance phone calls, unless you leave a message that I can call -you collect. If you need any significant amount of my time, I am -available on a paid consulting basis, and I do return those calls. +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. If you need any significant amount of my time, +I am available on a paid consulting basis, and I do return those +calls. The most inconvenient mail I get is for some well-intentioned person -to send me a few dollars asking me for a copy of PGP. I can't send -it to them because of the legal threats from PKP (or worse-- -sometimes these requests are from foreign countries, and I would be -risking violating cryptographic export control laws). Even if there -were no legal hassles involved in sending PGP to them, they usually -don't send enough money to make it worth my time ($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,9 +2195,17 @@ 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. +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". 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. Future versions of PGP may have to change the data formats for messages, signatures, keys and key rings, in order to provide @@ -1988,57 +2214,57 @@ problems with this version of PGP. Futu conversion utilities to convert old keys, but you may have to dispose of old messages created with the old PGP. -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 +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 as munitions. This is determined by volatile State +kind of software just like they regard munitions. This is determined +by volatile State Department, Defense Department and Commerce 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. +controls, and I urge other people not to export 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. +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 version 2.4 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 ViaCrypt PGP or the +freeware PGP versions. Some foreign governments impose serious penalties on anyone inside their country for merely using encrypted communications. In some @@ -2047,6 +2273,104 @@ that kind of country, perhaps you need P +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. 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. The fund is run +by my lead defense attorney, Phil Dubois, here in Boulder. Please +send your contributions to: + + Philip Dubois + 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 email to him -- I'd rather he use his +valuable time to work on my case. + +If you want to read some press stories about this case, see the +following references: + + 1) William Bulkeley, "Cipher Probe", Wall Street Journal, Thursday + April 28th, 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) John Markoff, "Cyberspace Under Lock and Key", New York Times, + Sunday 13 Feb 1994. + 7) Philip Elmer-DeWitt, "Who Should Keep the Keys", Time, 14 Mar + 1994, page 90. + + +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 + 2104 West Peoria Avenue + Phoenix, Arizona 85029 + Phone: 602-944-0773 + Fax: 602-943-2601 + E-mail: viacrypt@acm.org + +ViaCrypt has a version of PGP for MSDOS, and a number of Unix +platforms. Other versions are under development. 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. + + +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. + + + Computer-Related Political Groups ================================= @@ -2055,19 +2379,12 @@ mention here some computer-related activ 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 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 @@ -2076,6 +2393,12 @@ computer technology to participate in pu impacts of computers on society. They can be reached at: 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. 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. @@ -2083,28 +2406,33 @@ the PGP release package. Recommended Introductory Readings ================================= -1) Dorothy Denning, "Cryptography and Data Security", Addison-Wesley, +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. + (This is a "must-read" article on PGP and other related topics.) Other Readings ============== -4) Ronald Rivest, "The MD5 Message Digest Algorithm", MIT Laboratory +6) 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 +7) 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 +8) 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) +9) Paul Wallich, "Electronic Envelopes", Scientific American, Feb + 1993, page 30. (This is an article on PGP) +10) William Bulkeley, "Cipher Probe", Wall Street Journal, 28 April + 1994, front page. (This is an article on PGP and Zimmermann) To Contact the Author @@ -2115,8 +2443,9 @@ 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 line available, if you arrange it via voice line. @@ -2133,101 +2462,61 @@ compression before encryption, and good 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, you must get pgp26.zip which contains the MSDOS binary +executable and the PGP User's Guide, and you can optionally get +pgp26src.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 pgp26src.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 email 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. + +Source and binary distributions of PGP are available from the Canadian +Broadcasting Corporation library, which is open to the public. It has +branches in Toronto, Montreal, and Vancouver. Contact Max Allen, at ++1 416 205-6017 if you have questions. Here are a few people and their email addresses or phone numbers you can contact in some countries to get information on local PGP -availability: +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