Uri Blumenthal, <uri(_at_)watson(_dot_)ibm(_dot_)com>, writes:
Werner Koch says:
We use a 8 byte IV for encrypting the secret key material; see
section 5.5.3. Do we keep this 8 bytes or extend it to the blocksize?
IV length normally is equal to the block size. I see no reason to
divert from this.
With regard to the secret key encryption:
The only real requirement on an IV is that it is unique for that key,
that it does not match any other IV's and it doesn't match any of the
ciphertext blocks which are used with that key. For this purpose,
64 bits should be adequate unless we store more than 4 billion (2^32)
private keys using the same passphrase (and even then the unique salt
would save us). So a 64 bit IV is plenty big.
However in the interests of convenience and consistency it would probably
make more sense to use the block size. This avoids any ambiguities
about whether a shorter IV should be left or right justified and how
the remaining bits of the block should be filled in.
With regard to message encryption, the symmetrically encrypted data
packets:
The 8+2 bytes which precede the message are not technically an IV; the
IV is zero, and the 8+2 bytes are used in place of an IV to accomplish
the same purpose. However this size does not work properly in the case
of 128 bit blocks.
If we had two messages encrypted with the same key, then for each of
them we would encrypt a block of zeros and XOR that with the first 16
bytes of the message, to form the ciphertext. Only the first 10 bytes
are random; the remaining 6 are plaintext. Therefore the last 6 bytes
of this first block of data would be the first 6 bytes of plaintext,
xored with a value which was the same for each encryption where that
same key was used. This would allow an attacker to recover the XOR of
the first 6 bytes of the plaintexts of multiple messages, and possibly
therefore to find these 6 bytes of plaintext.
This is a serious leak. We would possibly be saved by the fact that
the spec says to use salt in hashing the passphrase, so it is unlikely
that any two messages are encrypted with the same key even if the same
passphrase is used. But still there is no reason to take this chance.
Therefore we should increase the 8 bytes to be the size of the block
cipher.
Several people have commented that they don't like the extra CFB sync
operation which is done after the first 8+2 (or now 16+2) bytes are read.
It is a nonstandard operation and requires special code in the CFB module.
I had suggested that we skip the CFB for larger blocks, on the theory
that we would eventually migrate to larger block ciphers throughout,
and then we could retire the CFB sync along with the support of 64 bit
block ciphers. This would be perhaps four or five years from now.
It is not difficult to code the CFB sync to be optional based on
block size. Can we consider keeping the language to use the extra
sync only for 64 bit block ciphers?
Hal Finney
NAI, Inc.