

Complexity is insecurity - cperciva
http://www.daemonology.net/blog/2009-09-04-complexity-is-insecurity.html

======
damienkatz
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.

~~~
cperciva
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. :-)

------
10ren
_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._

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

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

~~~
cperciva
_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.

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

~~~
cperciva
_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.

~~~
tptacek
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...](http://archives.neohapsis.com/archives/bugtraq/1999_1/0736.html)

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

~~~
cperciva
_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. :-)

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

~~~
cperciva
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.

~~~
tptacek
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.

~~~
cperciva
_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.

