-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ian Grigg, <iang(_at_)systemics(_dot_)com>, writes:
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.
We will need to make some alterations when it is time to support ciphers
with block sizes larger than 64 bits. There is language in the draft
which would allow us to fix it at that time. The current wording is:
: The data is encrypted in CFB mode, with a CFB shift size equal to the
: cipher's block size [Ref]. The Initial Vector (IV) is specified as all
: zeros. Instead of using an IV, OP prepends a 10 octet string to the
: data before it is encrypted. The first eight octets are random, and
: the 9th and 10th octets are copies of the 7th and 8th octets,
: respectivelly. After encrypting the first 10 octets, the CFB state is
: resynchronized if the cipher block size is 8 octets or less. The last
: 8 octets of ciphertext are passed through the cipher and the block
: boundary is reset.
Notice "resynchronized if the cipher block size is 8 octets or less".
This means the resync will go away for larger block ciphers. However now
I realize that the 8+2 header will not be right for such ciphers, either.
Probably we should replace the "8" with the block size of the cipher.
Any other suggestions on how to revise this?
(Note that the purpose of the two redundant bytes is to tell if you have
the right key for decryption.)
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 considered another way of documenting the resynchronization of the
CFB mode. It can be described pretty cleanly as follows: Encrypt the
first 8 bytes in CFB-64 mode, the next two bytes in CFB-16 mode, and
the remainder of the message in CFB-64.
In other words, you encrypt the first 64 bits (8 bytes) and shift the
shift register by 64 bits, bringing in new data; then you encrypt the
next 16 bits (2 bytes) and shift the shift register by 16 bits, bringing
in new data; and then you go back to encrypting 64 bits at a time and
shifting in 64 bits of new data each time.
Someone familiar with the meaning of CFB-n might find this description
to be clearer. Any preferences?
Hal
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv
iQA/AwUBNHpwNcDh8jnv1nHwEQL2uQCg0utkjVCOh1RClQcKDs9W15Vaxu0AnRLe
sVg7l3g6rMqgp/ioCMVx9EoU
=DxbI
-----END PGP SIGNATURE-----