At 03:46 PM 3/20/98 PST, Jim Gillogly wrote:
The original concept doesn't seem comparatively obnoxious -- yes, it has
the
byzantine bit-twiddling that we've come to know and/or love, but at
least is
only one octet's worth. I don't see spending 4 octets on an iteration
count
that likely won't be used beyond 2 octets' worth. If we specify an
iteration
count high enough to slow down a 333 GHz Pentium VIII enough to foil its
dictionary attack, the pokey 333 MHz Pentium II won't be able to do it once
in reasonable time. I'd just as soon go back and save 3 octets, as long as
the C-like conversion expression from the previous draft stays in the text.
There are a number of people (myself included) who find PGP's tendency to
bit-twiddle in order to save three octets maddening. I'm a lot more
sympathetic to Lindsay Mathieson's plea to live with the bit-twiddling
because when it's done it's done.
However, I'd like a little more clarity in the next part of the section
that
describes how the iterated octet count is actually used. This and the
previous section talking about multiple hash contexts could benefit from
some diagrams, I think.
While we're on clarity (well, I am, anyway), would it be possible to filter
a diagrammatic form of Hal Finney's latest explanation of CFB into section
5.7?
Certainly the explanation, I was already planning that. Diagrams, I'm not
so sure about. The RFC format of 58 lines per page of 72-character lines
make a constrained canvas for any sort of diagram. The few we have have an
unerring ability to find page breaks, which I then clean up by hand. I'm
considering it, though for the CFB explanation. I'm also considering
pseudo-code there.
Jon
-----
Jon Callas jon(_at_)pgp(_dot_)com
CTO, Total Network Security 4200 Bohannon Drive
Network Associates, Inc. Menlo Park, CA 94025
(650) 473-2860
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA)