[Top] [All Lists]

Complexity not a dominant strategy for independant deployment

1997-11-24 17:35:36
It seems that every time that one of the technical people from PGP Inc
post that we leap forward in our understanding of what's happening. 
Thanks Hal.

Hal Finney wrote in "Re: hand huffman encoding at PGP world HQ:"

It is true that Phil Zimmermann has been the chief advocate of making
PGP data structures as concise as possible.  (I don't know whether Jon
actually goes around the office singing songs about it or not.)  Phil is
out of the country now so I will try to relay some of his thinking.

First, the difficulty is really not as large as people are making out.

Well, I have to disagree on that.  The difficulty is high.  I recall the
swearing going on when each one of the infamous bit twiddles was finally
debugged out of the Cryptix code - not pleasant to be on the same
mailgroup as that discussing yet another PGP furfy.

There are only a handfull of people who really understand the formats,
and they have invested years in the exercise.  You're probably one of
them, I'd hazard a guess that Derik and Will are too.  Outside that
small group, which might think of it as "not so hard," we have a whole
bunch of people who are working on this, but have different motivations:

  * hack something up to please the boss / move onto the
    next project.  Somebody's paying for this.
  * no particular loyalty to pgp formats, above say SMTP
    or IP or ... most will be expert in many things rather
    than just one protocol, so there's only a limited
    attention span.
  * no particular loyalty to pgp, against say SMIME or
    hacking up their own, which would be a *lot* simpler
    and would do the the same job.

Another factor is that many of these people did not choose to be in the
PGP bit-twiddling profession, their paymasters sent them into it.  We've
all got our cross to bear, but in this case there is the valid
difference between those that are conscripted and those that volunteer. 
The people who are going to coding up the future generation of OP might
not actually be the right programmers for the job.  The more you head in
to the standards and respectable systems field, the lesser becomes the
benefit from programmer self-selection.

And then there's the simple documentation exercise.  The standard, huge
as it is, will be a daunting factor in itself.  The bigger it gets, the
more difficult it is to go through all the conformance exercises that
are now necessary - something that until now has been ignored in
programmer calculations.   Conformance testing is generally more complex
than writing the code in the first place...

Up until now, it has been the fact that the only documentation was the
code.  PGP code is not the worst I've come across, but it's not the
best.  Having the code-as-dox is a reasonable strategy when it is well
written, but elsewise, you're adding a cost.  Having a complicated
standard will result in a three-way reliance of programmers on the
standard, the code and the conformance tests.

Complexity is not a good strategy for widespread adoption by independant
developers.  I think the notion of going for a MUST 32 bits,
MUST/SHOULD? read others and MAY produce others has some merit, which
still allows PGP Inc to pursue their minimalist signature aspirations.


FP: 1189 4417 F202 5DBD  5DF3 4FCD 3685 FDDE on