On Wed, Jul 27, 2022 at 04:15:24PM -0400, Theodore Ts'o via Libc-alpha wrote: > 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. The only place I've heard of a viable "soft requirement" for real entropy is for salting the hash function used in hash table maps to harden them against DoS via intentional collisions. This is a small but arguably legitimate usage domain. Most use of random() is not this, and should not be this -- the value of deterministic execution for ability to reproduce crashes, debug, etc. is real, and the value of actual entropy vs a deterministic-seeded prng is imaginary. The purpose of arc4random has always been *cryptographically secure* entropy, not "gratuitously replace random() and break reproducible behavior because the programmer does not understand the difference". Nobody should be advocating for using these functions for anything except secure secrets. Rich
