I agree with the author’s sentiment about FIPS 140. I find NIST to be incredibly slow. I understand there must be some stability, but they are too slow. For example, I think it's horrible that they are still recommending PBKDF2 in 2025.

▲

SAI_Peregrinus 7 hours ago | parent [-]

A big part of the problem I have with it is that it's a "ceiling" on security. Things like electrical code or building code are a "floor" on quality, you have to be at least as good as the code requirements, but can freely be better. FIPS-140 bounds you both ways. If you could more easily do better it'd be much less of a problem that NIST are slow.

▲

fl0ki 6 hours ago | parent | next [-]

In fairness, it's one thing for an implementation like a building to be as over-enginereed as possible in its own right, but it's another when a standard has to ensure that multiple implementations can interoperate. I'm not saying FIPS-140 has only that kind of limitation (far from it), just that this isn't the best analogy.

▲

akerl_ 5 hours ago | parent [-]

Is any of FIPS about ensuring interoperability?

▲

dlgeek 4 hours ago | parent [-]

Yeah, there's a ton of correctness testing involved. That's mostly at the algorithm, rather than the module level, so it'll fall under CAVP/ACVP rather than CMVP.

	▲	akerl_ 4 hours ago \| parent [-]
		That's not for interop, that's for "are you actually doing the crypto you said you'd do". It's designed to prevent broken crypto, not to ensure coordination between parties.

▲

Analemma_ 5 hours ago | parent | prev [-]

I don't love FIPS either, but cryptosystems don't work the same way as buildings and electrical codes. It's very easy to have "secure cryptosystem A" and "secure cryptosystem B", and then have massive security holes in "cryptosystem A + B". This happens all the time, and is one of the main reasons for the classic "don't roll your own crypto" admonition. The FIPS "whole system" mandate is meant to forestall this failure mode.