[Bug libc/29437] arc4random is too slow

["adhemerval.zanella at linaro dot org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=29437

--- Comment #11 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to Florian Weimer from comment #8)
> (In reply to Cristian Rodríguez from comment #4)
> > (In reply to Miroslav Lichvar from comment #0)
> > 
> > > This can be fixed easily in the chrony source code, but I thought it might
> > > be a good example of a real-world application impacted by this change and
> > > there could be others.
> > 
> > You need a PRNG, seeded by a single call to arc4random_buf.. (xoroshiro128+?)
> > People are unfortunately rejecting your usecase as invalid because this does
> > not require a csprng. :-( (to me that sums up everything that is wrong, you
> > known you don't need one, but notmal averege joe programmer has no idea of
> > all the subtleties ans is stuck with using random() ..)
> 
> Absolutely not. The idea behind arc4random is that an entire distribution
> can use this function without worrying performance or properties of the
> generated stream of randomness. It was designed for a search-and-replace of
> calls to random, without case-by-case reviews if the change is actually
> required for security reasons. If the glibc implementation does not meet
> that, we have failed.

I disagree that we have failed, the main problem is that arc4random
implementation from OpenBSD (which is copied on multiple systems and libraries)
did not take into consideration the problems Jason has raised, and thus now
callers expect a certain performance on any possible system (even if the
cryptographic secure part can not be safely enforced).

So the question is should we trade performance or correctness?

-- 
You are receiving this mail because:
You are on the CC list for the bug.