Re: pgp263iamulti06
Are there known, documented security deficiencies in it? The CSPRNG is almost certainly broken. PGP 2.6.3 was a DOS program, which meant it could easily get direct access to hardware. That meant it could use the uncertainty of the physical world as a key factor in the CSPRNG. But ever since August 2001 and the release of Windows XP, DOS programs no longer get direct access to hardware. Everything is abstracted away through the Windows Hardware Abstraction Layer (HAL) or other similar layers. The core assumption of the PGP 2.6.3 CSPRNG ("we can use direct access to hardware to sample entropy from the physical world") no longer holds and hasn't been valid for more than twenty years. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: pgp263iamulti06
from r...@sixdemonbag.org...: The CSPRNG is almost certainly broken. Thank you! When generating the key-pair with Re: pgp263iamulti06, the "randomness" is obtained by user's keyboard input. Is it then that the above applies only when the session key is generated? PGP 2.6.3 was a DOS program,... And Linux. (Apple too - remember compiling it on Mac when the command-line build tools were still available). So is the same (i.e., a problematic source of randomness when generating the session key) likely to be the case compiling/running 2.6.3iamulti06 under Linux today? PetRoh ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: pgp263iamulti06
When generating the key-pair with Re: pgp263iamulti06, the "randomness" is obtained by user's keyboard input. Is it then that the above applies only when the session key is generated? No, the whole CSPRNG is (probably) compromised. PGP 2.6.3 used keyboard interrupts harvested directly from the hardware to get a collection of random bits which it then fed into the CSPRNG to be expanded out into a large quantity of randomish bits. It's just that when generating a new certificate it always replenished the CSPRNG's entropy -- when generating traffic it didn't, but the CSPRNG was still dependent on the randomness collected earlier. On Windows, you no longer have this direct access to hardware and there's almost certainly some determinism introduced by the HAL. the command-line build tools were still available). So is the same (i.e., a problematic source of randomness when generating the session key) likely to be the case compiling/running 2.6.3iamulti06 under Linux today? I wouldn't say "almost definitely" the way I do for DOS, but I'd still say I'd find it a disturbing possibility I'd want to investigate and rule out before I used PGP 2.6.3 in a UNIX environment. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: pgp263iamulti06
On 23-01-2022 21:23, Robert J. Hansen via Gnupg-users wrote: > No, the whole CSPRNG is (probably) compromised. PGP 2.6.3 used keyboard > interrupts harvested directly from the hardware to get a collection of > random bits which it then fed into the CSPRNG to be expanded out into a > large quantity of randomish bits. Is this also used when generating symmetric keys? Or only used by secret key generation? If the last is the case, then existing keys generated on DOS (or Linux?) might be safe (apart from a possibly short key length). BTW, I remember I compiled 2.6.3ia with Visual Studio 5 on windows 95 and that was easy (just put all C files in a new project and build it). The added advantage was that I got long filename support without any code changes. I assume that it would work the same for the multi versions although I never tried, none of my contacts used those. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: pgp263iamulti06
Is this also used when generating symmetric keys? Or only used by secret key generation? If the last is the case, then existing keys generated on DOS (or Linux?) might be safe (apart from a possibly short key length). Existing certificates would be unaffected, but since the CSPRNG is used for all sorts of things in signatures and encryption, it absolutely should not be used for anything more than reading old traffic. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: pgp263iamulti06
Robert J. Hansen via Gnupg-users wrote: When generating the key-pair with Re: pgp263iamulti06, the "randomness" is obtained by user's keyboard input. Is it then that the above applies only when the session key is generated? No, the whole CSPRNG is (probably) compromised. PGP 2.6.3 used keyboard interrupts harvested directly from the hardware to get a collection of random bits which it then fed into the CSPRNG to be expanded out into a large quantity of randomish bits. It's just that when generating a new certificate it always replenished the CSPRNG's entropy -- when generating traffic it didn't, but the CSPRNG was still dependent on the randomness collected earlier. On Windows, you no longer have this direct access to hardware and there's almost certainly some determinism introduced by the HAL. I remember using a Windows-95-native PGP years ago that also used keyboard and mouse events to acquire entropy; presumably, there was not that much determinism, or every PGP key generated on Windows is likely to be weak. the command-line build tools were still available). So is the same (i.e., a problematic source of randomness when generating the session key) likely to be the case compiling/running 2.6.3iamulti06 under Linux today? I wouldn't say "almost definitely" the way I do for DOS, but I'd still say I'd find it a disturbing possibility I'd want to investigate and rule out before I used PGP 2.6.3 in a UNIX environment. If it reads /dev/random, you are fine; the Linux kernel collects very good entropy and GPG uses (and has always used) that source. If it does something else, you probably have a problem, possibly a "Debian OpenSSL" problem... -- Jacob ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: pgp263iamulti06
I remember using a Windows-95-native PGP years ago that also used keyboard and mouse events to acquire entropy; presumably, there was not that much determinism, or every PGP key generated on Windows is likely to be weak. Win95 still allowed direct access to underlying hardware. In the XP-and-beyond world, direct hardware access virtually requires a driver. If it reads /dev/random, you are fine; the Linux kernel collects very good entropy and GPG uses (and has always used) that source. If it does something else, you probably have a problem, possibly a "Debian OpenSSL" problem... /dev/random didn't exist in 1991-2 when PGP 2.6.3i was written. At least on SGI IRIX, the standard way of getting random bytes was to open an audio device and sample the least significant bits of the input stream... ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: pgp263iamulti06
from r...@sixdemonbag.org...: ... I wouldn't say "almost definitely" the way I do for DOS, but I'd still say I'd find it a disturbing possibility I'd want to investigate and rule out before I used PGP 2.6.3 in a UNIX environment. Thank you very much for your comments. Would you be able to suggest the version to use in "portable" mode? (a) under Linux? (b) under Windows? tia, PetRoh ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: pgp263iamulti06
Would you be able to suggest the version to use in "portable" mode? GnuPG 1.4, but I'd honestly prefer to run a bootable Linux distro. Portable apps are a monstrous security hazard if they're used on computers beyond your control. USB malware is a very real thing. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: pgp263iamulti06
On 2022-01-23 at 15:23 -0500, Robert J. Hansen wrote: > > When generating the key-pair with Re: pgp263iamulti06, the > > "randomness" is obtained by user's keyboard input. Is it > > then that the above applies only when the session key is > > generated? > > No, the whole CSPRNG is (probably) compromised. PGP 2.6.3 used keyboard > interrupts harvested directly from the hardware to get a collection of > random bits which it then fed into the CSPRNG to be expanded out into a > large quantity of randomish bits. It's just that when generating a new > certificate it always replenished the CSPRNG's entropy -- when > generating traffic it didn't, but the CSPRNG was still dependent on the > randomness collected earlier. > > On Windows, you no longer have this direct access to hardware and > there's almost certainly some determinism introduced by the HAL. Ok, you made me actually look at pgp263iamulti06. :-) It seems to be using ANSI X9.17 but built on CAST5. ANSI X9.17 has been removed by NIST, and CAST5 has a block size of only 64 bits. Nevertheless, it probably is a decent enough CSPRNG nowadays. Way out of my reach, anyway. However, the entropy gathering seems overly optimistic: It doesn't seem to take timing into account,* just the keystrokes themselves.** It discards more than two consecutive presses of the same key, but other than that, it will be assuming about 7 bits of entropy per key-press. Whereas the user will be typing with a keyboard which doesn't even have 2^7 keys. Perhaps up to 5 bits of randomness, more likely on the order of 2^4 different keys, and the keys pounded by the user won't be independent events, so not even 4 bits of entropy. There are lots of further mixing (including additional randomness saved on randseed.bin file), but if you actually had less random bits than you thought... Regards * Time is used to ensure not fetch more than one keypress per second. ** Note: on Macintosh the implementation seem to work slightly different than the others. ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: pgp263iamulti06
Ok, you made me actually look at pgp263iamulti06. :-) I almost feel like I should apologize. However, the entropy gathering seems overly optimistic: *wince* That's quite a bit worse than I remember. (I haven't looked at 2.6.3 source code in probably 25 years.) So, yeah. I'm comfortable calling the 2.6.3 CSPRNG system fatally compromised due to inadequate entropy gathering. Thank you for looking into this! OpenPGP_signature Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: pgp263iamulti06
On 1/29/2022 at 11:02 PM, "Robert J. Hansen" wrote:> Please comment if this is adequate, or there is still a problem with > Disastry's Linux Version. Why? I've been trying to get people to move to OpenPGP for literally a quarter-century, Vedaal. I'm not going to suddenly switch gears and work on giving people reasons *not* to migrate. = I have publicly posted here that GnupG should not have to make a considerations with backward compatibility with Disastry's version, those who use Disastry's version among each other will continue to do so, and among those who communicate with GnuPG user's, will use GnuPG. If person1 has a signed and encrypted email to person 2, but which used IDEA and MD 5, and now wants to decrypt, and re-encrypt and sign, and send to person 2, who will then destroy the original email, why shouldn't they be allowed to know if this is safe. They still use GnuPG for current email and will not be discouraged by knowing that there is a safe way to do this in Linux based Diastry's version, which cannot be sent to person 2's v3 key in GnuPG 2.x vedaal ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: pgp263iamulti06
If person1 has a signed and encrypted email to person 2, but which used IDEA and MD 5, and now wants to decrypt, and re-encrypt and sign, and send to person 2, who will then destroy the original email, why shouldn't they be allowed to know if this is safe. They *are* allowed. The source code is there for them to study. What I said is that I'm not going to do that work for them, because I think PGP 2.6.3 is best abandoned. Full stop. No exceptions. Migrate your data already, you've had over a quarter century. People are of course free to disagree with me: some do. But that is my position, and I think it's kind of incredible that someone would ask me to come up with reasons that would allow PGP 2.6.3 users to justify their continued use. :) ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users