Re: getrandom vs. crypto/gc-random

[Jeffrey Walton]

On Sun, May 31, 2020 at 3:02 PM Bruno Haible <bruno@clisp.org> wrote:
>
> Hi Simon,
>
> Thanks for your insights.
>
> > Historically, the problem is that for cryptographic purposes,
> > /dev/random and /dev/urandom can be a really bad choice on many
> > platforms.  This has probably been improved over the years, especially
> > on the most relevant platforms, but still
>
> Indeed. Even without having done multidimensional correlation analysis
> (as explained in Knuth vol. 2), it looks fishy that getrandom() with
> GRND_RANDOM is able to return 100000 bytes of "random" data instantly
> on
>   GNU/Hurd, Mac OS X, GNU/kFreeBSD, FreeBSD 12.0, OpenBSD 6.5,
>   Minix 3.3, AIX 7.1, Haiku, and native Windows.
> I would have expected something better on OpenBSD at least...
>
> > The gc-random module wasn't really perfect in this regard, it required
> > that people used libgcrypt or provided a known-good randomness device
> > that is different for every platform .  The gc-random logic was
> > incomplete here.
>
> Feel free to enhance it. I'm not touching this code, because I lack
> the profound crypto know-how.
>
> > There ought to be a word about in the gnulib documentation for
> > getrandom() and getentropy() so that applications don't assume these
> > gnulib modules provides crypto-strength output on all platforms.
>
> I'm adding these notes in the documentation:
>
>
> 2020-05-31  Bruno Haible  <bruno@clisp.org>
>
>         getrandom, getentropy: Mention the crypto/gc-random module.
>         Suggested by Simon Josefsson in
>         <https://lists.gnu.org/archive/html/bug-gnulib/2020-05/msg00400.html>.
>         * doc/glibc-functions/getrandom.texi: Mention the quality issues and 
> the
>         crypto/gc-random module.
>         * doc/glibc-functions/getentropy.texi: Likewise.
>
> diff --git a/doc/glibc-functions/getentropy.texi 
> b/doc/glibc-functions/getentropy.texi
> index b7717e5..998bcf4 100644
> --- a/doc/glibc-functions/getentropy.texi
> +++ b/doc/glibc-functions/getentropy.texi
> @@ -31,3 +31,9 @@ Mac OS X 10.13, Solaris 11.4, Android 9.0.
>  Portability problems not fixed by Gnulib:
>  @itemize
>  @end itemize
> +
> +Note: This function does not provides high-quality random numbers, as needed
> +by some crypto applications.  If you want such high-quality random numbers,
> +use the function @code{getrandom} with the @code{GRND_RANDOM} flag or 
> (better)
> +use the @samp{crypto/gc-random} module and configure with
> +@samp{--with-libgcrypt}.
> diff --git a/doc/glibc-functions/getrandom.texi 
> b/doc/glibc-functions/getrandom.texi
> index 3baf390..7488f6f 100644
> --- a/doc/glibc-functions/getrandom.texi
> +++ b/doc/glibc-functions/getrandom.texi
> @@ -29,6 +29,12 @@ Solaris 11.4.
>
>  Portability problems not fixed by Gnulib:
>  @itemize
> -This function cannot produce truly random numbers on some platforms:
> +This function cannot produce truly random numbers, even when the
> +@code{GRND_RANDOM} flag is given, on some platforms:
>  GNU/Hurd, Mac OS X, GNU/kFreeBSD, FreeBSD 12.0, OpenBSD 6.5, Minix 3.3, AIX 
> 7.1, Haiku, mingw, MSVC 14.
>  @end itemize
> +
> +Note: This function does not provides high-quality random numbers, as needed
> +by some crypto applications, even when the @code{GRND_RANDOM} flag is given.
> +If you want such high-quality random numbers, use the @samp{crypto/gc-random}
> +module and configure with @samp{--with-libgcrypt}.

Nowadays it may be prudent to simply state the data returned from the
prng should be treated as a seed and not used directly. Some folks
will use it directly even though the security properties may not be
present. For folks who need crypto parameters, suggest they use
Krawczyk's HDKF to extract the entropy from the seed and expand it.
HKDF provides provable security properties and Krawczyk provides the
analysis.

I would avoid labels like "low quality" and "high quality". It is
impossible to judge at runtime without auditing mechanisms in place
operating on the returned data. Even trying to pick a test at runtime
to judge the stream is like trying to pin jello to a wall.

Also, it looks like (to me) getrandom may suffer VM rollback attacks.
So claiming a stream is high quality may be questionable if a reboot
produces the same stream.

The problem of VM rollback attacks is kind of tricky. For that problem
you usually use hedging. Also see "When Virtual is Harder than Real:
Security Challenges in Virtual Machine Based Computing Environments"
and "When Good Randomness Goes Bad: Virtual Machine Reset
Vulnerabilities and Hedging Deployed Cryptography".

Jeff