I seem to remeber some comments in the 2.x code tree from Colin Plumb
discussing the merits of the CFB resync.
Here we go:
* That is, the last 4 bytes of a 12-byte field are en/decrypted using
* the first 4 bytes of IDEA(previous 8 bytes of ciphertext), but then
* the last 4 bytes of that IDEA computation are thrown away, and the
* first 8 bytes of the next field are en/decrypted using
* IDEA(last 8 bytes of ciphertext). This is equivalent to using a
* shorter feedback length (if you're familiar with the general CFB
* technique) briefly, and doesn't weaken the cipher any (using shorter
* CFB lengths makes it stronger, actually), it just makes it a bit unusual.
from idea.c; actually it looks to be just a comment about the security
of different feedback lengths in CFB mode.
On use of CFB instead of CBC, I think this is actually goos because
it avoids the whole padding issue which people frequently get wrong
with bad security implications. Plus it's simpler to not have to pad.
Error recovery is a phantom property, as in no mode is it secure.
Adam
On Thu, May 01, 2003 at 04:18:47PM +1200, Peter Gutmann wrote:
"Hal Finney" <hal(_at_)finney(_dot_)org> writes:
I think this may have been the reason that Phil chose CFB. As for the non-
standard "sync" operation, I don't remember why he did that. Probably it just
seemed to be a natural way of handling CFB given his understanding of its
rationale in terms of the way it interfaced with the underlying cipher.
I believe it was an implementation bug/quirk, not a deliberate design
decision.
Peter.