[Top] [All Lists]

Re: Complexity not a dominant strategy for independant deployment

1997-11-24 19:59:24
Adam Back wrote:

I found the non-standard CFB mode consumed more time than the LOL
twiddling (spent a bit of time with two gdb's up to get that one
working).  Not tackled the rest of the bit twiddling to date, nor the
WoT and revocation semantics.  (I only coded the PRZ style CFB and LOL
bit twiddling as an extra confidence test that my app was doing
something sensible with it's vanilla IDEA and 32 bit ints).

You raise an interesting point.  No, more than interesting, this brings
up dark memories.  Ian will confirm that there was nothing that caused
more strife in the entire Cryptix development effort over the last 2.5
years than the CFB_PGP (as it is called at the minute within
Cryptix-Java).  Five people have had a go at coding it up in an
architecturally good way such that users can see what's happening.  I
think the sixth is just about to have another go <evil chuckle>.

It never occurred to me until right now - probably because I have
cauterised that part of my brain - but it would be a big win for future
generations if we can add an alternate CFB method that is straight down
the line, and start deprecating the existing method.

I am *not* suggesting that we should make the existing CFB_PGP anything
less than a MUST to read.  The current generation can suffer.  We did.

But it would be nice to have straight CFB that could be coded up from
Schneier without resorting to black magic.  That way a non-conforming
implementation would be  quicker to get going, and if it is successful,
we could start to deprecate the CFB_PGP in the V2 that people are
looking to.  Slowly slowly, none of this unseemly rush that leaves
customers suddenly with a split email community.

I defer to the bit-twiddlers amongst us as to the appropriate way to do


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