The best security researchers in the world are almost uniformly not trained in mathematics. Here's a short list of top-tier researchers. Spot the mathematicians!<p>* Mark Dowd<p>* John McDonald<p>* Alex Sotirov<p>* Dino Dai Zovi<p>* Charlie Miller<p>* Michal Zalewski<p>* Aaron Portnoy<p>* Dave Aitel<p>* David Litchfield<p>* Barnaby Jack<p>This doesn't invalidate the blog post, but I will go on to suggest that quite a lot of people with extensive formal training in mathematics either (a) have/had careers in software security with less spectacular results than e.g. Aaron or Michal or (b) have produced, despite incentive to the contrary, some really crappy code.
Computer security is a social science, so degrees in ethnography, epistemology, or organizational behavior are a lot more relevant than mathematics. Agreed that math teaches you rigorous thinking and questioning assumptions, but outside of the narrow areas of cryptography and systems analysis the specific skills you learn aren't that important for security work.
<i>Knuth is famous for the remark "Beware of bugs in the above code; I have only proved it correct, not tried it", and the implicit statement that a proof-of-correctness is not adequate to ensure that code will operate correctly is one I absolutely agree with</i><p>My boss told me a similar story of a computer science professor giving a cross-group talk in which he pitched the concept of formal methods to a group of physicists who, among other things, programmed collectors for particle experiments. (Supposedly this happened at Cornell in the seventies.) The CS professor enthusiastically and animatedly proved the correctness of an algorithm for solving a simple graph-coloring game and then asked whether there were any questions. One of the physicists raised his hand and asked, "How fast does it run?"<p>"That's the beauty of formal methods! Now that I've proved the algorithm correct, I already know it will produce the right answer. There are far too many possible inputs to verify correctness via testing, so there's actually no point in running it at all."
Where the author's narrative breaks down is when he draws a parallel between security and <i>proofs of theorems</i>. The closer connection is between security and <i>adequacy</i> of theorems.<p>It is true that you need to make sure your software conforms to its specifications and that process does involve informal (or formal) proof-like reasoning, but that is only a small part of the challenge. <i>This</i> is the part that mathematicians would be good at, but other technologies are good at the this as well (type checkers prove weak properties, verification tools prove stronger ones). None of this requires a "twisted mind", just attention to detail.<p>The problem of writing software specifications that correspond to the <i>abstract notion of security</i> is the tougher task. In math, the closest analogy is figuring out what theorems people actually care about. While I don't know for sure, I'm skeptical that a math education emphasizes this skill. Security takes this skill a step further and requires Schneier's "twisted mind" to consider all the real-world ways that things could go wrong (including, among other things, the incentives that might motivate an adversary) and write specifications for secure, but useful, software.
Forget security, <i>programming</i> is mathematics. If you program, you should be doing this whether you're writing security code or not. Nothing saves me more keystrokes or debugging time than proving things about my algorithm before I code it, and I know this comes from math because my CS-only friends <i>can't do it</i>. I don't care if you want to go in to algorithm theory or get a software job at a bank, if you're a CS major, you need to take some rigorous math or you'll be at a disadvantage.
I am not sure that I buy this. There are plenty of people who have internalized a painstaking and rigorous approach to problem solving, often from a young age. While many of these are also those who would excel in a mathematical environment, a mathematical education fails to capture any of the specific details of security.
This article is correct, except it omits one important point... writing programs is harder than writing a proof. Especially security code. With sufficiently complex proofs it is often hard to find holes in the proof, but with security code (and code in general) there are ways to attack it, that just isn't doable with standard math proofs. There's no notion of "fuzzing" with proofs.<p>But in any case, the gist of the article is correct -- the rigor used in math proofs is the MIN bar for security code.
But isn't this ignoring a holistic view of security and the fact that many flaws comes down to human errors, not only in code, but in procedures and organisations. It seems to me that by saying: security is math, there is a risk of ignoring that part of the problem.