On Mon, May 07, 2018 at 05:10:27PM +0100, Ben Hutchings wrote: > On Mon, 2018-05-07 at 11:57 -0400, Sam Hartman wrote: > > There are basically three "strengths" of random numbers available now: > > Weak: /dev/urandom > Medium: getrandom(flags=0) > Strong: /dev/random, getrandom(flags=GRND_RANDOM) > > k5_get_os_entropy() has switched from weak/strong depending on the > "strong" flag to always medium. I think what you actually want is > medium/strong.
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). So the question (for them) is not "strong" or "weak", but rather "fully seeded" or "not seeded yet". In this worldview, if you have to choose between /dev/random and /dev/urandom, (1) /dev/random is the only thing that actually provides the guarantee you want, but (2) /dev/random is incredibly painful for using "all the time", so you're tempted to use /dev/urandom for cases where it's "less important", like session keys, but reserve /dev/random for times when you really care about the "fully seeded" property, like long-term keys. When those were the only choices, the 'strong' flag made sense. Now, we have getrandom(), which is a great API and is pretty much exactly what you want (again, at least in this worldview). IIUC Ted says that you should "just use getrandom" for your entropy needs and not worry about /dev/*random. I don't know whether he takes a stance on the GRND_RANDOM flag, though. Anyway, I mention this all in the hope that we can just drop this line or discussion and let upstream krb5 decide what properties they want from a CSPRNG, and not try to revisit that design. To answer Sam's questions, in the above worldview, the right answer for the KDC and the right answer for kadmind are the same -- just use getrandom(). It provides the output of a high-quality CSPRNG, and is guaranteed to block until fully seeded. In this worldview, the cryptographic quality of the (fully seeded) urandom pool is more than adequate, so there's no need to ever pass GRND_RANDOM. I'm certainly open to having krb5 ship a proof-of-concept wait-for-entropy.service in unstable for a while, though it seems like something better suited for libc or systemd core for the long term. If we need to for stretch, it would presumably be easy enough to just add a stanza to the KDC's unit file to increase the timeout (though how do we know what sort of timeout is "long enough"?). > I'm going to start a discussion on debian-release, as we need to > coordinate a solution across multiple packages. Thanks, I'm glad someone with more time than me has already started getting the right thing done. > Jann Horn suggested improving systemd-random-seed.service so that it > actually credits entropy after feeding saved random bits into the RNG. > But this will require some care to ensure we never use the same random > bits twice (including on multiple systems built from the same system > image). Indeed, that's in the general case a rather hard problem. -Ben
signature.asc
Description: PGP signature
