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