From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 029651F55B for ; Mon, 1 Jun 2020 13:46:04 +0000 (UTC) Received: from localhost ([::1]:46342 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jfklO-0003YL-Qk for normalperson@yhbt.net; Mon, 01 Jun 2020 09:46:02 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:32840) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jfkl3-0003IZ-UL for bug-gnulib@gnu.org; Mon, 01 Jun 2020 09:45:41 -0400 Received: from mail-io1-xd41.google.com ([2607:f8b0:4864:20::d41]:37414) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jfkl1-0001Jf-W4 for bug-gnulib@gnu.org; Mon, 01 Jun 2020 09:45:41 -0400 Received: by mail-io1-xd41.google.com with SMTP id r2so6959886ioo.4 for ; Mon, 01 Jun 2020 06:45:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to; bh=k0tuEOxm68PhBdSOMMacGapypPwawrUJuANmvRe1Yg0=; b=AtUYpthPqdT3cwBbTdqOPLGEYUTtAIDsYaVjhSrt5ia9/KmeLVuPAUoxUmrFIuXCr+ xzoagJE5I0NS6HlnmvinDycgifSDd+ebKWk84Cz5p8NP/Hgjoxunsp1FCCxoJXVIPoB6 oFodtzkQCRPukXv9IN7y4sb6SWTYw7g4ytXp3KMVUMLfh6yf5KUFSxPzeR98Wb92WSK2 isB9xd43Qp2TftkjSsCLRwcwNrwnQIRLLsv5w+Udk7jMZJnRN3eIoVFu9VCag6TzzWua dZc0We6FKTdlCKl8JsSKVxTa4iDNo+GLDwDqKgX7EjW0NbfkrBzM5M6bZu5X9Cs11LAp 44Ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to; bh=k0tuEOxm68PhBdSOMMacGapypPwawrUJuANmvRe1Yg0=; b=kcpA4Tm6p8bptJaPMmwjjuSh2TDJmN1L651Q2XUwbEVNKEl2i9aXL3n4ui5DzSHp20 RkI49yi5Az4IX9kXBCw6jQkSX4cMzf4c1KcM9uuW6OWQi69TdUODVRrpl0jVBfrw1ZWJ mX43fh5B0vHJ81iPcJ6/Z4q31Yv+UbXeTUraOSyvIx5eMUPWidr2EwWZDrmLFOgTj9Oy waXbiMYyYBddnHZRPc7bJKQJR9r7II/oqMZLKrMvvjeUfjgBXXPvjdIGy9LJ/1uoCYmk jBvQ2S40eqAodQAjHLpnyZ1iHs+G3pO2iQns+lDJImPKbOQ6IAvqbcM4vsm6Ldn8Q9V4 twSg== X-Gm-Message-State: AOAM5301Ot8kVUH56pf24w3n9KqdEZAn6wislQaOnZkJWEY8kzQ/Jlqv EeTvf8WSi+b8eRH2gVY08dObqtu1piQMqByQvPAcg7DEdio= X-Google-Smtp-Source: ABdhPJxdETg6pxlzM8ncVkT6mMEfMfwvPAX5YS33p5UbkVbah9YniFKt0ipWVetfxteBlpGjN/G8wCAPvFFMLxvltzA= X-Received: by 2002:a02:810:: with SMTP id 16mr21645813jac.17.1591019138164; Mon, 01 Jun 2020 06:45:38 -0700 (PDT) MIME-Version: 1.0 References: <20200525193753.12395-1-eggert@cs.ucla.edu> <4410554.e4VoEpFJVW@omega> <5726410.jNJkLPuzOh@omega> In-Reply-To: <5726410.jNJkLPuzOh@omega> From: Jeffrey Walton Date: Mon, 1 Jun 2020 09:45:09 -0400 Message-ID: Subject: Re: getrandom vs. crypto/gc-random To: bug-gnulib@gnu.org Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2607:f8b0:4864:20::d41; envelope-from=noloader@gmail.com; helo=mail-io1-xd41.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: noloader@gmail.com Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" On Sun, May 31, 2020 at 3:02 PM Bruno Haible 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 > > getrandom, getentropy: Mention the crypto/gc-random module. > Suggested by Simon Josefsson in > . > * 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