The Two Threads of Dr. Cohen

[cman@communities.com (Douglas Barnes)]

There are two threads to Dr. Cohen's arguments which bear
separation. One thread, with the implications of deliberate
wrongdoing on the part of Derek Atkins or others unnamed
should be dismissed out of hand. His comments regarding the
fundamental security properties of PGP and the burden of
proof for software security are right on target.

One has to draw the line somewhere with regard to what "they"
are out to do. PGP may have had weaknesses from the beginning,
but to suggest a deliberate change so subtle to escape PGP's
original authors is to descend into the realm of paranoia.
In addition, such allegations are extremely rude, and I think
Dr. Cohen owes Derek an apology.

At the same time, I think some apologies are in order with
respect to some very good points raised by Dr. Cohen about
software security. There is a whole sub-discipline of CS
devoted to the construction of trusted computer systems, which
if practiced can result in much greater assurances about the
reliability and security of the resultant software. This is
(I believe) the source of Dr. Cohen's assertion that the
burden of proof is on those who claim something is secure.

PGP is practically a poster child for how not to write a secure
piece of software. It has had a great many authors. It is non-
modular. It is large and complex. Simplicity is almost always
sacrificed at the altar of even slight performance gains. It
is absolutely infested with platform-dependent code. And these
are only the problems that directly impact its security... it's
also strongly tied to a tty-style interface and implements a
poorly-designed format.

With respect to "tiger teaming" PGP, I think it is a pretty
hopeless proposition. It is never, ever going to be as secure
as some people would like it to be. Given the past and current
bug discovery rate, it is almost inconceivable that there are
not exploitable bugs. This is not to say it isn't "pretty good",
but it is not what someone with a formal background in real
secure systems developement would ever bless as "secure".

PGP needs to be thrown away and rewritten from scratch. This
has, in fact, been done, but while this development effort has
been incrementally better, it still doesn't qualify as a
secure development approach. Also, nobody has this product yet
for reasons that I won't mention as we don't need to start
another tangential flamewar.

In any event, I think it's important for people to realize that
in the security community, the burden of proof _is_ on the
software developer, not on those claiming security problems.
I'm surprised Perry hasn't chimed in on this score yet, many
of his posts allude to similar notions of security by design
and by construction.

Doug