Mailing List Archive

> 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

> from rjh@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

> 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

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

> from rjh@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

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

> 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

> 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

> 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

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

> 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!

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

> 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