Re: arc4random - are you sure we want these?

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

On Wed, Jul 27, 2022 at 08:34:17AM -0300, Adhemerval Zanella Netto wrote:
> The only thing I am kinda worried is we will need to be judicious if
> we aim to use arc4random internally for hardening, since on some pattern
> usage and kernels we might hit some performance issues.  For instance,
> we will need to tune down some internal parameters for a glibc testing
> because now on a somewhat recent kernel (5.15.0-41-generic) I am seeing
> a 10 runtime increase which the change to use getrandom.  Jason has
> told it has been fixed upstream, but taking in consideration the box
> is an updated Ubuntu 22.04, it might take some time to have this fix
> propagated on all kernels out there.

What I'd suggest is that we be a realistic about specific use cases.
Are we talking about scientific simulations?  You don't want to be
using be using secure random number generation for that anyway,
because most reputable scientists have this thing about repeatable
experiments.

Are we talking about key generation?  How many keys per second is it
really realistic that such a system would need to support?.  How many
SSL connections would it be *able* to support?  And since a secure web
server or VPN gateway is going to be on the network, then you're going
to want the latest kernel fixes, since there have been quite a some
Really Bad Security vulnerabilities that have been fixed just in the
past week (especially if you care about FEDRAMP or PCI compliance) at
which point, you'll get the new and improved getrandom(2).

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.
Sure, maybe numbers would look small on a low-end ARM system --- but
how many secure web transactions or IPSEC/wireguard connections could
such a low-end ARM system really support, *anyway*?

One of the dirty little secrets of web sites who live and die by
clickbait performance benchmark articles for advertising revenue is
how rarely real life workloads really are bottlenecked by things like,
say, file system or /dev/random benchmarks.  Reading those articles
are *fun*, for people who like to say that their systems' metrics are
longer/faster/stronger/whatever, but it's rare that they actually
impact real world use cases.  More often than not, the bottleneck is
elsewhere.

Cheers,

					- Ted

P.S.  The newer /dev/random drier would probably help out people who do things
like "dd if=/dev/urandom of=/dev/expensive-ssd-where-it-would-be-way-faster-
and-less-destructive-of-write-wearout-to-use-hdparm-security-erase bs=4k" ---
but that's not really relevant to the glibc arc4random() discussion.  :-)