Re: arc4random - are you sure we want these?

["Theodore Ts'o" <tytso@mit.edu>]

On Wed, Jul 27, 2022 at 02:49:57PM +0200, Florian Weimer wrote:
> * Theodore Ts'o:
> 
> > But even if you didn't take the latest kernels, I think you will find
> > that if you actually benchmark how many queries per second a real-life
> > secure web server or VPN gateway, even the original 5.15.0 /dev/random
> > driver was plenty fast enough for real world cryptographic use cases.
> 
> The idea is to that arc4random() is suitable in pretty much all places
> that have historically used random() (outside of deterministic
> simulations).  Straight calls to getrandom are much, much slower than
> random(), and it's not even the system call overhead.

What are those places?  And what are their performance and security
requirements?  I've heard some people claim that arc4random() is
supposed to provide strong security guarantees.  I've heard others
claim that it doesn't, or at least glibc was planning on disclaiming
security guaranteees.  So there seems to be a lack of clarity about
the security requirements.

What about the performance requirements?  Designing an interface where
the requirement "as fast as possible" is often not a great pathway to
success, because the reality is that engineering is always about
tradeoffs.

If there are no security requirements (given the claim that some
people want to put in the documentation disclaiming that arc4random
might not be secure), why not just have people continue to use
random(3)?

    	      	     	      	     - Ted