True RNG and GnuPG / libgcrypt

Leo Gaspard ekleog at
Thu Oct 3 22:11:59 CEST 2013


On Thu, Oct 03, 2013 at 11:10:10AM -0700, Charles Swiger wrote:
> On Oct 3, 2013, at 4:47 AM, Leo Gaspard <ekleog at> wrote:
> > Knowing that /dev/random is directly OS-managed, distrusting it is directly like
> > distrusting the OS. (Assuming the OS claims it has a secure randomness
> > compressor.)
> > 
> > And, once you do not trust your own OS, you can trust absolutely no program
> > running on it. Thus you are not able to trust GnuPG, if you run it on your
> > not-trusted OS.
> Yes, that's true as far as it goes: if the OS has been maliciously compromised,
> then no program running on it can be considered secure or trustworthy.
> However, please also note that bugs or flaws in what was believed to be a good
> implementation of /dev/random, OpenSSL's rand, etc can lead to weak crypto.
> A recent case-in-point was the Android SecureRandom issue affecting Bitcoin and
> possibly other apps, which was due to OpenSSL not being properly initialized:

In this case, wouldn't re-reading and triple-checking that these
randomness-generating algorithms are indeed "random" be a better effort for the
whole crypto community ? This way, each and every application can benefit from
the work made on /dev/random.

What's more, adding yet another random number generator means yet another
randomness library to be checked for bugs.

> > So I believe implementing a fortuna "generator" in GnuPG is not the most urgent
> > improvement to be made -- though I know nothing of GnuPG's current most-wanted
> > improvements.
> I seem to recall interest in supporting GnuPG on Android, so it would seem worthwhile
> to make sure that GnuPG is properly seeding OpenSSL and/or libgcrypt.  My own quick
> check of libgcrypt sources suggests that it will treat Android as a Linux flavor
> and try to seed its CSPRNG from /dev/random.

In this case, wouldn't developing a general algorithm for randomness
accumulation and then proposing it to android for inclusion be a better idea
than just sticking it in gnupg ?

This way, all applications can take advantage of the new randomness accumulation
algorithm. And maybe would it even be possible to re-use GNU/Linux's /dev/random

However, not knowing much about development on android, I am not to be trusted
with ideas.

BTW, reading the first few paragraphs of the article you linked, seeding the
PRNG from  /dev/random *is* actually the thing to do, as the issue with android
would be (if I understood) that it does not properly seed its PRNG.



More information about the Gnupg-devel mailing list