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