2016-19. If you're running Gnu Privacy Guard (GnuPG/GPG) for OS/2, your key is almost certainly catastrophically weak and adversaries with a need can almost certainly decrypt everything sent to you. The problem goes back to GnuPG for OS/2 1.2.0. If after reading this you believe it's not accurate, please send a comment (link below).
All keys made on GPG for OS/2 versions 1.4.0 through 1.4.9 are suspect and should be revoked. By default, these versions do not use cryptographically strong random numbers. Instead, they transiently load the random number OS/2 entropy collector RndOS2.DLL, get a single poll of system statistics, and complete the key generation long before 10 seconds when the first new poll would occur. In the worst case, this can mean entropy of zero. There can be no assurance that data drawn directly from the DLL is cryptographically secure.
Removing the RndOS2.DLL does not result in the documented fallback to the Rexx entropy gathering daemon (RexxEGD) even if you installed it and have it running. Some versions report this and abort. Others report it but make an insecure key anyway.
To get reasonable assurance of cryptographically strong random numbers based on RndOS2.DLL, you must obtain the companion random number OS/2 daemon RndOS2Dmn.EXE, load it at boot so that RndOS2.DLL is always loaded and polling for entropy every 10 seconds, and you must draw the data from the daemon and not the DLL. Otherwise, there can be no assurance that the DLL has been loaded long enough to collect entropy, and thus no assurance that the random data is cryptographically strong.
Keys made on GPG for OS/2 versions 1.2.0 through 1.2.5 are suspect and should be revoked unless it's known that the RexxEGD was used in place of RndOS2.DLL. These versions will only use the RexxEGD if they cannot find RndOS2.DLL. (I was unable to locate a copy of v1.2.5 for testing but presumably, it has the same behavior.)
RndOS2 is 'a port of the various /dev/random devices of OpenBSD, done as a dynamic link library (DLL) [Emphasis added] (). Huerlimann, Tobias. 2004. RNDOS2 Readme. (Archive.org copies: TobiasHuerlimann.DE /software /rndos2/.) The RndOS2 archive includes the aforementioned RndOS2Dmn.EXE, 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 the GPG ports don't do this. They don't even include the daemon. If the daemon was never loaded, or it was terminated, they will happily load RndOS2.DLL transiently and finish generating a key before even a single 10-second repoll of system statistics occurs.
Periodically polling entropy is part of the fundamental design of the Linux Random Number Generator (LRNG) that RndOS2 was intended to implement. Since these GPG ports don't even include the daemon to keep RndOS2.DLL loaded, it obviously can't periodically poll for entropy. The source file rnd.c confirms that RndOS2 is in part a port of BSD's random.c and that this is based on the LRNG (). Shalayeff, Michael and Ts'o, Theodore. 1994-2001. random.c. Available as rnd.c in archive rndos2-0.91.zip from archive.org copy from os2site.com.
The entropy from a snapshot of system statistics can in the worst case be zero. This is why the LRNG is supposed to be run from power on with a carryover seed and do periodic polling (). Gutterman, Zvi, Pinkas, Benny, and Reinman, Tzachy. 2006. Analysis of the Linux Random Number Generator (abstract with link to 18 page PDF). The RNDOS2 config.h file shows at lines 39-42 that the RNDOS2_POLLINTERVAL referenced in rnd.c is 10000 milliseconds. That shows that it was indeed intended to poll every 10 seconds. But with nothing to keep RndOS2.DLL loaded, it is not doing that.
Repeated polling for randomness is a fundamental requirement, but what is good practice? RNDOS2 derives in part from code by Peter Gutmann (). Gutmann, Peter. 1999. [Re:] Randomness Testing (quoted in a reply from Brian Havard). (lists.gnupg.org /pipermail /gnupg-devel /1999-December /016199.html) He suggests that entropy collectors poll at least once a minute for five minutes before first use and no less than once every ten minutes thereafter (). Gutmann, Peter. 1998. Software Generation of Practially Strong Random Numbers (abstract with link to publisher site 17 page PDF).
There can be no assurance that the entropy in a single snapshot of system statistics is anywhere near enough to support strong keys. 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.
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. (). Schneier, Bruce. 2015. Lousy Random Numbers Cause Insecure Public Keys. (schneier.com /blog /archives /2012 /02 /loud_random_nu.html.)
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 (). BBC. 2013. NSA 'altered random-number generator'. Sep. 11. (Archive.org copy of bbc.com /news /technology-24048343.)
It's possible to work around this issue. But it requires going back to Tobias Huerlimann's GPG v1.2.4 port, removing all vestiges of RndOS2, and making sure RexxEGD is loaded at power on. This is because the fallback to the RexxEGD from v1.4.1 through 1.4.9 stopped working. There isn't any way I can see to make these ports usable without recompiling to draw entropy either from the RexxEGD or at least from the RndOS2Dmn.EXE instead of from RndOS2.DLL directly. It would have been nice if all the ports permitted the user to configure which source of entropy to use.
The Rexx Entropy Gathering Daemon can be started at power on and provide reasonable assurance of always delivering practically strong random numbers (). O'Connor, Russell. 2001. Rexx Entropy Gathering Daemon for OS/2. (Also RexxEGD at archive.org. You can also watch its console to verify that it's collecting entropy periodically and that programs like GPG are drawing random numbers from this source.
Using GPG v1.2.4 to force the use of the RexxEGD means working with age issues. It's necessary to modify a modern gpg.conf to be compatible with this very old version. That means substituting obscure codes instead of algorithm names and removing algorithms the old port doesn't have. For example, if you want to use a cert-digest-algo stronger than SHA1, you have to pick RIPEMD160, because in this old GPG port, the SHA2 algorithms are read-only. Similarly, GZIP2 compression is not available. You also might be better off not to advertise the operating system or GPG version to hackers, and perhaps to have a photo. Considering all of that might result in this rather cryptic code in your gpg.conf where each bulleted item is a single line:
no-emit-versionshow-photosphoto-viewer ib.exe %ipersonal-cipher-preferences S9 S8 S7 S10 S4 S3personal-digest-preferences H10 H9 H8 H3 H2 H1cert-digest-algo RIPEMD160default-preference-list H10 H9 H8 H3 H2 H1 S9 S8 S7 S10 S4 S3
S2 Z2 Z1 Z0We 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, Elaine and Robinskey, Allen. 2015. Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths (30 page 331 kilobyte PDF) (NIST Special Publication 800-131A Rev 1). Caution: This document has been superseded. (Also at archive.org nvlpubs.nist.gov /nistpubs /SpecialPublications /NIST.SP.800-131Ar1.pdf (Index of captures). 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.' (). The GnuPG Project. 2015. GnuPG Frequently Asked Questions (question 11.4).
As it happens, this old port of GPG can't create keys longer than 2048 bits using the RexxEGD anyway. If you try, it pulls 300 random bytes from the daemon but then partway 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. Nowhere are you prompted that you can also create an encryption key. But you can. The process goes like this:
Talk about a steep learning curve. No wonder Johnny Can't Encrypt (). Whitten, Alma and Tgyar, J.D. 1999. Why Johnny Can't Encrypt (abstract with link to HTML and Postscript versions). (Source: usenix.org /legacy /publications /library /proceedings /sec99 /whitten.html)
Alas, I know just enough to be dangerous but not enough to make a newer GnuPG/2 that works correctly. Somebody else should fix it. They might consider making it default to a 2048 bit RSA key set and requiring the RexxEGD. It would also be nice if it could complete the generation of a 4096 bit RSA key set when using the RexxEGD.
If GPG for OS/2 must come with the questionable RndOS2, it should be modified to only draw random numbers from the daemon. And the RndOS2 could do with a whole lot more sources of randomness. In any event, GPG should at least allow the user to choose the RexxEGD and affirmatively reject the RndOS2. Then users who care about such things could have greater confidence that it might be producing secure keys.
It was disappointing when GnuPG/2 stopped using the RexxEGD unless you purged the black box that is RndOS2. It was aggravating when it stopped falling back to the RexxEGD if RndOS2.DLL was purged. And it was disappointing to realize that RndOS2.DLL is being loaded transiently, without accumulated entropy, such that any generated keys are without doubt breakable. With doubtful random numbers, all the effort put into these GPG ports is for naught and could even be harmful. After all, anything anyone encrypts with your weak key and sends to you can be decrypted by adversaries.