TEXT   41


Guest on 15th May 2022 04:14:18 AM

  1. [Note: This file now contains all the information that used to be in
  2. the newfor22.doc through newfor26.doc, starting with the most recent
  3. information first]
  5. Changes for PGP 2.6.2i
  7.   The most important changes are described in the file readme.1st. See
  8.   diffs.doc for a more detailed list of changes.
  10. Changes for PGP 2.6.2
  12. - Some people reported a "bug" that you could stick an extra paragraph
  13.   in the beginning of a clear-signed message and PGP would still report
  14.   a good signature.  PGP allows comment "headers" before ASCII-armor
  15.   blocks (like the Version: header that's there for debugging
  16.   purposes), terminated, as with e-mail and usenet messages, by a blank
  17.   line.  These headers are just window dressing; PGP ignores them.  So
  18.   this is actually a "feature"; the bug is that people think it's part
  19.   of the signed message.  There are a number of ways to fake the
  20.   visual appearance of a blank line using common file-viewing
  21.   utilities, a blank line is easy to miss even if you know about it,
  22.   and headers are not presently used in clear-signed messages.  So now
  23.   headers are forbidden at the beginning of a clear-signed message.
  24.   Also, PGP enforces an RFC-822-like syntax on header lines before ASCII
  25.   armor.
  26.   Note that in no case has PGP's output ever been compromised; the problem
  27.   arises only if people see the "good signature" message but try to read
  28.   the input directly to see what was signed.
  29. - Closed files properly in a number of error situations, which also helps
  30.   PGP run under OS/2. (Contributed by John Frickson)
  31. - Improved OS/2 makefile target.
  32. - Added a few contributed makefile entries (hpux9, amix, encore, machten)
  33. - Fixed MAX_BIT_PRECISION to 2048.
  34. - Changed the +'s printed during prime generation (to indicate that a
  35.   candidate prime just passed a Fermat test) to *'s, since some people's
  36.   modems go into command mode when fed slow strings of +'s.
  37. - Added a copyright notice for RSAREF.
  38. - Updated the manual-checking error message to tell people that they
  39.   can find a simple fix if they RTFM.  Hopefully this will further
  40.   encourage people to complain to whoever distributed PGP without the
  41.   manual instead of just getting frustrated.
  42. - Fixed (at long last) PGP's table of file extensions to know that
  43.   gzip is .gz, and not .z. (Which was the preferred form some time ago.)
  44. - Fixed a bug in key editing with the public and secret keyrings in
  45.   different directories.  The old code was assuming they were in the same
  46.   directory, which used to be a safe assumption, but no more.
  47. - Fixed a problem with access() on VMS returning failure when fed a
  48.   directory that exists.
  49. - Enlarged randseed.bin to hold more entropy, and arranged for it to be
  50.   saved on each invocation of PGP so the entropy from keystrokes while
  51.   not encrypting would be available for future use.  See the comment in
  52.   random.c for implementation details.
  53. - A problem checking separate signatures on files with upper-128
  54.   characters has been fixed.  PGP was assuming that since MS-DOS uses
  55.   CRLF line endings, files for signature testing are already in canonical
  56.   test format.  This is not true if upper-128 characters are in use.
  57. - Got rid of pkcs_compat as redundant.
  59. Changes to PGP 2.6.1
  61. PGP 2.6.1 is a bugfix release of PGP 2.6. It fixes many bugs that have been
  62. reported by the PGP user community since the original release of PGP 2.6
  63. back in May of 1994. The most notable bugs are the "xorbytes" bug that
  64. resulted in less randomness then full Shannon Entropy for all key bits.
  65. (Note: People who generated keys with PGP 2.6 do *not* need to generate
  66. new keys). Another bug that manifested itself as "DOS error 8" errors has
  67. also been fixed. It is also safe to edit your key userid with PGP 2.6.1
  68. even if you store your passphrase in the PGPPASS variable.
  70. PGP 2.6.1 will now accept keys up to length 2,048 bits, however it
  71. will still only generate keys up to 1,024 bits. This is a phased
  72. upgrade approach to increasing PGP's keysize.
  74. Changes to PGP 2.6:
  76. This version of PGP uses a version of RSAREF provided to MIT by RSA Data
  77. Security for use in PGP. This version is legal within the U.S.  See the
  78. enclosed RSAREF license for full details. Basically this is a
  79. non-commercial release. If you want to use it in a commercial or
  80. governmental setting, talk to ViaCrypt (2014 West Peoria Avenue,
  81. Phoenix, Arizona 85029, +1 602 944-0773).
  83. While PGP version 2.5 used RSAREF version 2.0, PGP 2.6 uses RSAREF
  84. version 1.  This change was made in consultation with RSA Data
  85. Security, which is currently revising its version 2.0 distribution.
  86. The version of RSAREF included with this distribution is RSAREF
  87. version 1, not version 2.0.
  89. PGP 2.6 will read messages, signatures and keys created with versions of
  90. PGP post 2.2. (i.e., 2.3, 2.3a, 2.4 and 2.5). However after 9/1/94 Version
  91. 2.6 will create messages which contain a version number of "3" in signatues,
  92. messages and keys (see pgformat.doc for details). PGP2.6 will be able to
  93. read these signatures, messages and keys, but prior versions will not.
  95. Versions prior to 2.6 would not permit a new signature to be added to a key
  96. if there was an already existing signature from the same signer. Starting
  97. with version 2.6 newer signatures will override older ones *as long as the
  98. newer signature verifies*. This change is important because many keys have
  99. signatures on them that were created by PGP version 2.2 or earlier. These
  100. signatures can not be verified by PGP 2.5 or higher. Owners of keys with
  101. these obsolete signatures should attempt to gather new signatures and
  102. add them to their key.
  104. Significant changes were also made for version 2.5. Because version 2.6 is
  105. coming out very soon after 2.5 (which was only really a beta test version)
  106. readers are encouraged to read the file "newfor25.doc" as well as this file.
  108. Changes to PGP 2.5:
  110.                  ***** MOST IMPORTANT *****
  112. This version of PGP uses RSAREF 2.0, so it's legal in the U.S.!  The
  113. RSAREF license forbids you to (among other things; see the license for
  114. full details) "use the program to provide services to others for which
  115. you are compensated in any manner", but that still covers a lot of
  116. people.  If you want to use it in a commercial or governmental
  117. setting, talk to ViaCrypt (2014 West Peoria Avenue, Phoenix, Arizona
  118. 85029, +1 602 944-0773).
  120. PGP 2.5 should always be distributed with a copy of the RSAREF 2.0
  121. license of March 16, 1994 from RSA Data Security, Inc., so that all
  122. users will be aware of their obligations under the RSAREF license.
  124. Since the RSAREF license conflicts with the GNU General Public License that
  125. PGP was formerly distributed under, the GPL had to go.  PGP is still
  126. freely distributable, though.  (From a copyright point of view; export
  127. controls or some other legal hassle may apply.)
  131. RSAREF 2.0 can understand only the pkcs_compat=1 formats for signatures
  132. and encrypted files.  This has been the default since 2.3, so old files
  133. should not be too much of a problem, but old key signatures will
  134. encounter difficulties.  This change will result in a hole being ripped
  135. in the "web of trust" as many old signatures are invalidated.  Please check
  136. your key rings (pgp -kc) and re-issue any signatures that have been
  137. invalidated.  PGP by default offers to remove such signatures.  Even if you
  138. leave them in, they are not trusted.
  140. Another RSAREF limitation is that it cannot cope with keys longer than
  141. 1024 bits.  PGP now prints a reasonably polite error message in such a
  142. case.
  146. The support files are thinner.  The various contrib directory utilities
  147. have not been updated since 2.3a, and since the PGP developers know how
  148. annoying it is to have people using an ancient version and complaining
  149. about a bug in a program that was fixed a year ago, they have been
  150. omitted rather than annoy the contributors in this way.  Also, the
  151. language translation file, language.txt, is incomplete.  The strings
  152. that were in 2.3a are there, and some that could be updated without
  153. much knowledge of the language, but others that are new to 2.5 are
  154. untranslated.  The format should be obvious and some tools for
  155. manipulating the language traslations are included in the contrib
  156. directory.
  158. Printed KeyIDs have been incresed to 32 bits, as there were enough keys
  159. out there that 24-bit keyIDs were no longer sufficiently unique.  The
  160. previous 24-bit keyID is the LAST 6 digits of an 8-digit 32-bit keyID.
  161. For example, what was printed as A966DD now appears as C7A966DD.
  163. The config-file options
  164.         pubring=<filename>,
  165.         secring=<filename>, and
  166.         randseed=<filename>
  167. have been added.  Hopefully, the uses will be obvious.  With these, you can
  168. keep keyrings anywhere you like.  Of course, they can also be specified on
  169. the command line with +pubring= (or abbreviated to +pub=).
  171. If the line
  172.         comment=<string>
  173. appears in the config file, the line "Comment: <string>" appears in
  174. ASCII armor output.  Of course, you can also use this from the
  175. command line, e.g. to include a filename in the ASCII armor, do
  176. "pgp -eat +comment=filename filename recipient".
  178. PGP now enables clearsig by default.  If you sign and ascii-armor a
  179. text file, and do not encrypt it, it is clearsigned unless you ask
  180. for this not to be done.
  182. The now enables textmode.  Textmode detects non-text files and
  183. automatically turns itself off, so it's quite safe to leave on all
  184. the time.  If you haven't got these defaults yourself, you might
  185. want to enable them.
  187. All prompts and progress messages are now printed to stderr, to make them
  188. easier to find and ensure they don't get confused with data on standard
  189. output such as pgp -m output.
  191. PGP now wipes temp files (and files wiped with pgp -w) with pseudo-random
  192. data in an attempt to force disk compressors to overwrite as much data as
  193. possible.
  195. On Unix, if the directory /usr/local/lib/pgp exists, it is searched
  196. fror help files, language translations, and the PGP documentation.  On
  197. VMS, the equivalent is PGP$LIBRARY:.  (This is PGP_SYSTEM_DIR, defined
  198. in fileio.h, if you need to change it for your site.)
  200. Also, it is searched for a default global config.txt.  This file may
  201. be overridden by a local config.txt, and it may not set pubring,
  202. secring, randseed or myname (which should be strictly personal)
  204. The normal help files (pgp -h) are pgp.hlp or <language>.hlp, such as
  205. fr.hlp.  Now, there is a separate help file for pgp -k, called pgpkey.hlp,
  206. or <language>key.hlp.  No file is provided by default; PGP will use
  207. its one-page internal help by default, but you can create such a file
  208. at your site.
  210. On Unix systems, $PGPPATH defaults to $HOME/.pgp.
  212. PGP used to get confused if you had a keyring containing signatures from
  213. you, but not your public key.  (PGP can't use the signatures in this case.
  214. Only signatures from keys in the keyring are counted.)
  215. PGP still can't use the signatures, but prints better warning messages.
  216. Also, adding a key on your secret key ring to your public keyring
  217. now asks if the key should be considered ultimately-trusted.
  218. Prviously, you had to run pgp -ke to force this check, which was
  219. non-obvious.
  221. Due to a few people distributing PGP without the manual (including one
  222. run of a few thousand CD-ROMs), and the resultant flood of phone calls
  223. from confused users, PGP now looks to make sure a manual is somewhere in
  224. the vicinity when running to discourage this sort of thing.  (If you're
  225. getting this warning and need details on how to get rid of it, try pgp -kg.)
  227. On Unix, PGP now figures out the resolution of the system clock at run
  228. time for the purpose of computing the amount of entropy in keystroke
  229. timings.  This means that on many Unix machines, less typing should be
  230. required to generate keys.  (SunOS and Linux especially.)
  232. The small prime table used in generating keys has been enlarged, which
  233. should speed up key generation somewhat.
  235. There was a bug in PGP 2.3a (and, in fact in 2.4 and dating back to 1.0!)
  236. when generating primes 2 bits over a multiple of the unit size (16 bits
  237. on PC's, 32 bits on most larger computers), if the processor doesn't deal
  238. with expressions like "1<<32" by producing a result of 1.  In practice,
  239. that corresponds to a key size of 64*x+4 bits.
  241. Code changes:
  243. At the request of Windows programmers, the PSTR() macro used to translate
  244. string has been renamed to LANG().
  246. The random-number code has been *thoroughly* cleaned up.  So has the
  247. IDEA code and the MD5 code.  The MD5 code was developed from scratch and
  248. is available for public use.
  250. The Turbo C makefile was dropped in favour of a Borland C .prj file.
  251. You can use makefile.msc as a guide if you need one for a command-line
  252. Turbo C.
  254. Changes to PGP 2.4:
  256. - Fixed a bug with the -z <passphrase> option.  If no passphrase was given,
  257.   PGP used to crash.
  259. - When using -c, the IV is generated properly now, and the randseed.bin
  260.   postwash is done.  (This bug could have resulted in the same ciphertext
  261.   being generated for the same plaintext, if the same passphrase is used.)
  263. - Memory allocated with halloc() is now freed with hfree() in ztrees.c and
  264.   zdeflate.c.  (MS-DOS only.)
  266. - The decompression code now detects end of input reliably, fixing a
  267.   bug that used to have it produce infinite amounts of output on come
  268.   corrputed input.  Decompression has also been sped up.
  270. - PGP -m won't try to write its final output to the current directory.
  271.   This makes it less efficent if you want to save the text to a file, but
  272.   more secure if you don't.
  274. - Number of bits allowed when generating keys limited to 1024, in line
  275.   with the limits in RSAREF and BSAFE.  It used to be higher, but
  276.   folks, if you think you need a key larger than that, do some research
  277.   into the complexity of factoring.
  279. - Version number changed to pgp2.4
  281. News for PGP 2.3a
  283. There was a bug in PGP's handling of clear-signed messages when lines
  284. were terminated with CR-LF pairs.  This has been revamped.  The previous
  285. limit on the length of lines in clear-signed messages has been eliminated.
  287. The randseed.bin file was not closed when read, which resulted in it
  288. not being rewritten with a new value under some operating systems.
  289. Fixed.
  291. Not all of the bytes in randseed.bin were being used, resulting in less
  292. randomness than desired when picking session keys.  While it did not make
  293. the compromise of session keys likely, it was undesirable and has been fixed.
  295. PGP should now compile with less difficulty under OS/2.
  296. The Turbo C makefile was incorrect.  Fixed.
  297. The VMS build files were out of date.  Fixed.
  299. PGP was not accepting octal escapes in the language.txt file that did not
  300. begin with \0.  \377 is now acceptable.
  301. The language.txt file got mangled in the middle somehow.  Fixed.
  303. News for PGP 2.3
  305. This PGP 2.3 release has several bug fixes over PGP 2.2, and a few
  306. new (although somewhat esoteric) features.  Among them are:
  308. - An important bug: there was a bug with compression under MS-DOS which
  309.   caused the wrong piece of memory to be freed, with results that ranged
  310.   from none to undecodable messages to machine crashes.
  312. - When adding keys, PGP now properly closes all the files it opens, so
  313.   you don't run out of file handles (MS-DOS) or file descriptors (UNIX).
  315. - Sometimes PGP would not properly ask the user to set trust parameters
  316.   when keys were validated by adding new signatures.  This has been
  317.   fixed.
  319. - When PGP messages are sent through a MIME mail system, a conflict
  320.   arises over the use of the '=' character.  PGP can now decode ASCII
  321.   armored messages which have been mangled by MIME's quoting mechanism.
  323. - PGP previously kept track of one pass phrase (from the PGPPASS
  324.   environment variable, the file descriptor named by the PGPPASSFD
  325.   environment variable, a -z <password> option, or previous user
  326.   prompts), and tried it if it needed a subsequent pass phrase.  This
  327.   caused bugs if you attempted something that required two pass phrases,
  328.   such as pgp -sc (sign and conventionally encrypt).  PGP now keeps
  329.   track of any number of pass phrases, including multiple -z options,
  330.   and uses them as necessary.  Mostly, it just Does The Right Thing,
  331.   but if you care, the exact algorithm is as follows:
  333.   - There is a pool of private-key pass phrases that starts out with the
  334.     contents of the PGPPASS environment variable (if any), and has every
  335.     pass phrase that is successfully used to unlock a private key added
  336.     to it.  When a private key needs unlocking, every pass phrase in the
  337.     pool is tried first.
  338.   - There is a list of PGP pass phrases available for use by whatever needs
  339.     one.  This is initialized with the -z command-line options and the
  340.     phrase read from the PGPPASSFD file descriptor.  When a pass phrase
  341.     is needed, it is taken from the front of that list.  When a pass
  342.     phrase is needed to unlock a secret key, every key on the list is tried,
  343.     and if it "fits" and unlocks the secret key, it is moved to the key
  344.     pass phrase pool.
  345.   - If the above fails to produce a pass phrase, the user is prompted to
  346.     supply one.
  348.   Key generation (we need all the keystrokes we can get for random-number
  349.   accumulation) and key signing (to make sure the user really means to do
  350.   what they're doing) are exceptions; the user is always prompted for a
  351.   pass phrase under those circumstances.
  353. New options:
  355. +pkcs_compat=n
  356.         This defaults to 1, which tells PGP to generate encryption key
  357.         and signature blocks in a format derived from the PKCS standards.
  358.         This format is understood (but not generated) by PGP 2.2.  If set
  359.         to 0, the old format is generated, which may be needed for
  360.         portability to PGP versions before 2.2.  PGP is still incompatible
  361.         with the PKCS standards in many ways, but in future, values of 2
  362.         or higher may be used to produce formats which are more compatible.
  364. Other notes:
  366. The MS-DOS executable was compiled with Borland C++ version 3.0, optimized
  367. for maximum speed, except that jump optimisation was turned off.  If it
  368. is turned on, the Transform() function in md5.c is compiled incorrectly.
  369. The pgp.prj file that was used is included in the source distribution.
  371. Thanks to everyone who worked on PGP and sent in bug reports.  Two who
  372. didn't make it into the manual are to Lindsay DuBois for a bit of last-
  373. minute translation, and Reptilian Research for support in developing PGP.
  375. And thanks to the Cypherpunks who managed to get PGP so much attention
  376. in Wired magazine recently.
  378. I hope you enjoy PGP!
  380.         -Colin <colin@nyx.cs.du.edu>
  382. News for PGP 2.2
  384. The main change since PGP 2.1 is a speedup in key management, and
  385. the ability to encrypt for more than one recipient.  Apart from
  386. this there are some bugfixes and some new options to make it easier
  387. to use PGP from shell scripts or mailers.
  389. You can encrypt for more than one recipient by specifying additional
  390. userids on the command line eg:
  392.         pgp -e plaintext Alice Bob Carol
  395. Some notes about the changes:
  397. - PGP doesn't do a keycheck on a keyfile before it is added anymore,
  398. this is to speed up merging a big keyfile with your public keyring which
  399. may already have most of the keys in the keyfile you are adding.  After
  400. PGP has checked a signature it sets a flag in your public keyring to
  401. mark this signature as checked.  Because PGP 2.1 didn't have these
  402. flags, PGP will check *all* signatures on your keyring the first time
  403. you add a key with PGP 2.2.  After that PGP will only check new
  404. signatures.  Also by using an older version than 2.2 on your keyring you
  405. will clear these flags again.
  408. New options:
  410. +interactive
  411.         If you add a keyfile, PGP will ask for each new key if it should
  412.         be added to your keyring.
  414. Options for use in shell scripts:
  416. +verbose=n
  417.         The default is 1.  With +verbose=0, PGP will only print an error
  418.         message if something goes wrong.  With +verbose=2, PGP will tell
  419.         you what it's doing in detail suitable for debugging.
  421. +force
  422.         Overwrite output file without asking, or with -kr: remove key
  423.         without asking (only if it has just one userid).
  425. +batchmode
  426.         With this option PGP won't ask any questions or prompt for
  427.         alternate file names.  Some of the key commands still need
  428.         user interaction and can't be done from a shell script.
  429.         You can also use this option to check if a file has a good
  430.         signature.  If the input file did not have a signature the exit
  431.         code will be 1, if the file had a signature and if it checked OK
  432.         the exit code will be 0.  Note that if the input file has more
  433.         than one armored messages, a good signature on one of these
  434.         messages will make the exit code 0 (if there are no errors).
  436. These "long" options can be abbreviated as long as the abbreviation is
  437. unambiguous.  "interactive" and "verbose" can also be set in config.txt;
  438. you can then turn these flags off on the command line with +option=.
  441. Some of the bug fixes:
  443. - Key lookup on keyID (eg 0x12AB) fixed for -ks/-krs.
  445. - Dearmoring of Macintosh type text files (CR only) now also works.

Raw Paste

Login or Register to edit or fork this paste. It's free.