New Linux /dev/random RNG Revved For The 43rd Time

[ddriver]

A new revision does not imply previous versions are wrong.

Only that it is not good enough.

[Jakobson]

A new revision does not imply previous versions are wrong.

The patchset must be keep updated all the time against the latest kernel version and its changes. The implementation was already ready about 20 patchset versions ago. Only the maintainer of random subsystem has been totally unresponsive.
Some people also do not like the idea Linux LRNG would be FIPS 140-2 compliance not even opt-in as it is implemented. Also a developer of one famous VPN kernel module, which purposely utilize only non-NIST approved algorithms, has strong opinion against FIPS compliance needed for governmental use cases.

[Old Grouch]

A new revision does not imply previous versions are wrong.

Only that it is not good enough.

Yes, well Newtonian physics augmented (and sometimes corrected) Aristotelian and Ptolomeic physics; and Einsteinian physics augmented (and sometimes corrected) Newtonian physics. No-one has yet successfully merged General Relativity and Quantum Gravity, so we know the Einsteinian description is incomplete.

The same applies to software. Incomplete does not mean useless, we just acknowledge improvements can (or maybe should) be made. Depending on the scope/use-case, what you have might be good enough. Just because we know General Relativity gives an incomplete description of nature does not make it useless; and the same goes for previous versions of software.

[quaz0r]

invoking quantum physics and general relativity is rather fitting here actually

[szymon_g]

Also a developer of one famous VPN kernel module, which purposely utilize only non-NIST approved algorithms, has strong opinion against FIPS compliance needed for governmental use cases.

elaborate, please

[intelfx]

It shouldn't take this much to make it right.

Clearly they should have call on you to do it. You know so much on the subject

Maybe they should have called you? You clearly have a strong opinion on the matter.

[sdack]

I do not know the past history of this patchset, but this response to the latest posting may be of interest:
http://lkml.iu.edu/hypermail/linux/k...1.2/05647.html
(Jason A. Donenfeld being the guy behind wireguard.)

Thank you. It certainly was an interesting read. That said, Jason comes across like an asshat and his opinion should be ignored. There was nothing constructive about it. He could have suggested making FIPS compatibility configurable, instead, he complains about it all and goes as far as making it personal. The current random number generator when used on embedded systems with limited entropy can certainly use some work considering how one has to run haveged in userland just to make it work.

[Jakobson]

He could have suggested making FIPS compatibility configurable...

FIPS has been a kernel configuration option and will also be in Stephan Müller's implementation (it's disabled by default). I strongly feel there should be freedom to enable an option to harden LRNG just like kernel has options to mitigate e.g. various side-channel and speculative branch predictor vulnerabilities which might be overkill for an ordinary user.

[Old Grouch]

I think the overly simplified summery is that if you want a FIPS 140-2 compliant system, it must be impossible to negotiate to use non-approved algorithms and use non-approved methods.

From the point of view of the Linux kernel, some people wish to preserve the flexibility of using non-approved algorithms.
From the point of view of people wishing to operate FIPS 140-2 compliant systems, some people wish to ensure non-approved algorithms are not available, and FIPS 140-2 approved methods of generating random numbers are used.
In the case of the random number generation method, some people can argue quite strongly that non FIPS 140-2 compliant mechanisms are more appropriate to their use-cases.

I am absolutely not an expert here: but I suspect setting a system flag that tells the kernel to operate in FIPS 140-2 compliant mode or not is not an acceptable solution for certification of FIPS 140-2 compliance, which hinders (if not completely prevents) the mainline linux kernel from being used in situations where certified FIPS 140-2 compliance is mandatory.

All of the above could be hogwash. Please do your own research. If you care to share the results of your own analysis, please do. Unfortunately, I have other things I need to do, as I'd love to get to the bottom of this, but I can't justify spending the time on it right now. Hopefully someone will be afflicted with siwoti and post a correct summary.

[sdack]

... From the point of view of people wishing to operate FIPS 140-2 compliant systems, some people wish to ensure non-approved algorithms are not available, and FIPS 140-2 approved methods of generating random numbers are used. ...

Not calling it hogwash as per your suggestion, but I would like to point out that this view is somewhat narrow-minded when it is about open source. Anyone can modify the code any way they like. Thus for cryptography options to be configurable at compile time should not be an issue. For options to be configurable at run-time do we need to rely on the kernel's own security model. However, simply making code unavailable is not a guarantee for security without a kernel itself being secure in the first place. From what I have read about LRNG does it offer mostly compile-time options and the concerns raised appear to be more FUD than founded. If there are no more real issues with it that one could address then one should start supporting it.