Jon Callas <jon(_at_)pgp(_dot_)com> wrote on Fri, 20 Mar 1998:
Previous discussion of this decided that we wanted to either simplify the
iterated-salted S2K or drop it. In the current draft, I simplified by
changing the 8-bit coded number to a 32-bit number.
It sounds to me like people are willing to live with the original
description. Is this correct? I'm perfectly willing to change it back. Make
your voice heard if you care.
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.
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?
Jim Gillogly
Hevensday, 28 Rethe S.R. 1998, 23:52
12.19.5.0.8, 7 Lamat 6 Cumku, Eighth Lord of Night