Re: arc4random - are you sure we want these?

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

On Tue, Jul 26, 2022 at 10:16:19PM -0400, Rich Felker wrote:
> Last year I helped someone get musl up and running with EABI userspace
> (all we support) on a pre-EABI kernel (2.6.18 or so?) on embedded
> hardware in use in the field that could not be upgraded for hardware
> support reasons. Assuming post-2014 kernel may be okay for
> desktop/server distros but from my perspective it's pretty
> unthinkable.

Was that machine on the network in any way?  Why did it need
cryptographic keys in the first place?  Sure, maybe there are some
super-rare cases where you just *happen* to decide that you need to
use ancient hardware to generate keys that are communicated over the
serial console to sign official RPM packages for some distro --- but I
would *hope* that the distro could afford to spring for hardware that
wasn't antedeluvian.

It's fair that there are stupid people out there who think that it's
an OK thing to use software which is riddled with zero-days because
they're too cheap to update their hardware.  But my point is that if
you are worrying about fallback to /dev/urandom being a security hole,
what *other* security holes might exist on that system?

I can understand the argument the machine shouldn't fail, which
probably means you probably want to make sure the ancient code
shouldn't block forever, even if they are generating RSA
public/private keypairs for SSL certificates in their init.d scripts,
milliseconds after being booted on CPU's so ancient that they don't
support RDRAND.  But let's be real here about how secure that system
is **actually** going to be, even *if* the random number generator is
perfect(tm) and bug-free(tm).  Let's not kid ourselves.

Cheers,

					- Ted