pgp263iamulti06

[Ángel]

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.