Okay, how can we resolve this conflict:
From section 5.7:
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 8th octets,
respectively. 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.
From section 12.8:
OpenPGP CFB mode uses an initialization vector (IV) of all zeros, and
prefixes the plaintext with ten octets of random data, such that
octets 9 and 10 match octets 7 and 8. It does a CFB "resync" after
encrypting those ten octets.
Note that for an algorithm that has a larger block size than 64 bits,
the equivalent function will be done with that entire block. For
example, a 16-octet block algorithm would operate on 16 octets, and
then produce two octets of check, and then work on 16-octet blocks.
5.7 says that resync is only done for a blocksize <= 64 but 12.8 says
that is done always (the following step by step list also says this).
Please, can we agree on one version - I don't care which one, but it
is a bad idea to change this after the first message/secret-key has been
enciphered with a >64 bit blocksize cipher.
We should agree on an interpretation of these questions:
* Use resyncing at all for ciphers with a blocksize > 64 ?
* Use it for encryption of secret key material in V3 packets ?
* Use the blocksize or 64 bits for the CFB shift ?
* Prepend 8+2 or blocksize+2 random bytes to the plaintext?
* Keep the 8 byte salt for S2K modes?
Werner Koch at guug.de www.gnupg.org keyid 621CC013