Subject: Re: Low-level question about OpenPGP - why CFB mode?

From: [email-masked] (Peter Gutmann)
Date: Thu, 1 May 2003 16:18:47 +1200

"Hal Finney" <[email-masked]> 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.

---

From: Adam Back <[email-masked]>
Date: Thu, 1 May 2003 05:53:40 +0100

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

---

From: Ian Grigg <[email-masked]>
Date: Thu, 01 May 2003 11:54:46 -0400

> I believe it was an implementation bug/quirk, not a deliberate design

I had heard that it was an attempt to make it
"more secure", like the salting of the Unix
password (DES) :-)

Either way, their appears
to be no justification for continuing its use,
and a good reason for deprecating it:  it is
rather complex to document and program up, this
conversation about the munged CFB mode has been
had many times in the past (here and elsewhere)
and will be had many times in the future.

In the spirit of improving the codability of
OpenPGP, I'd suggest it be replaced with a
standard textbook or FIPS mode.

(Not in the current version of course, but at
the next convenient moment.)

-- 
iang

---

From: Derek Atkins <[email-masked]>
Date: 01 May 2003 12:32:44 -0400

> standard textbook or FIPS mode.

<chair hat>

In the interest of finishing the OpenPGP work, I claim it is too late
in the process to make such a major change to the protocol in terms of
losing compatibility with all prior versions.  Having implemented this
non-FIPS mode, it is NOT that complicated, and the text we have that
describes it (indeed, the text in RFC 1991 that described it!) has never
been a hinderance to implementation.

The only questions have been "why do you do it this way?" which is not
IMHO a reasonable reason to force a change at this late date.  It may
be a reasonable reason to add text explaining why we do it this way,
or comparing it to the FIPS CFB mode, but that could go in an appendix
just as easily as it could go into the text.

</chair hat>

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com