Website:Walter Gregg

On this page: Main Content. Unsafe Random Numbers from RNDOS2. Weak Random Numbers Mean Breakable Keys. Strong Random Numbers from RexxEGD. Improving GPG for OS/2. References.

Can Recent GPG's for OS/2 Make Secure Keys?

December 13, 2016. GPG keys generated with recent ports for OS/2 may be catastrophically weak. The random number generator isn't accumulating entropy.

The problem is that GPG doesn't load the entropy gathering random number generator RNDOS2 until the very moment of key generation. It immediately draws out random numbers and completes key generation before even a single 10 second repoll of system entropy occurs.

The Rexx Entropy Gathering Daemon, by contrast, can be loaded at boot and thus provide reasonable assurance of delivering practically strong random numbers. However, RexxEGD support was dropped in GPG v1.4.2. Reasonable assurance of generating strong keys requires the older v1.2.4 and expungement of RNDOS2 so that the RexxEGD is used.

Contents ↑

Unsafe Random Numbers from RNDOS2

RNDOS2 is 'a port of the various /dev/random devices of OpenBSD, done as a dynamic link library (DLL) [Emphasis added].' (Huerlimann 2004) The archive includes a boot daemon that can in principle keep RNDOS2.DLL loaded and polling system statistics every 10 seconds to guarantee that there is sufficient entropy to draw practically strong random numbers from the daemon. But GPG doesn't do this.

The actual GPG implementation doesn't draw random numbers from the daemon. Indeed, it doesn't even include the daemon. Instead, at the instant of key generation, it loads the supplied RNDOS2.DLL directly. There is no possibility that the entropy pool is filled, because GPG draws random numbers immediately and completes key generation before even a single 10 second repoll of system statistics occurs. But periodically polling entropy is part of the fundamental design that RNDOS2 is intended to implement.

Although RNDOS2 is ported in part from the Linux Random Number Generator (LRNG), this GPG implementation doesn't load it at boot and keep it loaded, so it can't poll for the required entropy. The source file rnd.c shows that RNDOS2 is in part a port of BSD's random.c and that this is based on the LRNG. (Shalayeff and Ts'o 1994-2001) The entropy from a snapshot of system statistics can in the worst case be zero, so the LRNG must run from boot with a carryover seed and do periodic polling. (Gutterman, Pinkas, and Reinman 2006) The RNDOS2 source files rnd.c and config.h show that it was intended to poll every 10 seconds, but with nothing to keep it loaded, it obviously can't.

Repeated polling for randomness is a fundamental requirement. What is good practice? RNDOS2 derives in part from code by Peter Gutmann. (Gutmann 1999) His presentation on software generation of practically strong random numbers suggests polling once a minute for five minutes before serving clients and then dropping back to once per 10 minutes. (Gutmann 1998)

There can be no assurance that the entropy in a single snapshot of system statistics is anywhere near enough to support strong keys. In fact, we have pretty good assurance that it isn't. For RNDOS2, per the source code add_randomness.c, the entropy sources are shockingly limited:

It isn't obvious that anything is wrong. Nevertheless, in this implementation, the output can only be expected to be mathematically random, not cryptographically unpredictable. We are effectively seeding the generator with the time of day plus a couple of packet counters thrown in for good measure.

Contents ↑

Weak Random Numbers Mean Breakable Keys

This is a critical security issue. Tens of thousands of insecure public keys have been found in the wild and the issue is attributed to bad random number generators. See the essay 'Lousy Random Numbers Cause Insecure Public Keys.' (Schneier 2012)

If random number generators are biased, the game's over. Documents leaked by Edward Snowden indicate that the NSA has spent a fortune compromising random number generators, because if those are corrupt, they can decrypt anything:

'... the NSA subverted a standards process ... [and] had written a flaw into a random-number generator that would allow the agency to predict the outcome of the algorithm....' (BBC 2013)

Contents ↑

Strong Random Numbers from RexxEGD

It's possible to work around this issue by going back to Tobias Huerlimann's GPG v1.2.4 port, removing all vestiges of RNDOS2, and making sure RexxEGD is loaded at boot. Unfortunately, Tobias dropped support for the RexxEGD in his v1.4.2 port and no later ports through at least 1.4.9 will use it.

Unlike RNDOS2, the Rexx Entropy Gathering Daemon can be started at boot and provides reasonable assurance of always delivering practically strong random numbers. (O'Connor 2001) You can also watch it's console to verify that it's really collecting entropy periodically and that GPG is actually drawing random numbers from this source.

Using GPG v1.2.4 comes with age issues. It's necessary to modify gpg.conf to be compatible with it. That means substituting obscure codes instead of algorithm names and removing algorithms the old port doesn't have. For example, if you want to write with a cert-digest-algo stronger than SHA1, you have to pick RIPEMD160, because in this old GPG, the SHA2 algorithms are read only. Similarly, GZIP2 compression is not available. I also prefer not to advertise the operating system and GPG version to hackers (oops, I've just done that), and to have photos. So I have this cryptic code in my gpg.conf now, where each bulleted item is a single line:

We also need to bump up the key size to 2048 bits. According to NIST, a key size of 2048 bits is both necessary and sufficient. (Barker and Roginsky 2015) Although some are using 4096 or 3072 bit keys, they have some disadvantages.

'...moving past RSA-2048 means you lose the ability to migrate your certificate to a smartcard, or to effectively use it on some mobile devices, or to interoperate with other OpenPGP applications that don't handle large keys gracefully.' (GnuPG 2015)

As it happens, this old port of GPG can't successfully create keys longer than 2048 bits using the RexxEGD anyway. If you try, it pulls 300 random bytes from the daemon but then part way through the key generation process it posts this complaint:

gpg: Write error to pipe: 6
gpg: fatal: can't write to the EGD: No such file or directory

The daemon is still running and you can still pull random numbers from it, so I suspect that this error message doesn't refer to the RexxEGD but rather to the Perl EGD pipe that indeed doesn't exist. So 2048 bits it is.

It turns out that we also need to abandon the DSA/ElGamal default key set. If you stick with this default, GPG silently fails in that it generates a set of keys, but only the ElGamal pair has the desired key length. The DSA key pair is still only 1024 bits, and there is no warning to that effect. And it's been reported that a securely generated DSA key pair is compromised if it's used even once on a system with a weak random number generator. Need I say more?

It's not at all obvious to the end user that there is another choice, because the RSA choice says 'sign only', and the end user trying to create an encryption key would think that is pointless. No where are you prompted that you can then create an encryption key too. But you can. The process goes like this:

Contents ↑

Improving GPG for OS/2

Talk about a steep learning curve. No wonder Johnny Can't Encrypt. (Whitten and Tgyar 1999)

An improved GPG for OS/2 should default to a 2048 bit RSA key set, require the RexxEGD, and come with it, so that users don't have to think. It should also allow generating a 4096 bit RSA key set when using the RexxEGD.

If GPG for OS/2 must come with the questionable RNDOS2, it should at least allow the user to choose the RexxEGD and affirmatively reject RNDOS2. Then users who care about such things could have greater confidence that it might be producing secure keys.

Fair disclosure: I have a modified personal copy of the RexxEGD. It was disappointing to discover that current GPGs won't use it.

Contents ↑

References

Contents ↑

2016. (Walt.Gregg.Juneau.AK.US/6/os2-make-gpg-keys; CreativeCommons.org/licenses/by-nc-sa/4.0.)

 No Privacy