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