Re: [PATCH v1 1/2] random-bits: Factor out entropy generating function

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

On 04/04/2022 13:51, Noah Goldstein via Libc-alpha wrote:
> On Mon, Apr 4, 2022 at 10:00 AM Florian Weimer via Libc-alpha
> <libc-alpha@sourceware.org> wrote:
>>
>> * Jason A. Donenfeld via Libc-alpha:
>>
>>> _However_, based on what people have said in this thread, this all
>>> seems highly unnecessary, since you just need some boring
>>> statistically uniform randomness without any crypto or security
>>> requirements of any kind, and it simply needs to be fast and dumb. If
>>> that's the wrong set of requirements for this problem (I still have no
>>> idea what the bigger picture here is), please pipe up.
>>
>> If we can make a cryptographically secure generator fast enough, it
>> would relieve programmers of the need to choose between that and another
>> generator that just gives some random-looking bits fast.  If programmers
>> don't have to make a choice, they can't choose incorrectly (introducing
>> performance bugs or security bugs).
> 
> It sounds like you're talking about creating a user facing API. Since
> random_bits
> is internal do we really need so much ease of use at the cost of performance?

For a user exported ABI I think it would be better to rehearse the arc4random 
proposal, which I might spend some time to come with a simpler solution based
on Florian proposal.  For this specif proposal, I see that just factoring the
code to make only x86 use the rdtsc should be suffice.

Ideally, if we eventually get an arc4random the idea would be use it instead.
Florian initial proposal aimed to use AES so we can leverage hardware assisted
optimization presented in some chips.