The monoculture of meritocracy [LWN.net]

The monoculture of meritocracy

Posted Dec 1, 2012 19:29 UTC (Sat) by ThinkRob (subscriber, #64513)
In reply to: The monoculture of meritocracy by khim
Parent article: Crowding out OpenBSD

>This is good example. Let me rephrase the question: why do you think Linux is a problem while AES and SHA are Ok? IOW: why even have a contest where one winner is picked and then reused everywhere if monoculture is so bad?

I think there's a simple answer to that, actually: the impact of bugs.

If a kernel that's been out in the wild for some time has a bug due to a lack of attention, then users might hit crashes or lose data. That's bad, but it's fixable. Users may be able to work around it, and a lot of crash bugs are not *that* hard to fix once they're identified (finding/reproducing them is the hard part.)

If a cipher has been out in a while, and is found to have a bug that, say, reduces the key strength from 128 bits to 50 bits, that's also bad. But unlike a kernel bug which can be fixed or worked around, the impact of the bug is retroactive. All of the data encrypted with that broken cipher is now vulnerable. Worse still, there's no way to recall it. Some bad guy intercepted your traffic protected with $BUSTED_CIPHER? Well if he kept a copy around once the bug is found he can go back and decrypt it.

Unlike a kernel bug, a crypto bug can be devastating for *years* after it's been found and fixed, and there's not always a way to mitigate the damage. So while we want solid, bug-free kernels, there is a much, much higher value placed on getting our encryption/hashing algorithms right the first time.

*That* is why I'm OK with people unifying behind one or two ciphers and one or two hashing algos. Yes, it does have the "eggs in one basket" issue, but the cost of getting it wrong can be so very high that we really want to ensure that we have as many eyeballs on it as possible.

(Log in to post comments)

The monoculture of meritocracy

Posted Dec 10, 2012 12:51 UTC (Mon) by ekj (guest, #1524) [Link]

If you're paranoid about it, you nest ciphers (with unrelated keys!)

You use AES( k2, BLOWFISH( k1, plaintext)) which is secure aslong as *either* blowfish *or* AES survives.

You can do the same thing with hashes, but you need to concatenate or interleave them rather than nest them - the result is a hash that is as large as the sum of the two -- and that remains secure aslong as atleast once of the hashes is secure. (and *possibly* secure even if both hashes are broken)

Even someone who -can- find sha1 and md5 collisions *might* have a harder time finding two distinct documents that collide in both md5 and sha1. (yes I'm aware that md5 has been broken)