[Cryptography] "Is FIPS 140-2 Actively harmful to software?"

[Dirk-Willem van Gulik]

Op 20 jun. 2014, om 15:11 heeft Ben Laurie <ben at links.org> het volgende geschreven:

> On 20 June 2014 14:00, Jerry Leichter <leichter at lrw.com> wrote:
>> He never quite says "yes" but he clearly thinks it.
> 
> I think it, too. I did the beginning of the first implementation for
> OpenSSL, and I hated it then. For example, they made me remove the
> inclusion of the PID in the random pool (which prevents duplicate
> randomness after a fork).
> 
> It hasn't got any better.


Arguably it got worse and slower.  

And yes, It is very easy to rally behind this type of sentiment; the stupidity; the inefficiency of good design processes done by committee and the meagre output of their output; especially given the immense volume and quality of individual inputs. 

If there ever was a competition for a crap one with substandard governance - FIPS would do well in that race!

However I’d caution agains going too far and de-facto/industry wise killing it by voting with our feet.

Without FIPS (or a similar standard), no matter how low or bad, we loose ‚aim’. And we’re suddenly in a world where the ‚how good is it’ is subject to scrutiny; questioning; and where the organizations around us are exposed to the fact that a lot of this is about sound, yet subjective, engineering judgement and trust in persons. And hence all sort of forces and adverse processes shake loose. And in the end; it is not sound engineering that wins - but power and what that power wants.

Part of the the reason for speaking up right now is driven by the various parliamentary inquiries around tunnel safety happening in here in the Netherlands. A few fairly critical and complex tunnels where designed (well) against contemporary international tunnel safety standards. They where commissioned according to these (high*) standards. 

In the aftermath of the Mont Blanc tunnel accident the various international standards for tunnel safety were reconsidered and revised. This led to a perceived absence of standards during the execution; and hence a top down `we never compromise on safety’ sort of pressure. And the then predictable fallout on timeline, public perception, budget. And in summary in an endless cycle reminiscent of The Very Hungry Caterpillar; where a politician cannot be (ever) be re-assured by the engineers adding a safety feature; as it is not their reassurance he seeks - but the grandstanding one gets during the process of seeking and the show of power that ‚demands’ the costly extra.

What was interesting was that during these enquiries the lack of a standard (no matter how low or high) led to situations where even the very best engineers where forced to go on the book that they would never ‚compromise’. Forgetting the core tenet of their profession - to build the best/safest *within* the confines of reality, budget, possibility, time or whatever other constraint.

In my day to day job, I, and my customers, are highly dependent on the various tokens, talismans and good blessings of these standards. No matter how crap - it is better than nothing - and provides helpful abstractions behind with a professional can re-mediate what is needed w.r.t. quality; the fact that the situation is not quite that what is covered by the rule, etc. 

And loss of *that* is what I fear in this post-Snowden world. 

That we collectively kill FIPS, NIST et.al. — and thus invite a whole raft of powers and subversion into our profession that are *stronger* and ultimately not good for security**. 

So yes - 140-2 may be harmful to some patients - but it does help securing the herd.

Thanks,

Dw.



*:  Keep in mind that the Netherlands is _flat_; tunnes do not go through mountains but are a few meters under the surface.
**: And yes - I am sure one can think of some lovely psy-ops/subversion/complot theory circular arguments here :)