Re: [PATCH 2/2] Add single-threaded fast path to rand()

[Florian Weimer <fweimer@redhat.com>]

* Zack Weinberg:

> On Fri, Mar 22, 2024, at 3:47 PM, Mathieu Desnoyers wrote:
>> On 2024-03-22 14:05, Adhemerval Zanella Netto wrote:
>>> On 22/03/24 12:30, Zack Weinberg wrote:
>
>>>> I would describe that as a "CSPRNG with a known bug that makes it
>>>> unsuitable for use under some conditions", but not as "not a CSPRNG".
> ...
>>> I tend to agree, but the contention point was really 'that makes it
>>> unsuitable for use under some conditions' was a deal breaker in face that
>>> kernel provides an API with better guarantees.
>
> How strong exactly are the guarantees that OpenBSD provides for its
> arc4random?  I don't think we *need* to do any better than that,
> although obviously we should if we can.

I don't think OpenBSD deals with virtualization in this context.  I
don't know their reasons, but the use case must be vanishingly small.  I
don't expect that there are many who worry about key disclosure due to
VM snapshots and live migration, and, at the same time, are fine with
virtualization itself as potential source of leaks.

> Independently, I propose that the existing non-cryptographic PRNGs
> (rand(), random(), etc.) should all be changed to run off a thread-local
> scrambled-linear generator
> (https://vigna.di.unimi.it/ftp/papers/ScrambledLinear.pdf).  These have
> better statistical properties than anything we currently offer, and a
> state space that's small enough (256 bits) that it's reasonable for us
> to have one per thread, obviating locking concerns.

I think that's only possible if the process has not called srand.

Thanks,
Florian