A query was made about the Macintosh version of PGP and the bug fixes in 2.3. There was a bug in random number generation routines apparently introduced in a recent version that caused some decrease in security of the process but nothing seriously weakening. The Macintosh version is developed mostly independently of the `official' PGP version and the bug is not present in the 2.3 release. The 2.3a PGP release fixes the bug. PRZ writes, `The security problem was mostly theoretical, not a practical one for most scenarios.' (more information below). Queries were made about the effort to streamline the Macintosh user interface. In general, this has been underway for a long time in slow but consistent progress (the improvement from say 2.1 to 2.2 was significant). In MacPGP 2.3 a new online help system has been added based on Norstadt's excellent Disinfectant code (a system which exceeds the sophistication of many commercial software packages). There is an announcement currently on sci.crypt for the FTP site. All GUI versions of the PGP code are somewhat limited in sophistication by internal organization of PGP code toward the `teletype output' mindset. A major effort is underway to remodularize the code to internally encapsulate algorithms from the input & output (user interface) to make future GUI versions more accessable to programmers, and ultimately with new versions for users. A Windows version is in the works. PGP-RSAREF negotiations are plodding along with J. Berman of EFF as an intermediary. The developers are unsure of the reasons for the slow pace. J. Bidzos is supposed to make a major public announcement on this avenue very soon. Finally, some concern has been raised about bugs in the PGP code. The various developers are aware of the slightly disconcerting quality control on recent versions. One of the most direct ways that PGP users can help improve the quality of the software is to volunteer to beta-test versions on their platform in a timely manner at the release of new versions. Surprisingly few volunteers are available. If you would like to contribute in this area, please send mail to prz@acm.org. Following is information from Z. Fiedorwicz, the MacPGP developer. (Feel free to redistribute my message in its entirety.) ===cut=here=== Date: Wed, 21 Jul 1993 10:08:33 -0500 From: Zbigniew Fiedorowicz <fiedorow@math.ohio-state.edu> Subject: MacPGP 2.3 randseed bug fix There is a small bug in MacPGP 2.2 and MacPGP 2.3 in the handling of the randseed.bin file used in the generation of the random session IDEA keys used to encrypt outgoing messages. (This bug is also present in the Unix and MS-DOS versions.) Due to this bug only the first four bytes of the 24 byte randseed.bin file are ever read into memory. Since MacPGP also uses keyboard and mouse timings to generate random bytes, this does not give rise to any predictability which could easily be exploited for cracking MacPGP messages. While a special bug fix version 2.3a was released for the Unix and MS-DOS versions of PGP, this was necessitated by the presence of several other bugs NOT present in MacPGP 2.3 (eg. verification of clear-signed messages didn't work). Hence NO version 2.3a release of MacPGP is planned. If you are concerned by this bug, you can fix it by hand with ResEdit following the instructions below. The usual precautions when using ResEdit apply: FIRST MAKE A BACKUP COPY OF MACPGP 2.3 The patch: open the CODE 4 using the Hex Editor (under the Resource menu). Then using the Find menu, find the following offsets in CODE 4 and apply the patches indicated: Offset 0005E8 4878 0004 4878 0001 ^^^^ 0018 <--- replace 0004 by 0018 0005F8 5980 4FEF 0010 640A ^^^^ 5180 <--- replace 5980 by 5180 Then choose "Save" under the File menu. Exactly the same instructions apply to MacPGP 2.2 as well. Technical Explanation: The bug is caused by a single line in the open_strong_pseudorandom(byte key[16], byte buf[24]) function in the crypto.c module: if (fread(buf,1,sizeof(buf),f) < sizeof(buf)) /* empty file? */ ^^^^^^^^^^^ ^^^^^^^^^^^ Since buf is an argument to the function, it gets reinterpreted by the C compiler as simply char *buf and hence sizeof(buf) is taken to be 4 instead of 24 as intended. This line of C gets compiled into the following machine/assembly code: 0005E6: 2F0C MOVE.L A4,-(A7) 0005E8: 4878 0004 PEA $0004 0005EC: 4878 0001 PEA $0001 0005F0: 2F2E 000C MOVE.L $000C(A6),-(A7) 0005F4: 4EAD 067A JSR $067A(A5) 0005F8: 5980 SUBQ.L #$4,D0 0005FA: 4FEF 0010 LEA $0010(A7),A7 0005FE: 640A BCC.S *+$000C ; The patch converts this to 0005E6: 2F0C MOVE.L A4,-(A7) 0005E8: 4878 0018 PEA $0018 0005EC: 4878 0001 PEA $0001 0005F0: 2F2E 000C MOVE.L $000C(A6),-(A7) 0005F4: 4EAD 067A JSR $067A(A5) 0005F8: 5180 SUBQ.L #$8,D0 0005FA: 4FEF 0010 LEA $0010(A7),A7 0005FE: 640A BCC.S *+$000C ; which corresponds to if (fread(buf,1,24,f) < 8) This is of course still not quite right, but unfortunately there is no SUBQ.L #24,D0 instruction. (SUB.L #24,D0 is a 4 byte instruction which would mess up relative offset references all over CODE 4.) However the chances of this causing any problem are extremely small.