Fixing getrandom()

Posted Sep 30, 2019 19:30 UTC (Mon) by wahern (subscriber, #37304)
In reply to: Fixing getrandom() by mezcalero
Parent article: Fixing getrandom()

Who cares if it's reused? The same 32-byte random seed cryptographically mixed with a non-repeating nonce, like the system clock, would have the same strength as a new 32-byte random seed, presuming the seed remains confidential. Long-term it's better to change the seed in case confidentiality was unknowingly violated or the nonce repeats (clock reset), but as a practical matter those aren't prerequisites to having a reasonably sane and secure system, especially considering the alternative--a multiplicity of userland CSPRNGs all scavenging for entropy independently.

Fixing getrandom()

Posted Oct 1, 2019 17:28 UTC (Tue) by alonz (subscriber, #815) [Link] (2 responses)

You're assuming that there is a reasonably-initialized system clock at the point where entropy is required – this is just as wrong as any of the other assumptions regarding entropy.

Fixing getrandom()

Posted Oct 1, 2019 19:07 UTC (Tue) by wahern (subscriber, #37304) [Link] (1 responses)

I am assuming it, but I think it's a reasonable assumption--that there are adequate sources available to minimize the chance of a repeating nonce. The system clock was just an example. And of course there are systems where the assumption can't hold at all. So what? How many systems do there need to be to hold back everybody else? 1%? 0.1?%? 0.01%? 0%?

Some systems are just hopelessly broken when it comes to entropy. And that can't be fixed. But those systems are increasingly (and at this point likely *entirely*), small, embedded systems. It was always the responsibility of the designers of those systems to either make sure there's an entropy source available or design their firmware so that it wasn't necessary (i.e. no sshd generating a new private key on first boot). Are we going to let them hold back the inevitable *forever*? At some point we have to hold the stragglers' feet to the fire and cut our losses on the installed base--most of which would never upgrade, anyhow, and are unlikely to even be using getrandom(2) in the first place.

With the prevalence of not only RDRAND and similar on-chip sources, but also many other sources (e.g. Intel QuickAssist provided a hardware generator on the NIC controller since *before* it was even branded QuickAssist, EFI provides randomness, which in some cases comes from a hardware source--but that's a QoI issue), it's time to make the switch over to assuming (*loudly* assuming) that strong entropy is available at boot or will be available very shortly after boot (see CPU jitter hack as a last-ditch effort). Almost all of userland already makes this assumption, and has for quite some time, rightly or wrongly; now the ball is in the kernel's court to make good on that assumption to the best of its ability.

This *will* happen eventually, the only question is how long we'll wring our hands over misplaced concern for embedded platforms that are and were fundamentally broken. It's been almost 15 years since the VIA C3 included an on-chip RNG. Embedded designers have had ample warning about the necessity of providing strong entropy for a long time.

Fixing getrandom()

Posted Oct 1, 2019 20:23 UTC (Tue) by wahern (subscriber, #37304) [Link]

Also, just to be clear, the context for the boot seed was systemd. The overlap of embedded systems lacking both hardware entropy such as RDRAND and a reliable system clock but still running systemd is likely not very large. But then you also need to discount that by the odds of consecutive boots where systemd couldn't re-save a seed. *And* you need to discount it further by the odds the system was doing anything security critical. *And* you need to discount this by the odds that such a scenario would be distinguishable and exploitable.

Can this scenario exist? Sure. Does it exist? We should assume so. The only question is what's the risk, and does that risk outweigh the risk of not improving other aspects of the system's randomness semantics with the consequence that software will attempt to compensate *poorly*. And, again, what's that relative risk within the context of embedded system + systemd - RNG - clock?