Security is Mathematics • Hacker News Board

Re: Security is Mathematics

#11

Post by jdp23 » Tue, Feb 15, 2011, 6:47 PM UTC

stcredzero wrote: post #10

jdp23 wrote: post #8

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.

Right. I don't think thorough economic analyses come into play nearly enough when people think about security.

Also an excellent point. Ross Anderson started pushing the term "Security Engineering" around 2000 and economics were a big part of it.

Re: Security is Mathematics

#12

Post by jdp23 » Tue, Feb 15, 2011, 6:49 PM UTC

kenjackson wrote: post #7

wging wrote: post #4

Earlier quoted context omitted.

>writing programs is harder than writing a proof Which programs and which proofs?

Any program function can be cast as a theorem (although vice-verse is difficult). Proving this theorem is easier than writing the corresponding program function. And by easier, I mean that the proof is easier to pass off as a correct proof than the program is to pass as a correct program. Of course, writing an actually correct proof is just as difficult as writing an actually correct program -- for the most part. Of…

I agree in the abstract, but ...

- what's the largest program you've written? - what's the largest program you've proved correctness of?

So in reality, meaningful proofs are much much much harder than writing programs.

Re: Security is Mathematics

#13

Post by adsr » Tue, Feb 15, 2011, 6:50 PM UTC

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.

Re: Security is Mathematics

#14

Post by jdp23 » Tue, Feb 15, 2011, 6:51 PM UTC

te_platt wrote: post #5

wging wrote: post #3

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.

I don't think he is trying to say mathematics is sufficient to be good at security, just that training in mathematics develops the right mindset for security. I have a degree in math and can see how my attitude changed as I progressed. When taking my first analysis class I was sure it is no coincidence the word begins with anal. It took a while for me to develop habits of skepticism about things that seem obvious at…

true, but the same's true for any rigorous training -- philosophy, Talmudic studies, law, physics, ...

Re: Security is Mathematics

#15

Post by thehotdon » Tue, Feb 15, 2011, 7:01 PM UTC

Or more generally, everything is mathematics.

Re: Security is Mathematics

#16

Post by kenjackson » Tue, Feb 15, 2011, 7:02 PM UTC

jdp23 wrote: post #12

kenjackson wrote: post #7

Earlier quoted context omitted.

Any program function can be cast as a theorem (although vice-verse is difficult). Proving this theorem is easier than writing the corresponding program function. And by easier, I mean that the proof is easier to pass off as a correct proof than the program is to pass as a correct program. Of course, writing an actually correct proof is just as difficult as writing an actually correct program -- for the most part. Of…

I agree in the abstract, but ... - what's the largest program you've written? - what's the largest program you've proved correctness of? So in reality, meaningful proofs are much much much harder than writing programs.

what's the largest program you've proved correctness of?

But that's the point. With security code, while you may not prove the correctness of it, there's a black hat that's trying to find a counterexample to your "proof".

Whereas for 99% of proofs that are published in the literature no one is trying to prove that there are flaws in the proof. As someone who reviewed CS papers I would always try to really read at least one proof in the paper. Not skim, but really scrutinize it. Probably 75% of the time I could find a problem with the proof. Usually one that was easily corrected, but it was still wrong. But it took substantial effort to do this (which is why I only did one per paper and just read the other proofs).

Re: Security is Mathematics

#17

Post by mdwrigh2 » Tue, Feb 15, 2011, 7:06 PM UTC

kenjackson wrote: post #2

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. But in any case, the gist of the ar…

I'd argue there is a certain notion of fuzzing with proofs. Say I have a proof claiming that a certain function is monotonic. Fuzzing, in this case, is throwing a bunch of numbers at the function and checking to see if it's actually monotonic with regards to your inputs.

Obviously not all math proofs are regarding functions and definable numbers, but there's a similar concept of fuzzing for each different proof type -- it just might not be easy to automate, or state in a programming language.

Re: Security is Mathematics

#18

Post by dkarl » Tue, Feb 15, 2011, 7:32 PM UTC

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

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?"

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

Re: Security is Mathematics

#19

Post by tptacek » Tue, Feb 15, 2011, 7:34 PM UTC

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!

* Mark Dowd

* John McDonald

* Alex Sotirov

* Dino Dai Zovi

* Charlie Miller

* Michal Zalewski

* Aaron Portnoy

* Dave Aitel

* David Litchfield

* Barnaby Jack

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.

Re: Security is Mathematics

#20

Post by juiceandjuice » Tue, Feb 15, 2011, 7:51 PM UTC

dkarl wrote: post #18

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 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 physicist…

True for a very well-defined set of inputs.

The problem with writing secure code that works well is making sure that all inputs conform to your well-defined set... i.e. they are a subset of your well-defined set.

Compounding on this is the non-apparent dimensionality of your sets. A good example of this would be concurrency. If a function doesn't have an exclusive lock an an array of data it's going to manipulate, the set could actually have two dimensions (one being time), in which the array could change.

I got a C- in Analysis II. I needed a C to get a Math minor, but decided it wasn't worth it.