hal(_at_)rain(_dot_)org says:
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.
True. But:
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.
Exactly!
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.
In essence those 8+2 bytes *are* performing the function of IV.
[...description of a problem....] This is a serious leak.
Probably. (:-)
.........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.
(:-) My wish precisely!
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?
Probably. No strong preference either way.
--
Regards,
Uri uri(_at_)watson(_dot_)ibm(_dot_)com
-=-=-=-=-=-=-
<Disclaimer>