
Security Fixes for Libgcrypt and GnuPG 1.4 - doener
https://lists.gnupg.org/pipermail/gnupg-announce/2016q3/000395.html
======
ctz
Here's the relevant commit: [https://git.gnupg.org/cgi-
bin/gitweb.cgi?p=gnupg.git;a=commi...](https://git.gnupg.org/cgi-
bin/gitweb.cgi?p=gnupg.git;a=commit;h=c6dbfe89903d0c8191cf50ecf1abb3c8458b427a)

You'll notice that there are no tests with this commit, and no tests on other
commits for the same feature. You can conclude from this that there are no
tests at all for correct CSPRNG operation.

~~~
voltagex_
How would you normally write a unit test for a RNG?

~~~
ctz
It's a PRNG, so you fix the inputs and make sure the output is correct for all
possible parameter sets.

Matthew Green has more on this here:
[http://blog.cryptographyengineering.com/2014/03/how-do-
you-k...](http://blog.cryptographyengineering.com/2014/03/how-do-you-know-if-
rng-is-working.html) ('Known Answer Tests (KATs)' section).

------
sneak
Why does Libgcrypt use a nonstandard CSPRNG to begin with? This is a solved
problem; why reinvent the wheel?

~~~
the_why_of_y
Apparently the vulnerable mix_pool function was added in 1998 in this commit,
citing a Peter Gutmann's Paper: "Software Generation of Practically Strong
Random Numbers":

[https://git.gnupg.org/cgi-
bin/gitweb.cgi?p=gnupg.git;a=commi...](https://git.gnupg.org/cgi-
bin/gitweb.cgi?p=gnupg.git;a=commitdiff;h=a6a8f1e706bd7e528262151bc04ebb9409c2eeed)

If you look at random.c before this commit, what it did previously is either
return bytes read from /dev/urandom or /dev/random (which is fine) or some
fall-back code that used the awful standard C rand(3).

I'd guess that at the time there were some crappy UNIXes that didn't have a
working /dev/random, so they wanted to make the fall-back less awful, and
accidentally broke the "working" case at the same time? Hazards of writing
portable code...

------
joeyrideout
When searching for more information on this CVE, I noticed a duplicate:
_Possible XSS Vulnerability in Action View_ [1]. Do duplicate CVEs pop up like
this often?

[1] [http://seclists.org/oss-sec/2016/q3/260](http://seclists.org/oss-
sec/2016/q3/260) (fetched 07:16:12 21 August 2016 UTC)

~~~
saurik
One of the two projects likely made a typo in their announcements; it will be
interesting to see who ends up having been wrong when the CVE details are
disclosed for that identifier ;P.

[http://cve.mitre.org/cgi-
bin/cvename.cgi?name=CVE-2016-6316](http://cve.mitre.org/cgi-
bin/cvename.cgi?name=CVE-2016-6316)

