On Tue, 25 Nov 1997, Hal Finney wrote:
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:
...
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.)
Either way, however lock in either a fixed 8, or fixed "Cipher Block Size"
early. Right now I have 8 hardcoded, but all three existing algorithms
use 8 byte blocks. Also quickly define a >8 byte block size cipher with
number and implement something so interoperability can be easily checked.
...
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.
I managed to get totally confused by the CFB stuff, but managed to hack
something that worked for 2.6.x starting with idea_cfb64_encrypt(buf1,
buf2, 10...) (from SSLeay - yes, 10 bytes), and after verifying the last
two byte pairs are identical, I reset the iv counter and load the ivec
with the original first 8 bytes, and then just use idea_cfb64_encrypt
normally.
It is much easier to just do than to explain. I had to create my own
generic cfb, which was fairly simple, and cfbreset routines for PGP 5.0
since it applied the cfb function over multiple algorithms. Cfbreset
should be just:
void cfbreset()
{
memmove(&cfbivec[8 - ivleft], cfbivec, ivleft);
memcpy(cfbivec, &lastiv[ivleft], 8 - ivleft);
/* lastiv is the iv previous to the current image */
ivleft = 0;
}
Replace 8 with cipherblocksize if/when that is changed. Also note that if
the only reset occurs at the beginning, and the initial iv is all zeros,
simply copying the original cipherblocksize bytes into the iv is
sufficient. This is currently true of how cfbreset is used in the
existing PGP implementations.
The worst problem I have is that various libraries have different data
types (sizes), so the iv data must be converted from/to the 8 byte cfb
vector to/from the 32bit words or whatever in a portable way. So although
there is not an "endian" assumption per se, when DES and IDEA use 32 bit
entities, I have to insure that the char[4] aligns properly. This isn't a
problem if there is an internal X_cfb64_encrypt call in the lib for all
conventional algorithms I want to implement.
--- reply to tzeruch - at - ceddec - dot - com ---