On Mon, 7 May 2018 18:28:01 -0500 Benjamin Kaduk <ka...@mit.edu> wrote: > At high risk of opening up the RNG debate that I did not want to > revisit, the current stance of upstream krb5 seems to fall into what > I'll call the "Schneier worldview", that a fully-seeded > well-designed CSPRNG can produce arbitrary amounts of random output > with no need to track "entropy depletion" or similar (emphasis on > fully-seeded).
This is a good summary of my position (speaking as the current best representative of "upstream krb5"). In particular, prior to getrandom(), I had been frustrated with these Linux /dev/[u]random properties: 1. /dev/random's concept of "strong" entropy attempts to mitigate against a preimage attack against SHA-1, and therefore depletes the estimate of strong randomness available as random data is read. If you aren't trying to mitigate against an attack on the CSPRNG, you don't need any concept of "running out of" randomness, only a one-time switch from "not ready" to "ready". (You might try to further reduce the risk of predictability after you've switched to "ready" state, of course. Schneier's Fortuna algorithm does this, under the assumption that entropy estimates will always be fallible.) 2. Reading from /dev/urandom can fully deplete the strong random estimate; no portion of the estimated incoming hardware entropy is reserved for /dev/random. Most running systems read from /dev/urandom often enough that the randomness estimate constantly returns to zero, so reading from /dev/random almost always blocks for a noticeable period. I had always viewed the "strong" parameter to krb5_c_os_random_entropy() as a workaround for these kernel properties (and perhaps similar properties on other kernels, although I'm not aware of any specific examples). We always want "strong" randomness. Running a KDC and issuing tickets with predictable session keys is terrible, even if it is less terrible than generating long-term keys predictable to an attacker. But reading from /dev/random with any frequency is too painful, and reading from /dev/urandom almost always yields unpredictable output. For those reasons I was happy to accept a change to use getrandom() with no flags on Linux, ignoring the "strong" parameter any bypassing the userspace Fortuna code. I can see that this change creates new KDC availability issues on VMs, but I don't see that as a krb5-specific issue.
