The monoculture of meritocracy [LWN.net]

The monoculture of meritocracy

Posted Nov 14, 2012 1:18 UTC (Wed) by geofft (subscriber, #59789)
In reply to: The monoculture of meritocracy by josh
Parent article: Crowding out OpenBSD

So the article says "Monocultures are unhealthy in general; a Linux monoculture may be the ultimate vindication of our approach to development, but it still would not be a good thing for the world as a whole. As in natural ecosystems, diversity is a source of strength."

I'm happy to disagree with that, and say that either Linux isn't a monoculture or that Linux is a good monoculture, and that all the BSD developers should give up and switch. :-) But it's what the article says, so I'm assuming it's representative of our community. Maybe it's not!

That said, to give one possible argument, we might find a class of attacks against a certain way of thinking about things in Linux that wouldn't happen against another OS. This sort of thing is certainly common in low-level crypto design (e.g., side-channel attacks from algorithms that aren't carefully designed to do the same operations regardless of the input), and is one of the many motivations for the AES and SHA competitions involving getting lots of different people to propose different ideas and attack each other's ideas, instead of collaborating on a single algorithm. On the software side, I've heard of cases where, e.g., several separate security bugs were found regarding NT's kernel entry ABI, and you couldn't fix those bugs at once without completely redesigning that ABI and possibly API.

(Log in to post comments)

The monoculture of meritocracy

Posted Nov 15, 2012 14:12 UTC (Thu) by khim (subscriber, #9252) [Link]

This sort of thing is certainly common in low-level crypto design (e.g., side-channel attacks from algorithms that aren't carefully designed to do the same operations regardless of the input), and is one of the many motivations for the AES and SHA competitions involving getting lots of different people to propose different ideas and attack each other's ideas, instead of collaborating on a single algorithm.

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?

AFAICS Linux fulfills the same role as AES or SHA: different implementations are offered and one it picked, then used everywhere. If it was a bad decision then later it can be changed (see: DES to AES and MD5 to SHAxxx transitions).

We don't support the ability to use some exotic and clever ciphers in our documents and web-servers (only when some cipher wins the contest it's used for "real" programs), why should we support the ability to run "real" programs on experimental OSes like OpenBSD or Haiku?

On the software side, I've heard of cases where, e.g., several separate security bugs were found regarding NT's kernel entry ABI, and you couldn't fix those bugs at once without completely redesigning that ABI and possibly API.

If that happens then you need to redesign said ABI, it makes no sense to cultivate series of OSes each with it's own problems: sooner or later they all will be compromised if you'll not tighten them up.

The monoculture of meritocracy

Posted Dec 1, 2012 19:29 UTC (Sat) by ThinkRob (subscriber, #64513) [Link]

>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.

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)