Hi Ted, On Mon, Jan 10, 2022 at 3:31 PM Theodore Ts'o <tytso@xxxxxxx> wrote: > There might be some FIPS certification labs that might be willing to > be taken in by the jitterentropy story, but when I've had private > communications from people who are familiar with the Intel > microarchitecture saying that jitterentropy is mostly "security by > obscurity", I'd be strongly opposed to replacing the current scheme > with something which is purely jitteretropy. > > Perhaps an build-time option where one of the seeds into the CRNG is > "jitterentropy", but we keep everything else. That way, jitterentropy > can still be TSA-style "security theatre", but we're not utterly > dependant on the "the CPU microarchitecture is SOOOOOOO complicated, > it *must* be unpredictable". Yea, I'm not really compelled by it as something real that we'd actually want to have for something serious. Keep in mind: this thread isn't really about cryptography, but just about compliance nonsense. BUT, if it turns out that the path to these people getting their green compliance checkbox stamp isn't actually thousands of lines of new code, but rather some glue bridging the /dev/urandom / getrandom(2) API into the blah cryptoapi thing, that's... interesting news to me. I'm not even saying, at this stage anyhow, that I want to do this, but I do find it a very interesting data point. As I wrote in [1]: > Specifically, I think that if you change your perspective from, "how can we > change the algorithms of the RNG to be FIPS" to "how can we bend FIPS within > its limits so that having what customers want would minimally impact the > quality of the RNG implementation or introduce undue maintenance burdens." We're now starting to get some idea about how this FIPS stuff bends. Jason [1] https://lore.kernel.org/lkml/CAHmME9qP9eYfPH+8eRvpx_tW8iAtDc-byVMvh4tFL_cABdsiOA@xxxxxxxxxxxxxx/
