
Entropy Loss and Output Predictability in the Libgcrypt PRNG [pdf] - tshtf
http://formal.iti.kit.edu/~klebanov/pubs/libgcrypt-cve-2016-6313.pdf
======
tptacek
Don't. Use. Userspace. Random. Number. Generators.

It is 2016. There is no business for any major tool to be shipping a
dependency on a userspace random number generator like this.

[http://sockpuppet.org/blog/2014/02/25/safely-generate-
random...](http://sockpuppet.org/blog/2014/02/25/safely-generate-random-
numbers/)

It's not enough for us to stop fielding new software with broken userspace
random (all userspace random is broken random). We need to go back through all
the software, find all the userspace RNGs, and replace them with urandom reads

~~~
ryuuchin
How to safely generate random numbers on Windows[1][2]:

    
    
      #include <windows.h>
      #define SystemFunction036 NTAPI SystemFunction036
      #include <ntsecapi.h>
      #undef SystemFunction036
    
      RtlGenRandom(buf, size);
    

This is more convenient than both rand_s[3] and CryptGenRandom[4]. The former
can only generate one byte per call and the latter requires you to create a
CSP (cryptographic service provider) before you can call it (which means you
have to destroy the CSP when you're done using it). In the end these all call
RtlGenRandom.

RtlGenRandom uses a CSPRNG specified in NIST 800-90[4]. It uses AES256 in CTR
mode AFAIK.

[1] [https://msdn.microsoft.com/en-
us/library/windows/desktop/aa3...](https://msdn.microsoft.com/en-
us/library/windows/desktop/aa387694\(v=vs.85\).aspx)

[2]
[https://boringssl.googlesource.com/boringssl/+/master/crypto...](https://boringssl.googlesource.com/boringssl/+/master/crypto/rand/windows.c#26)

[3] [https://msdn.microsoft.com/en-
us/library/sxtz2fa8.aspx](https://msdn.microsoft.com/en-
us/library/sxtz2fa8.aspx)

[4] [https://msdn.microsoft.com/en-
us/library/windows/desktop/aa3...](https://msdn.microsoft.com/en-
us/library/windows/desktop/aa379942\(v=vs.85\).aspx)

~~~
CiPHPerCoder
For anyone not writing C/C++ but still needs a CSPRNG:
[https://paragonie.com/blog/2016/05/how-generate-secure-
rando...](https://paragonie.com/blog/2016/05/how-generate-secure-random-
numbers-in-various-programming-languages)

------
advisedwang
The GPG folks don't currently recommend revoking keys based on this:
[https://lists.gnupg.org/pipermail/gnupg-
announce/2016q3/0003...](https://lists.gnupg.org/pipermail/gnupg-
announce/2016q3/000395.html)

------
weinzierl
> [...] the flaw makes a part of the PRNG output completely predictable. This
> bug exists since 1998 in all GnuPG and Libgcrypt versions [...]

> Please note that this document makes no claims about the effect of the flaw
> on the security of generated keys or other artifacts.

------
zeveb
Granted, Fortuna didn't exist in 1998 (it dates to 2003) — but why oh why
don't gcrypt & the kernel use it now?

~~~
tptacek
There's nothing especially magical about Fortuna. There are basically three
problems to solve with a CSPRNG:

1\. Ensuring that it's adequately seeded before anyone can use it.

2\. Providing forward secrecy by periodically rekeying ("refreshing the
entropy pool", but we should do away with that terminology).

3\. Carrying over state across reboots.

(There are four problems if you consider "being performant" a problem on the
scale of fundamental design, but it's mostly not).

You wouldn't think CSPRNGs are this simple by reading either the literature on
things like Fortuna and Yarrow or by reading the LKML and patch proposals for
the LRNG. You'd think it was super tricky to collect "enough entropy" from
enough "decorrelated sources", you'd think you'd have to deal with
"depletion", you'd think about "high quality" versus "low quality" entropy,
and the like. But these issues aren't just not important: they are mostly
folkloric.

Generating a practically limitless stream of random bits isn't a hard
cryptographic problem. It is an elementary problem. It's the problem that
every stream encryption scheme solves. You can simply use stream encryption
schemes, like stream ciphers or block ciphers and hashes in CTR mode, as
CSPRNGs.

The problem we need to solve isn't upgrading the LRNG or getting everyone to
use Schneier's favorite CSPRNG design (the section on this in Cryptography
Engineering is one of the book's few warts). It's _getting everyone to use the
kernel RNG to the exclusion of all else_. That's because those 3 problems I
listed up there are easy to solve if you're using /dev/urandom (or the
getrandom system call), but extremely tricky otherwise.

~~~
ahh
The biggest problem with "always use /dev/urandom" is that the kernel
developers themselves--wrongly--think that this problem is more difficult than
it is, and think that you shouldn't do just that.

This manifests in issues like scalability: some patches were merged to
(slightly) improve scalable performance of /dev/urandom...and these were
phrased as "Sure, we can do this, because idiots might want that and it costs
us little--but we should emphasize this sort of thing isn't an actual
supported feature!"

The people who maintain /dev/urandom aren't stupid, but for some reason they
really don't seem to get (or agree with at least) your argument. I'd really
like to understand why; I don't.

(I am technically a linux developer--I work on the kernel we use internally,
and have actual patches to my name upstream--but am not a deep part of the
external community.)

~~~
tptacek
T'so is simply wrong. I don't know that it's worth going into any more detail
than that. You can look to threads on HN where he's commented about the
utility of weak and strong random to see that concerns simply aren't rooted in
cryptographic reality. He is simply not a cryptographer.

Meanwhile, teams of people who are cryptographers of world renown, such as the
Bernstein, Lange, and Schwabe team that designed and implemented Nacl, _just
use urandom_.

This case is closed. Use the system call interface by all means if it's
available to you! But don't use userspace RNGs, like OpenSSL and GPG do, and
don't use /dev/random.

~~~
ahh
Right! I agree with you! I'm saying that because T'so is wrong, that the
kernel RNG, while still better than other options, will not be as good as it
should or could be.

