On Mon, 29 Jun 1998, Werner Koch wrote:
I am just curious:
How does OpenPGP cope with 128 bit block ciphers (AES)?
The data is encrypted in CFB mode, with a CFB shift size equal to
the cipher's block size. The Initial Vector (IV) is specified as
all zeros. Instead of using an IV, OpenPGP prefixes 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
Wouldn't it be better to prefix it with 16 random bytes for 128 bit
ciphers? Maybe we can remove the special CFB mode for these ciphers?
I spotted this a few months ago. Technically the prefix should be the
blocksize plus 2 and the text should be changed everywhere (including the
long description of the reset) replacing 8 with Blocksize. I have these
as #defines in my implmentation but they are likely to become variables,
so I was ready for this.
For that matter, what is the block size of a stream cipher? (Applause
with the sound of one hand clapping if you can answer correctly). Or one
that is a number of bits that is not divisible by 8?
Later the spec says:
After encrypting the first 10 octets, the CFB state is resynchronized
if the cipher block size is 8 octets or less.
but as you point out, using an IV of all zeros might still compromise the
first few bytes (of possibly known plaintext). The resynch should be BS+2
(similar problems occur with blocksizes smaller than 8).
Since no listed algorithm used a different block size it wasn't an issue
(and why I will oppose adding any new ones, and am strongly suggesting
deleting some).
It would make sense to change the places that use "8" to Blocksize and
"10" to Blocksize+2, and do stream ciphers without any CFB (but prefix it
with either 4 or 10 bytes, the last pair being copies of the penultimate
pair). This mod will have to be in the next version of the spec.
--- reply to tzeruch - at - ceddec - dot - com ---
Just say MAY and nits go away.