--- pgp/doc/changes.doc 2018/04/24 16:43:56 1.1.1.1 +++ pgp/doc/changes.doc 2018/04/24 16:45:58 1.1.1.3 @@ -1,391 +1,445 @@ -[Note: This file now contains all the information that used to be in -the newfor22.doc through newfor26.doc, starting with the most recent -information first] - -Changes to PGP 2.6.1 - -PGP 2.6.1 is a bugfix release of PGP 2.6. It fixes many bugs that have been -reported by the PGP user community since the original release of PGP 2.6 -back in May of 1994. The most notable bugs are the "xorbytes" bug that -resulted in less randomness then full Shannon Entropy for all key bits. -(Note: People who generated keys with PGP 2.6 do *not* need to generate -new keys). Another bug that manifested itself as "DOS error 8" errors has -also been fixed. It is also safe to edit your key userid with PGP 2.6.1 -even if you store your passphrase in the PGPPASS variable. - -PGP 2.6.1 will now accept keys up to length 2,048 bits, however it -will still only generate keys up to 1,024 bits. This is a phased -upgrade approach to increasing PGP's keysize. - -Changes to PGP 2.6: - -This version of PGP uses a version of RSAREF provided to MIT by RSA Data -Security for use in PGP. This version is legal within the U.S. See the -enclosed RSAREF license for full details. Basically this is a -non-commercial release. If you want to use it in a commercial or -governmental setting, talk to ViaCrypt (2014 West Peoria Avenue, -Phoenix, Arizona 85029, +1 602 944-0773). - -While PGP version 2.5 used RSAREF version 2.0, PGP 2.6 uses RSAREF -version 1. This change was made in consultation with RSA Data -Security, which is currently revising its version 2.0 distribution. -The version of RSAREF included with this distribution is RSAREF -version 1, not version 2.0. - -PGP 2.6 will read messages, signatures and keys created with versions of -PGP post 2.2. (i.e., 2.3, 2.3a, 2.4 and 2.5). However after 9/1/94 Version -2.6 will create messages which contain a version number of "3" in signatues, -messages and keys (see pgformat.doc for details). PGP2.6 will be able to -read these signatures, messages and keys, but prior versions will not. - -Versions prior to 2.6 would not permit a new signature to be added to a key -if there was an already existing signature from the same signer. Starting -with version 2.6 newer signatures will override older ones *as long as the -newer signature verifies*. This change is important because many keys have -signatures on them that were created by PGP version 2.2 or earlier. These -signatures can not be verified by PGP 2.5 or higher. Owners of keys with -these obsolete signatures should attempt to gather new signatures and -add them to their key. - -Significant changes were also made for version 2.5. Because version 2.6 is -coming out very soon after 2.5 (which was only really a beta test version) -readers are encouraged to read the file "newfor25.doc" as well as this file. - -Changes to PGP 2.5: - - ***** MOST IMPORTANT ***** - -This version of PGP uses RSAREF 2.0, so it's legal in the U.S.! The -RSAREF license forbids you to (among other things; see the license for -full details) "use the program to provide services to others for which -you are compensated in any manner", but that still covers a lot of -people. If you want to use it in a commercial or governmental -setting, talk to ViaCrypt (2014 West Peoria Avenue, Phoenix, Arizona -85029, +1 602 944-0773). - -PGP 2.5 should always be distributed with a copy of the RSAREF 2.0 -license of March 16, 1994 from RSA Data Security, Inc., so that all -users will be aware of their obligations under the RSAREF license. - -Since the RSAREF license conflicts with the GNU General Public License that -PGP was formerly distributed under, the GPL had to go. PGP is still -freely distributable, though. (From a copyright point of view; export -controls or some other legal hassle may apply.) - -*** IMPORTANT CHANGE: - -RSAREF 2.0 can understand only the pkcs_compat=1 formats for signatures -and encrypted files. This has been the default since 2.3, so old files -should not be too much of a problem, but old key signatures will -encounter difficulties. This change will result in a hole being ripped -in the "web of trust" as many old signatures are invalidated. Please check -your key rings (pgp -kc) and re-issue any signatures that have been -invalidated. PGP by default offers to remove such signatures. Even if you -leave them in, they are not trusted. - -Another RSAREF limitation is that it cannot cope with keys longer than -1024 bits. PGP now prints a reasonably polite error message in such a -case. - -OTHER CHANGES: - -The support files are thinner. The various contrib directory utilities -have not been updated since 2.3a, and since the PGP developers know how -annoying it is to have people using an ancient version and complaining -about a bug in a program that was fixed a year ago, they have been -omitted rather than annoy the contributors in this way. Also, the -language translation file, language.txt, is incomplete. The strings -that were in 2.3a are there, and some that could be updated without -much knowledge of the language, but others that are new to 2.5 are -untranslated. The format should be obvious and some tools for -manipulating the language traslations are included in the contrib -directory. - -Printed KeyIDs have been incresed to 32 bits, as there were enough keys -out there that 24-bit keyIDs were no longer sufficiently unique. The -previous 24-bit keyID is the LAST 6 digits of an 8-digit 32-bit keyID. -For example, what was printed as A966DD now appears as C7A966DD. - -The config-file options - pubring=, - secring=, and - randseed= -have been added. Hopefully, the uses will be obvious. With these, you can -keep keyrings anywhere you like. Of course, they can also be specified on -the command line with +pubring= (or abbreviated to +pub=). - -If the line - comment= -appears in the config file, the line "Comment: " appears in -ASCII armor output. Of course, you can also use this from the -command line, e.g. to include a filename in the ASCII armor, do -"pgp -eat +comment=filename filename recipient". - -PGP now enables clearsig by default. If you sign and ascii-armor a -text file, and do not encrypt it, it is clearsigned unless you ask -for this not to be done. - -The now enables textmode. Textmode detects non-text files and -automatically turns itself off, so it's quite safe to leave on all -the time. If you haven't got these defaults yourself, you might -want to enable them. - -All prompts and progress messages are now printed to stderr, to make them -easier to find and ensure they don't get confused with data on standard -output such as pgp -m output. - -PGP now wipes temp files (and files wiped with pgp -w) with pseudo-random -data in an attempt to force disk compressors to overwrite as much data as -possible. - -On Unix, if the directory /usr/local/lib/pgp exists, it is searched -fror help files, language translations, and the PGP documentation. On -VMS, the equivalent is PGP$LIBRARY:. (This is PGP_SYSTEM_DIR, defined -in fileio.h, if you need to change it for your site.) - -Also, it is searched for a default global config.txt. This file may -be overridden by a local config.txt, and it may not set pubring, -secring, randseed or myname (which should be strictly personal) - -The normal help files (pgp -h) are pgp.hlp or .hlp, such as -fr.hlp. Now, there is a separate help file for pgp -k, called pgpkey.hlp, -or key.hlp. No file is provided by default; PGP will use -its one-page internal help by default, but you can create such a file -at your site. - -On Unix systems, $PGPPATH defaults to $HOME/.pgp. - -PGP used to get confused if you had a keyring containing signatures from -you, but not your public key. (PGP can't use the signatures in this case. -Only signatures from keys in the keyring are counted.) -PGP still can't use the signatures, but prints better warning messages. -Also, adding a key on your secret key ring to your public keyring -now asks if the key should be considered ultimately-trusted. -Prviously, you had to run pgp -ke to force this check, which was -non-obvious. - -Due to a few people distributing PGP without the manual (including one -run of a few thousand CD-ROMs), and the resultant flood of phone calls -from confused users, PGP now looks to make sure a manual is somewhere in -the vicinity when running to discourage this sort of thing. (If you're -getting this warning and need details on how to get rid of it, try pgp -kg.) - -On Unix, PGP now figures out the resolution of the system clock at run -time for the purpose of computing the amount of entropy in keystroke -timings. This means that on many Unix machines, less typing should be -required to generate keys. (SunOS and Linux especially.) - -The small prime table used in generating keys has been enlarged, which -should speed up key generation somewhat. - -There was a bug in PGP 2.3a (and, in fact in 2.4 and dating back to 1.0!) -when generating primes 2 bits over a multiple of the unit size (16 bits -on PC's, 32 bits on most larger computers), if the processor doesn't deal -with expressions like "1<<32" by producing a result of 1. In practice, -that corresponds to a key size of 64*x+4 bits. - -Code changes: - -At the request of Windows programmers, the PSTR() macro used to translate -string has been renamed to LANG(). - -The random-number code has been *thoroughly* cleaned up. So has the -IDEA code and the MD5 code. The MD5 code was developed from scratch and -is available for public use. - -The Turbo C makefile was dropped in favour of a Borland C .prj file. -You can use makefile.msc as a guide if you need one for a command-line -Turbo C. - -Changes to PGP 2.4: - -- Fixed a bug with the -z option. If no passphrase was given, - PGP used to crash. - -- When using -c, the IV is generated properly now, and the randseed.bin - postwash is done. (This bug could have resulted in the same ciphertext - being generated for the same plaintext, if the same passphrase is used.) - -- Memory allocated with halloc() is now freed with hfree() in ztrees.c and - zdeflate.c. (MS-DOS only.) - -- The decompression code now detects end of input reliably, fixing a - bug that used to have it produce infinite amounts of output on come - corrputed input. Decompression has also been sped up. - -- PGP -m won't try to write its final output to the current directory. - This makes it less efficent if you want to save the text to a file, but - more secure if you don't. - -- Number of bits allowed when generating keys limited to 1024, in line - with the limits in RSAREF and BSAFE. It used to be higher, but - folks, if you think you need a key larger than that, do some research - into the complexity of factoring. - -- Version number changed to pgp2.4 - -News for PGP 2.3a - -There was a bug in PGP's handling of clear-signed messages when lines -were terminated with CR-LF pairs. This has been revamped. The previous -limit on the length of lines in clear-signed messages has been eliminated. - -The randseed.bin file was not closed when read, which resulted in it -not being rewritten with a new value under some operating systems. -Fixed. - -Not all of the bytes in randseed.bin were being used, resulting in less -randomness than desired when picking session keys. While it did not make -the compromise of session keys likely, it was undesirable and has been fixed. - -PGP should now compile with less difficulty under OS/2. -The Turbo C makefile was incorrect. Fixed. -The VMS build files were out of date. Fixed. - -PGP was not accepting octal escapes in the language.txt file that did not -begin with \0. \377 is now acceptable. -The language.txt file got mangled in the middle somehow. Fixed. - -News for PGP 2.3 - -This PGP 2.3 release has several bug fixes over PGP 2.2, and a few -new (although somewhat esoteric) features. Among them are: - -- An important bug: there was a bug with compression under MS-DOS which - caused the wrong piece of memory to be freed, with results that ranged - from none to undecodable messages to machine crashes. - -- When adding keys, PGP now properly closes all the files it opens, so - you don't run out of file handles (MS-DOS) or file descriptors (UNIX). - -- Sometimes PGP would not properly ask the user to set trust parameters - when keys were validated by adding new signatures. This has been - fixed. - -- When PGP messages are sent through a MIME mail system, a conflict - arises over the use of the '=' character. PGP can now decode ASCII - armored messages which have been mangled by MIME's quoting mechanism. - -- PGP previously kept track of one pass phrase (from the PGPPASS - environment variable, the file descriptor named by the PGPPASSFD - environment variable, a -z option, or previous user - prompts), and tried it if it needed a subsequent pass phrase. This - caused bugs if you attempted something that required two pass phrases, - such as pgp -sc (sign and conventionally encrypt). PGP now keeps - track of any number of pass phrases, including multiple -z options, - and uses them as necessary. Mostly, it just Does The Right Thing, - but if you care, the exact algorithm is as follows: - - - There is a pool of private-key pass phrases that starts out with the - contents of the PGPPASS environment variable (if any), and has every - pass phrase that is successfully used to unlock a private key added - to it. When a private key needs unlocking, every pass phrase in the - pool is tried first. - - There is a list of PGP pass phrases available for use by whatever needs - one. This is initialized with the -z command-line options and the - phrase read from the PGPPASSFD file descriptor. When a pass phrase - is needed, it is taken from the front of that list. When a pass - phrase is needed to unlock a secret key, every key on the list is tried, - and if it "fits" and unlocks the secret key, it is moved to the key - pass phrase pool. - - If the above fails to produce a pass phrase, the user is prompted to - supply one. - - Key generation (we need all the keystrokes we can get for random-number - accumulation) and key signing (to make sure the user really means to do - what they're doing) are exceptions; the user is always prompted for a - pass phrase under those circumstances. - -New options: - -+pkcs_compat=n - This defaults to 1, which tells PGP to generate encryption key - and signature blocks in a format derived from the PKCS standards. - This format is understood (but not generated) by PGP 2.2. If set - to 0, the old format is generated, which may be needed for - portability to PGP versions before 2.2. PGP is still incompatible - with the PKCS standards in many ways, but in future, values of 2 - or higher may be used to produce formats which are more compatible. - -Other notes: - -The MS-DOS executable was compiled with Borland C++ version 3.0, optimized -for maximum speed, except that jump optimisation was turned off. If it -is turned on, the Transform() function in md5.c is compiled incorrectly. -The pgp.prj file that was used is included in the source distribution. - -Thanks to everyone who worked on PGP and sent in bug reports. Two who -didn't make it into the manual are to Lindsay DuBois for a bit of last- -minute translation, and Reptilian Research for support in developing PGP. - -And thanks to the Cypherpunks who managed to get PGP so much attention -in Wired magazine recently. - -I hope you enjoy PGP! - - -Colin - -News for PGP 2.2 - -The main change since PGP 2.1 is a speedup in key management, and -the ability to encrypt for more than one recipient. Apart from -this there are some bugfixes and some new options to make it easier -to use PGP from shell scripts or mailers. - -You can encrypt for more than one recipient by specifying additional -userids on the command line eg: - - pgp -e plaintext Alice Bob Carol - - -Some notes about the changes: - -- PGP doesn't do a keycheck on a keyfile before it is added anymore, -this is to speed up merging a big keyfile with your public keyring which -may already have most of the keys in the keyfile you are adding. After -PGP has checked a signature it sets a flag in your public keyring to -mark this signature as checked. Because PGP 2.1 didn't have these -flags, PGP will check *all* signatures on your keyring the first time -you add a key with PGP 2.2. After that PGP will only check new -signatures. Also by using an older version than 2.2 on your keyring you -will clear these flags again. - - -New options: - -+interactive - If you add a keyfile, PGP will ask for each new key if it should - be added to your keyring. - -Options for use in shell scripts: - -+verbose=n - The default is 1. With +verbose=0, PGP will only print an error - message if something goes wrong. With +verbose=2, PGP will tell - you what it's doing in detail suitable for debugging. - -+force - Overwrite output file without asking, or with -kr: remove key - without asking (only if it has just one userid). - -+batchmode - With this option PGP won't ask any questions or prompt for - alternate file names. Some of the key commands still need - user interaction and can't be done from a shell script. - You can also use this option to check if a file has a good - signature. If the input file did not have a signature the exit - code will be 1, if the file had a signature and if it checked OK - the exit code will be 0. Note that if the input file has more - than one armored messages, a good signature on one of these - messages will make the exit code 0 (if there are no errors). - -These "long" options can be abbreviated as long as the abbreviation is -unambiguous. "interactive" and "verbose" can also be set in config.txt; -you can then turn these flags off on the command line with +option=. - - -Some of the bug fixes: - -- Key lookup on keyID (eg 0x12AB) fixed for -ks/-krs. - -- Dearmoring of Macintosh type text files (CR only) now also works. +[Note: This file now contains all the information that used to be in +the newfor22.doc through newfor26.doc, starting with the most recent +information first] + +Changes for PGP 2.6.2i/2.6.3i + + The most important changes are described in the file readme.1st. See + pgp262i.diffs and pgp263i.diffs for a more detailed list of changes. + +Changes for PGP 2.6.2 + +- Some people reported a "bug" that you could stick an extra paragraph + in the beginning of a clear-signed message and PGP would still report + a good signature. PGP allows comment "headers" before ASCII-armor + blocks (like the Version: header that's there for debugging + purposes), terminated, as with e-mail and usenet messages, by a blank + line. These headers are just window dressing; PGP ignores them. So + this is actually a "feature"; the bug is that people think it's part + of the signed message. There are a number of ways to fake the + visual appearance of a blank line using common file-viewing + utilities, a blank line is easy to miss even if you know about it, + and headers are not presently used in clear-signed messages. So now + headers are forbidden at the beginning of a clear-signed message. + Also, PGP enforces an RFC-822-like syntax on header lines before ASCII + armor. + Note that in no case has PGP's output ever been compromised; the problem + arises only if people see the "good signature" message but try to read + the input directly to see what was signed. +- Closed files properly in a number of error situations, which also helps + PGP run under OS/2. (Contributed by John Frickson) +- Improved OS/2 makefile target. +- Added a few contributed makefile entries (hpux9, amix, encore, machten) +- Fixed MAX_BIT_PRECISION to 2048. +- Changed the +'s printed during prime generation (to indicate that a + candidate prime just passed a Fermat test) to *'s, since some people's + modems go into command mode when fed slow strings of +'s. +- Added a copyright notice for RSAREF. +- Updated the manual-checking error message to tell people that they + can find a simple fix if they RTFM. Hopefully this will further + encourage people to complain to whoever distributed PGP without the + manual instead of just getting frustrated. +- Fixed (at long last) PGP's table of file extensions to know that + gzip is .gz, and not .z. (Which was the preferred form some time ago.) +- Fixed a bug in key editing with the public and secret keyrings in + different directories. The old code was assuming they were in the same + directory, which used to be a safe assumption, but no more. +- Fixed a problem with access() on VMS returning failure when fed a + directory that exists. +- Enlarged randseed.bin to hold more entropy, and arranged for it to be + saved on each invocation of PGP so the entropy from keystrokes while + not encrypting would be available for future use. See the comment in + random.c for implementation details. +- A problem checking separate signatures on files with upper-128 + characters has been fixed. PGP was assuming that since MS-DOS uses + CRLF line endings, files for signature testing are already in canonical + test format. This is not true if upper-128 characters are in use. +- Got rid of pkcs_compat as redundant. + +Changes to PGP 2.6.1 + +PGP 2.6.1 is a bugfix release of PGP 2.6. It fixes many bugs that have been +reported by the PGP user community since the original release of PGP 2.6 +back in May of 1994. The most notable bugs are the "xorbytes" bug that +resulted in less randomness then full Shannon Entropy for all key bits. +(Note: People who generated keys with PGP 2.6 do *not* need to generate +new keys). Another bug that manifested itself as "DOS error 8" errors has +also been fixed. It is also safe to edit your key userid with PGP 2.6.1 +even if you store your passphrase in the PGPPASS variable. + +PGP 2.6.1 will now accept keys up to length 2,048 bits, however it +will still only generate keys up to 1,024 bits. This is a phased +upgrade approach to increasing PGP's keysize. + +Changes to PGP 2.6: + +This version of PGP uses a version of RSAREF provided to MIT by RSA Data +Security for use in PGP. This version is legal within the U.S. See the +enclosed RSAREF license for full details. Basically this is a +non-commercial release. If you want to use it in a commercial or +governmental setting, talk to ViaCrypt (2014 West Peoria Avenue, +Phoenix, Arizona 85029, +1 602 944-0773). + +While PGP version 2.5 used RSAREF version 2.0, PGP 2.6 uses RSAREF +version 1. This change was made in consultation with RSA Data +Security, which is currently revising its version 2.0 distribution. +The version of RSAREF included with this distribution is RSAREF +version 1, not version 2.0. + +PGP 2.6 will read messages, signatures and keys created with versions of +PGP post 2.2. (i.e., 2.3, 2.3a, 2.4 and 2.5). However after 9/1/94 Version +2.6 will create messages which contain a version number of "3" in signatues, +messages and keys (see pgformat.doc for details). PGP2.6 will be able to +read these signatures, messages and keys, but prior versions will not. + +Versions prior to 2.6 would not permit a new signature to be added to a key +if there was an already existing signature from the same signer. Starting +with version 2.6 newer signatures will override older ones *as long as the +newer signature verifies*. This change is important because many keys have +signatures on them that were created by PGP version 2.2 or earlier. These +signatures can not be verified by PGP 2.5 or higher. Owners of keys with +these obsolete signatures should attempt to gather new signatures and +add them to their key. + +Significant changes were also made for version 2.5. Because version 2.6 is +coming out very soon after 2.5 (which was only really a beta test version) +readers are encouraged to read the file "newfor25.doc" as well as this file. + +Changes to PGP 2.5: + + ***** MOST IMPORTANT ***** + +This version of PGP uses RSAREF 2.0, so it's legal in the U.S.! The +RSAREF license forbids you to (among other things; see the license for +full details) "use the program to provide services to others for which +you are compensated in any manner", but that still covers a lot of +people. If you want to use it in a commercial or governmental +setting, talk to ViaCrypt (2014 West Peoria Avenue, Phoenix, Arizona +85029, +1 602 944-0773). + +PGP 2.5 should always be distributed with a copy of the RSAREF 2.0 +license of March 16, 1994 from RSA Data Security, Inc., so that all +users will be aware of their obligations under the RSAREF license. + +Since the RSAREF license conflicts with the GNU General Public License that +PGP was formerly distributed under, the GPL had to go. PGP is still +freely distributable, though. (From a copyright point of view; export +controls or some other legal hassle may apply.) + +*** IMPORTANT CHANGE: + +RSAREF 2.0 can understand only the pkcs_compat=1 formats for signatures +and encrypted files. This has been the default since 2.3, so old files +should not be too much of a problem, but old key signatures will +encounter difficulties. This change will result in a hole being ripped +in the "web of trust" as many old signatures are invalidated. Please check +your key rings (pgp -kc) and re-issue any signatures that have been +invalidated. PGP by default offers to remove such signatures. Even if you +leave them in, they are not trusted. + +Another RSAREF limitation is that it cannot cope with keys longer than +1024 bits. PGP now prints a reasonably polite error message in such a +case. + +OTHER CHANGES: + +The support files are thinner. The various contrib directory utilities +have not been updated since 2.3a, and since the PGP developers know how +annoying it is to have people using an ancient version and complaining +about a bug in a program that was fixed a year ago, they have been +omitted rather than annoy the contributors in this way. Also, the +language translation file, language.txt, is incomplete. The strings +that were in 2.3a are there, and some that could be updated without +much knowledge of the language, but others that are new to 2.5 are +untranslated. The format should be obvious and some tools for +manipulating the language traslations are included in the contrib +directory. + +Printed KeyIDs have been incresed to 32 bits, as there were enough keys +out there that 24-bit keyIDs were no longer sufficiently unique. The +previous 24-bit keyID is the LAST 6 digits of an 8-digit 32-bit keyID. +For example, what was printed as A966DD now appears as C7A966DD. + +The config-file options + pubring=, + secring=, and + randseed= +have been added. Hopefully, the uses will be obvious. With these, you can +keep keyrings anywhere you like. Of course, they can also be specified on +the command line with +pubring= (or abbreviated to +pub=). + +If the line + comment= +appears in the config file, the line "Comment: " appears in +ASCII armor output. Of course, you can also use this from the +command line, e.g. to include a filename in the ASCII armor, do +"pgp -eat +comment=filename filename recipient". + +PGP now enables clearsig by default. If you sign and ascii-armor a +text file, and do not encrypt it, it is clearsigned unless you ask +for this not to be done. + +The now enables textmode. Textmode detects non-text files and +automatically turns itself off, so it's quite safe to leave on all +the time. If you haven't got these defaults yourself, you might +want to enable them. + +All prompts and progress messages are now printed to stderr, to make them +easier to find and ensure they don't get confused with data on standard +output such as pgp -m output. + +PGP now wipes temp files (and files wiped with pgp -w) with pseudo-random +data in an attempt to force disk compressors to overwrite as much data as +possible. + +On Unix, if the directory /usr/local/lib/pgp exists, it is searched +fror help files, language translations, and the PGP documentation. On +VMS, the equivalent is PGP$LIBRARY:. (This is PGP_SYSTEM_DIR, defined +in fileio.h, if you need to change it for your site.) + +Also, it is searched for a default global config.txt. This file may +be overridden by a local config.txt, and it may not set pubring, +secring, randseed or myname (which should be strictly personal) + +The normal help files (pgp -h) are pgp.hlp or .hlp, such as +fr.hlp. Now, there is a separate help file for pgp -k, called pgpkey.hlp, +or key.hlp. No file is provided by default; PGP will use +its one-page internal help by default, but you can create such a file +at your site. + +On Unix systems, $PGPPATH defaults to $HOME/.pgp. + +PGP used to get confused if you had a keyring containing signatures from +you, but not your public key. (PGP can't use the signatures in this case. +Only signatures from keys in the keyring are counted.) +PGP still can't use the signatures, but prints better warning messages. +Also, adding a key on your secret key ring to your public keyring +now asks if the key should be considered ultimately-trusted. +Prviously, you had to run pgp -ke to force this check, which was +non-obvious. + +Due to a few people distributing PGP without the manual (including one +run of a few thousand CD-ROMs), and the resultant flood of phone calls +from confused users, PGP now looks to make sure a manual is somewhere in +the vicinity when running to discourage this sort of thing. (If you're +getting this warning and need details on how to get rid of it, try pgp -kg.) + +On Unix, PGP now figures out the resolution of the system clock at run +time for the purpose of computing the amount of entropy in keystroke +timings. This means that on many Unix machines, less typing should be +required to generate keys. (SunOS and Linux especially.) + +The small prime table used in generating keys has been enlarged, which +should speed up key generation somewhat. + +There was a bug in PGP 2.3a (and, in fact in 2.4 and dating back to 1.0!) +when generating primes 2 bits over a multiple of the unit size (16 bits +on PC's, 32 bits on most larger computers), if the processor doesn't deal +with expressions like "1<<32" by producing a result of 1. In practice, +that corresponds to a key size of 64*x+4 bits. + +Code changes: + +At the request of Windows programmers, the PSTR() macro used to translate +string has been renamed to LANG(). + +The random-number code has been *thoroughly* cleaned up. So has the +IDEA code and the MD5 code. The MD5 code was developed from scratch and +is available for public use. + +The Turbo C makefile was dropped in favour of a Borland C .prj file. +You can use makefile.msc as a guide if you need one for a command-line +Turbo C. + +Changes to PGP 2.4: + +- Fixed a bug with the -z option. If no passphrase was given, + PGP used to crash. + +- When using -c, the IV is generated properly now, and the randseed.bin + postwash is done. (This bug could have resulted in the same ciphertext + being generated for the same plaintext, if the same passphrase is used.) + +- Memory allocated with halloc() is now freed with hfree() in ztrees.c and + zdeflate.c. (MS-DOS only.) + +- The decompression code now detects end of input reliably, fixing a + bug that used to have it produce infinite amounts of output on come + corrputed input. Decompression has also been sped up. + +- PGP -m won't try to write its final output to the current directory. + This makes it less efficent if you want to save the text to a file, but + more secure if you don't. + +- Number of bits allowed when generating keys limited to 1024, in line + with the limits in RSAREF and BSAFE. It used to be higher, but + folks, if you think you need a key larger than that, do some research + into the complexity of factoring. + +- Version number changed to pgp2.4 + +News for PGP 2.3a + +There was a bug in PGP's handling of clear-signed messages when lines +were terminated with CR-LF pairs. This has been revamped. The previous +limit on the length of lines in clear-signed messages has been eliminated. + +The randseed.bin file was not closed when read, which resulted in it +not being rewritten with a new value under some operating systems. +Fixed. + +Not all of the bytes in randseed.bin were being used, resulting in less +randomness than desired when picking session keys. While it did not make +the compromise of session keys likely, it was undesirable and has been fixed. + +PGP should now compile with less difficulty under OS/2. +The Turbo C makefile was incorrect. Fixed. +The VMS build files were out of date. Fixed. + +PGP was not accepting octal escapes in the language.txt file that did not +begin with \0. \377 is now acceptable. +The language.txt file got mangled in the middle somehow. Fixed. + +News for PGP 2.3 + +This PGP 2.3 release has several bug fixes over PGP 2.2, and a few +new (although somewhat esoteric) features. Among them are: + +- An important bug: there was a bug with compression under MS-DOS which + caused the wrong piece of memory to be freed, with results that ranged + from none to undecodable messages to machine crashes. + +- When adding keys, PGP now properly closes all the files it opens, so + you don't run out of file handles (MS-DOS) or file descriptors (UNIX). + +- Sometimes PGP would not properly ask the user to set trust parameters + when keys were validated by adding new signatures. This has been + fixed. + +- When PGP messages are sent through a MIME mail system, a conflict + arises over the use of the '=' character. PGP can now decode ASCII + armored messages which have been mangled by MIME's quoting mechanism. + +- PGP previously kept track of one pass phrase (from the PGPPASS + environment variable, the file descriptor named by the PGPPASSFD + environment variable, a -z option, or previous user + prompts), and tried it if it needed a subsequent pass phrase. This + caused bugs if you attempted something that required two pass phrases, + such as pgp -sc (sign and conventionally encrypt). PGP now keeps + track of any number of pass phrases, including multiple -z options, + and uses them as necessary. Mostly, it just Does The Right Thing, + but if you care, the exact algorithm is as follows: + + - There is a pool of private-key pass phrases that starts out with the + contents of the PGPPASS environment variable (if any), and has every + pass phrase that is successfully used to unlock a private key added + to it. When a private key needs unlocking, every pass phrase in the + pool is tried first. + - There is a list of PGP pass phrases available for use by whatever needs + one. This is initialized with the -z command-line options and the + phrase read from the PGPPASSFD file descriptor. When a pass phrase + is needed, it is taken from the front of that list. When a pass + phrase is needed to unlock a secret key, every key on the list is tried, + and if it "fits" and unlocks the secret key, it is moved to the key + pass phrase pool. + - If the above fails to produce a pass phrase, the user is prompted to + supply one. + + Key generation (we need all the keystrokes we can get for random-number + accumulation) and key signing (to make sure the user really means to do + what they're doing) are exceptions; the user is always prompted for a + pass phrase under those circumstances. + +New options: + ++pkcs_compat=n + This defaults to 1, which tells PGP to generate encryption key + and signature blocks in a format derived from the PKCS standards. + This format is understood (but not generated) by PGP 2.2. If set + to 0, the old format is generated, which may be needed for + portability to PGP versions before 2.2. PGP is still incompatible + with the PKCS standards in many ways, but in future, values of 2 + or higher may be used to produce formats which are more compatible. + +Other notes: + +The MS-DOS executable was compiled with Borland C++ version 3.0, optimized +for maximum speed, except that jump optimisation was turned off. If it +is turned on, the Transform() function in md5.c is compiled incorrectly. +The pgp.prj file that was used is included in the source distribution. + +Thanks to everyone who worked on PGP and sent in bug reports. Two who +didn't make it into the manual are to Lindsay DuBois for a bit of last- +minute translation, and Reptilian Research for support in developing PGP. + +And thanks to the Cypherpunks who managed to get PGP so much attention +in Wired magazine recently. + +I hope you enjoy PGP! + + -Colin + +News for PGP 2.2 + +The main change since PGP 2.1 is a speedup in key management, and +the ability to encrypt for more than one recipient. Apart from +this there are some bugfixes and some new options to make it easier +to use PGP from shell scripts or mailers. + +You can encrypt for more than one recipient by specifying additional +userids on the command line eg: + + pgp -e plaintext Alice Bob Carol + + +Some notes about the changes: + +- PGP doesn't do a keycheck on a keyfile before it is added anymore, +this is to speed up merging a big keyfile with your public keyring which +may already have most of the keys in the keyfile you are adding. After +PGP has checked a signature it sets a flag in your public keyring to +mark this signature as checked. Because PGP 2.1 didn't have these +flags, PGP will check *all* signatures on your keyring the first time +you add a key with PGP 2.2. After that PGP will only check new +signatures. Also by using an older version than 2.2 on your keyring you +will clear these flags again. + + +New options: + ++interactive + If you add a keyfile, PGP will ask for each new key if it should + be added to your keyring. + +Options for use in shell scripts: + ++verbose=n + The default is 1. With +verbose=0, PGP will only print an error + message if something goes wrong. With +verbose=2, PGP will tell + you what it's doing in detail suitable for debugging. + ++force + Overwrite output file without asking, or with -kr: remove key + without asking (only if it has just one userid). + ++batchmode + With this option PGP won't ask any questions or prompt for + alternate file names. Some of the key commands still need + user interaction and can't be done from a shell script. + You can also use this option to check if a file has a good + signature. If the input file did not have a signature the exit + code will be 1, if the file had a signature and if it checked OK + the exit code will be 0. Note that if the input file has more + than one armored messages, a good signature on one of these + messages will make the exit code 0 (if there are no errors). + +These "long" options can be abbreviated as long as the abbreviation is +unambiguous. "interactive" and "verbose" can also be set in config.txt; +you can then turn these flags off on the command line with +option=. + + +Some of the bug fixes: + +- Key lookup on keyID (eg 0x12AB) fixed for -ks/-krs. + +- Dearmoring of Macintosh type text files (CR only) now also works.