And on & on.
Thomas Ptacek | August 9th, 2005 | Filed Under: Uncategorized
By the way, at some point, someone is going to have to explain to me the difference between vulnerability research in “normal” software and research in “cryptographic” software. If you discard vulnerability research and disclosure (aka “cryptanalysis”) from cryptography, you lose, well, the whole field of cryptography.
This is self-evident, of course, and it’s the reason Bruce Schneier urges aspiring cryptographers to go break a published cryptosystem before they try their hands at designing new ones. It’s much harder, and much more educational, to break a cryptosystem than to design a crappy new one.
(By the way, this provides the response to Ranum’s demogoguing “it’s easier to break things than to build them (comma-asshole)” quip. Maybe it’s easier to break bad things than to build them, but there’s nothing easy about building or breaking a good thing.)
Clearly Schneier-citing anti-disclosurites see some kind of divide between the vulnerability research Biham, Shamir, Bernstein, Kocher, and Schneier himself does, and the kind of research eEye does. I even buy that the line they’re talking about exists. But where to draw it?
If you end the “legitimate” research at math, you lose “the hardest part about designing a cryptosystem” (to paraphrase the fantastic Practical Cryptography). Lots of protocol flaws can be deduced with pen, paper, and a spec, but if you draw the line at “anything that doesn’t involve source code flaws”, you miss things like “don’t use S-boxes because they leak timing”.
Sure, most software bugs are simple. Grepping for “strcpy” is less of an accomplishment than discovering differential cryptanalysis. You win, crypto geeks. But there are plenty of simple cryptosystem flaws, too. And there are plenty of very complicated software flaws. For that matter, it may be easy to write new x86 stack overflow exploits, but the first one sure as hell wasn’t; it tooks months after being goaded by 8lgm to get it down.
I totally buy that this is a line that people like Lindstrom, Schneier, and Davidson would like to be able to draw. The rule could be, “disclosures that demonstrate novel vulnerabilities that will enable us to fix whole classes of problems will be published in detail, and everything else will be obscured”. I agree. It’d be great if we could. But we don’t know a lot of things about computer science (which is why vendors can get away with selling software that ignores the Halting Problem). What are you gonna do?
Writing about full disclosure is the easiest thing in the world to do for a security blogger, so every word I write about it feels like cheating. I’m going to try to stop now.
