On Tue, Sep 19, 2017 at 9:39 AM, Theodore Ts'o <tytso@xxxxxxx> wrote: > On Mon, Sep 18, 2017 at 01:24:18PM +0200, Jason A. Donenfeld wrote: >> Good luck with getting approval... While Ted and I have our >> differences like any two kernel developers, I really tend agree with >> him in his attitude about this FIPS silliness. ... > > Let me add one more reason why FIPS compliance for the kernel is just > ***stupid***. The way FIPS compliance works, you have to pay hundreds > of thousands of dollars to a FIPS certification lab to certify a > specific binary, complete with the exact build environment (compiler, > binutils, etc.) used to build that kernel binary. > > The moment you need to make a change --- say, to fix a critical > zero-day security bug --- this breaks the FIPS certification, ... > > You might say that FIPS certification != FIPS compliance. Sure, but > the only silly people who care about FIPS compliance also need FIPS > certification, for the US Goverment signoff. I do not think it is just the US that matters here. If I understand Stefan correctly, one of his concerns is German (or EU?) gov't standards that are somehow related. I'm very hazy on details. I emphatically agree with Ted on some points here. Making FIPS certification a goal for kernel development would be really dumb. Having multiple RNGs available & compile-time options to select among them also looks silly to me; we just need one good one. On the other hand, I do not see why the driver should not use a FIPS-compliant PRNG where it can. This would make things easier for anyone who does seek certification. One of the big distro vendors? A gov't department or contractor that wants to use Linux? A corporation's sys admin or security reviewer? Stefan? I cannot see much downside to this. Is the current PRNG more efficient? More easily maintained? Is it still the case that random(4) must use only hashes, not ciphers, to avoid restrictions under export laws?