Hacker News new | past | comments | ask | show | jobs | submit login
Complexity is insecurity (daemonology.net)
58 points by cperciva on Sept 4, 2009 | hide | past | favorite | 15 comments



Good article, but I was hoping this was about how intellectual insecurity tends to create complexity. To not value and create simple things due to a desire to show off how smart you are with a mastery of the deeply complex.


Well, I'm a computer scientist, not a psychologist. I did consider titling the post "the insecurity complex", but I figured that would be even more likely to be misunderstood. :-)


There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. - C. A. R. Hoare

But I prefer Adams related formulation for usability:

... their fundamental design flaws are completely hidden by their superficial design flaws.


It's not just code complexity. I recall having to deal with older versions of pgp and gpg which made even some simple operations relatively complicated. I am positive that it would have been possible to talk people into doing stupid things by offering to 'help' them understand what they were to do to sign keys or something like that.


Code complexity != insecurity.

Case in point, many cryptographic algorithms are complex (by non-cryptographic standards) but essential. That doesn't make them insecure, just less inscrutable.

It is when 'things are missed' in information security that insecurities occur (e.g. developer is not aware of strcpy limitations so uses it regardless) - writing a simpler malloc will not save you from a stack-based overflow.


many cryptographic algorithms are complex

I'd dispute that. Aside from multiprecision arithmetic for asymmetric cryptography, which I'll admit uses a fair number of lines of code, most cryptographic algorithms are quite small (SHA256 and AES are both well under 200 LoC); and all well-written cryptographic code should be "straight-line" code, i.e., with a cyclomatic complexity of 1.

e.g. developer is not aware of strcpy limitations so uses it regardless

Nothing will save you from developers who blindly use functions without knowing what they do. I was writing for the benefit of those people who already meet a certain minimum level of competence.


Algorithmic complexity is dwarfed by real world software complexity the vast majority of the time. However, even for pure math I think the thesis still stands just fine: more complex mathematical proofs are more likely to contain flaws than simple ones. Things "can be missed" at any level, in real code or theoretical, which is why you want to minimize any opportunities for things to be missed.


Great article, but why write your own XML parser? Rolling your own if all the available implementations were alphas and betas, but given that there are so many solid and well-tested solutions, aren't you unnecessarily increasing your project's total complexity?


Great article, but why write your own XML parser?

I didn't write my own XML parser. I wrote my own parser for XML-minus-stuff-which-makes-it-really-hard-to-parse.

...given that there are so many solid and well-tested solutions...

Name a simple well-tested XML parser with a good security track record. Heck, never mind simple and well-tested... name an XML parser with a good security track record. As far as I know, none exist.


You know, Marcus Ranum once decided to write an HTTP server "minus the stuff in HTTP that makes it hard to write a safe HTTP server" for his Network Flight Record intrusion detection product.

http://archives.neohapsis.com/archives/bugtraq/1999_1/0736.h...

Not that you're Marcus Ranum. Among other things, you never provoked us into finding a horrible flaw in your product. SO WATCH YOUR MOUTH, BUDDY.

It really is a common failure mode, though. "OpenSSL looks scary, so I'll just implement a subset of SSL on my own."


Among other things, you never provoked us into finding a horrible flaw in your product

I haven't? Gosh, I'd better try harder. Please download the tarsnap client code and look for horrible security flaws. :-)


Just by saying that, you've already screwed yourself. =)


No I haven't. My security metric for tarsnap is "can the NSA break this"; as much as I respect your abilities, I have a feeling that any security flaws you can find, the NSA can also find.


I wasn't talking about me; my point was, by being reasonable, you're going to have a hard time picking fights with security researchers.

Incidentally: you'd be surprised how many "names" in the industry are ex-NSA.


I wasn't talking about me; my point was, by being reasonable, you're going to have a hard time picking fights with security researchers.

Hmm, you may have a point there. In that case... there's no way you'll ever find any security flaws in tarsnap! My code is far too good for either you or anyone else to find any bugs in it! And your mother is... oh, never mind. I'm really not very good at acting unreasonable. :-)

Incidentally: you'd be surprised how many "names" in the industry are ex-NSA.

Fair enough -- but the principle of conservatism requires me to presume that the NSA has at very least more resources than its former employees.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: