Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <b33914f7-660a-e5c9-f77b-2f6227ea8ab8@linaro.org>
Date:   Mon, 25 Jul 2022 12:59:39 -0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
 Gecko/20100101 Thunderbird/102.0.3
Subject: Re: arc4random - are you sure we want these?
Content-Language: en-US
To:     Rich Felker <dalias@libc.org>
Cc:     "Jason A. Donenfeld" <Jason@zx2c4.com>, libc-alpha@sourceware.org,
        Florian Weimer <fweimer@redhat.com>,
        Yann Droneaud <ydroneaud@opteya.com>, jann@thejh.net,
        Michael@phoronix.com, Paul Eggert <eggert@cs.ucla.edu>,
        linux-crypto@vger.kernel.org
References: <YtwgTySJyky0OcgG@zx2c4.com> <Ytwg8YEJn+76h5g9@zx2c4.com>
 <6bf352e9-1312-40de-4733-3219721b343c@linaro.org>
 <20220725153303.GF7074@brightrain.aerifal.cx>
From:   Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
Organization: Linaro
In-Reply-To: <20220725153303.GF7074@brightrain.aerifal.cx>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 25/07/22 12:33, Rich Felker wrote:
> 
> If this is just a case of trying to be "cautious" about overpromising
> things, the documentation needs fixed to specify that this is a
> CSPRNG. I'm particularly worried about the wording "these still use a
> Pseudo-Random generator and should not be used in cryptographic
> contexts". *All* CSPRNGs are PRNGs. Being pseudo-random does not make
> it not cryptographically safe. The safety depends on the original
> source of the entropy and the practical irreversibility and other
> cryptographic properties of the extension function. The fact that this
> has been stated so poorly in the documentation really has me worried
> that someone does not understand the issues. I haven't dug into the
> list mails or actual code to determine to what extent that's the case,
> but it's really, *really* worrying.

That's the main drive to avoid calling CSPRNGs, since nor me or Florian
is secure enough to certify current scheme can actually follow all the
requirements.  It does follow OpenBSD strategy of a fast-key-erasure 
random-number generators, although all strategies of key reseeding are
basically heuristics.

If I understand Jason argument correctly, unless we have a kernel API
which it actually handles the buffer (so it can reseed or clear when it
seems fit), there is no point is proving a CSPRNGs in userspace, use
getrandom instead.