ietf-openpgp
[Top] [All Lists]

Re: Sample Twofish message

1999-04-07 23:20:13
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