On Mon, Jan 10, 2022 at 03:38:08PM +0100, Jason A. Donenfeld wrote: > > 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. The last time I had the displeasure of looking into the FIPS certification, which granted, was over a decade ago when I was in IBM's Linux Technology Center, what I learned was it all depends on the FIPS certification lab. NIST writes the documentation, but what really matters is the FIPS certification lab that a hardware or software vendor pays $$$$ to in order to get the magic certificate which allows you to sell into *some* government contracts. (When I had to go through the all of the nonsense to get a TS/SCI clearance to support the real-time kernel for all of the IBM servers for the DDG/1000 Zumwalt Class destroyer, they didn't care about getting FIPS certified. I've also seen tighter security measures for computer rooms at NYC financial companies than at a Top Secret machine root at said defense contractor. Go figure....) The other thing I learned for those customers who *did* care, was that the only thing that got certified was a specific binary image. If you replace the kernel or OpenSSL library with, say, a bugfixed version that fixed an actively exploited zero day, *boom*, that would break the certification and the system would no longer be FIPS certified. Some FIPS labs would allow you to certify the "cryptographic core" of the OpenSSL library, which the OpenSSL library would then dlopen, and so as long as the bugfix was in, say, the ASN.1 parser, and you didn't need to change the "cryptographic core" it was OK --- and you just needed to hope that there weren't any bugs in the cryptographic core, since then you wouldn't be allowed to fix it --- since FIPS compliance was more important than, say, the *actual* security of the system in question. So yeah, as I said, it's all about TSA-style security theatre, and when I worked for IBM and there was millions of dollars on the line, I might have cared. For upstream development, (and blessedly, this is not something that my current employer has needed to worry about) I care far less about it. If we want to add a CONFIG_RANDOM_SECURITY_THEATRE build option which diverts getrandom and /dev/urandom to use crypto/drbg, I'm going to think it's a waste of time, and there are some things about crypto/drbg that I'm not psyched about such as the fact that only reseed after 2**20 calls to drbg_generate(), and the drbg statemachine will initialize itself from get_random_bytes() in early boot, when the CRNG is least likely to be securely initialized. So **I** wouldn't want to use it for my own personal security, but if it allows Ubuntu to sell into the US govnerment market, my only hope is that this wouldn't be inflicted on all of their customers, but only those US Government customers who care (and as near as I can tell, this is *not* all USG customers). > > 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. Well, if we optionally (if jitterentropy_rng is compiled in), we would periodically pull from it as one additional entropy source into the input_pool, it won't do any harm --- other than the CPU overhead consumed by jitterentropy, of course. Maybe that would make some people happy, including some FIPS Labs? I've also seen some FIPS certifications which didn't care about what the kernel did, but only cared about what was in the OpenSSL library. (Which is where the story about segregating out the cryptographic core so that you could actually patch most zero-days without having to go back to the FIPS certification lab, pay $$$, and wait months for the updated binary to be certified.) So I suspect that there will be a lot of anecdotal evidence, but the only thing we can probably say with any amount of certainity is Your Mileage May Vary. Cheers, - Ted
