Rich, That was the best email I have ever read on this mailing list. Congratulations and thank you. Please post this as a blog post somewhere.
NK On Tue, Mar 5, 2013 at 6:23 PM, Rich Kulawiec <[email protected]> wrote: > On Fri, Feb 15, 2013 at 01:35:53PM -0800, Adam Fisk wrote: > > At the risk of getting swept up in this by consciously saying something > > unpopular, I want to put my shoulder against the wheel of the "open > source > > process produces more secure software" machine. [snip] > > I've been thinking about your (excellent) comments for several weeks now. > And I'm going to argue that open source doesn't necessarily produce more > secure software, but it's a prerequisite for any credible attempt. And > that in this particular case, there's just no substitute for it. > > But before I get started, let me pointed out that I'm very much *not* > arguing that the contrapositive is true, that "open source == chewy > goodness" automatically. We've all seen open source code that was junk. > Lots of it. We've all probably written some, too; I know I have. > > So here goes: > > Consider this hypothetical: you have the imaginary disease Bieberitis, > which progressively imposes the characteristics of Justin Bieber on you, > then kills you. So not only do you die, you die badly. Clearly: it's > an awful fate. > > There are only two drugs available to treat this disease. > > Drug A has a history that looks something like this: the basic > biochemistry has been known for 18 years. It's been studied at multiple > universities and research institutions. There are numerous published > papers on it. Early animal trials were conducted 15 years ago, and those > results were published as well, leading to another round of animal trials > with a slightly different formulation and more publication. Following > review by independent agencies 12 years ago, limited human trials were > held, with still more publication. A lengthy review and debate ensued, > the drug was discussed and debated at numerous conferences and meetings, > other (new) researchers weighed in with their papers, and a second > round of human trials took place 9 years ago. Following that, review > by multiple government agencies commenced. Additional work continued > in parallel on refinement of dosage and delivery. Eventually, following > another blizzard of paperwork and publication, the drug was approved -- > and is now available to you. Studies are still ongoing, of course, > and it's expected that half a dozen more papers will be published in > referreed journals this year. > > So: drug A has a long history. Lots of clueful eyeballs have investigated > it personally, and many more clueful eyeballs have read the published body > of work, thought about it, argued about it, reviewed it, critiqued it, > supported it, rebutted it, and otherwise been involved in the process. > Moreover: nearly all those clueful eyeballs are INDEPENDENT clueful > eyeballs, who have, in many cases, substantial motivation to disprove > claims made -- since one of the best ways to make one's academic > reputation is to perform ingenious, ground-breaking work which > demonstrates that something everyone agrees on is completely wrong. > > Now, about drug B: drug B has no publications associated with it. > It's never been independently reviewed. It has none of the lengthy > history of A. What's it got? It's got a shiny color brochure written by > the marketing department that tells you how great it is, because it was > developed by some of the top people ever. Really. Top people. As in: > > Major Eaton: We have top men working on it now. > Indiana Jones: Who? > Major Eaton: Top...men. > > That's it. That's all you get. Promises. Assurances. Hand-waving. > Top...men. > > Now: which drug are you going to take? > > Of course the obvious answer is A, since B is more commonly known as > "snake oil". It's garbage. No thinking, responsible person would > ever choose B, because -- absent the history and the research and > the publication and everything else -- it might be the instant cure > for Bieberitis, or it might be sugar pills, or it might be poison. > There's no way to know. > > All serious fields of intellectual endeavor use the same model as I > outlined in the development of drug A, which I'll lump under the rubric > "peer review". Architecture and law, physics and economics, medicine and > civil engineering, everybody uses this. And they use it because, despite > its flaws, it works really, really well. It's an essential component of > the scientific method. It's how we make forward progress, however slowly. > > Fields of study that don't use this are crap. Astrology, creationism, > alchemy, homeopathy, phrenology, and yes, closed-source software: all crap. > > There is no way we should accept what any closed-source vendor claims > about their code. There is no reason to, no matter who they are, no > matter how much we trust them, no matter how pure their motives are. > Heck, we often can't even trust OUR OWN CODE to do what we think we want > it to do, even when we're staring right at it -- so why in the world > should we make the fantastic leap of faith to trust someone else's when > we can't even see it? > > Closed-source software is the equivalent of drug B. We're expected > to take the authors' word that it (a) does everything they say it does > and (b) does nothing else. We're expected to do this despite decades > of history proving, many times per day, that this is not only wrong, > but completely, wildly, amazingly wrong. (For a small drink out of > the firehose of evidence substantiating that statement, read bugtraq, > or full-disclosure, or the -developers list for any substantial project, > or the bug queue for something hosted on SourceForge, or check the patch > lists for any piece of software, or look at your own code.) > > We, for a value of "we" meaning "all programmers on this planet", > pretty much suck at writing software. Even the best of us, and I'm > sure not one of them, struggle to write programs of any size/complexity > that meet their functional specifications and don't have major security > or privacy issues. The only slim chance we have of maybe, MAYBE, on > a good day, with the wind blowing in the right direction, of actually > getting somewhere vaguely close to what we're aiming at, is peer review. > It's not a great chance: but it's the best we've got. > > Maybe in 50 years that'll change. Maybe by then we'll able to write > large-scale/complex programs with verifiable code that matches verifiable > specifications. But we're not there yet, so yeah, I'm gonna stick with: > source or GTFO. > > But wait! There's more! > > This isn't just any old piece of software: this isn't a word processor > or a database: this is crypto that is intended to keep people *alive*. > And while I won't even pretend to be a cryptographer, one thing I've > learned is that developing solid cryptographic algorithms is hard. > Really hard. People with significant expertise in the field spend > mountains of time working on them...only to find that 8 months after > publication, somebody on the other side of the world has already managed > to mount a credible attack. Then there's a tiny crack...and soon someone > else widens the crack...and then, in a flurry of published papers and > conference presentations, the whole thing gets demolished. > > Or at least compromised to such an extent that everyone concurs it won't > survive much longer, that what's on the table strongly indicates that > better attacks will come along and finish the job. > > The only way, really, that we can have any confidence in any cryptographic > algorithm is to see it published...and then wait. We wait to see what > happens when people get a look at it and start thinking about ways to > tear it apart using either theoretical or practical attacks, or more > likely, both. > > How long do we wait? That depends. There's no fixed schedule. > But every year that an algorithm withstands scrutiny slightly increases > our confidence that this is not an accident -- that it's not escaping > attack because nobody's trying, but because it truly is robust in the > face of clueful and determined experts. > > So in the case of cryptography software, it's not just source or GTFO: > it's publish the algorithm or GTFO. > > ---rsk > -- > Too many emails? Unsubscribe, change to digest, or change password by > emailing moderator at [email protected] or changing your settings at > https://mailman.stanford.edu/mailman/listinfo/liberationtech >
-- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at [email protected] or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
