On Wed, Jul 27, 2022 at 4:15 PM Theodore Ts'o via Libc-alpha <libc-alpha@xxxxxxxxxxxxxx> 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? Well pretty much everywhere a shared library is involved from the start.. On one very basic vm here there are 18 shared libraries using srandom, thus perturbing each other states if loaded by the same process, possibly in a catastrophic/predictable way. and nobody uses the random_r interfaces. > And what are their performance and security > requirements? Common programmers know nothing about this, even seasoned ones don't.. if it runs slow or is not CSPRNG then the average app will use one userspace PRNG or CSPRNG or buffer from the kernel somewhere.. I do not have to justify this assertion..it is just a matter you download libgcrypt, gnutls, openssl none of those libraries use the kernel entropy as the first option, all feed them to either proven or dubious s RNGs schemes and then pass that to users. Think on why that is and why we are discussing yet another interface in the first place..
