[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Unnecessarily bloated IV calculation
>From [IO-RES] Appendix B:
In phase 1, material for the initialization vector (IV material) for
CBC mode encryption algorithms is derived from a hash of a
concatenation of the initiator's public Diffie-Hellman value and the
responder's public Diffie-Hellman value using the negotiated hash
algorithm. This is used for the first message only. Each message
should be padded up to the nearest block size using bytes containing
0x00. The message length in the header MUST include the length of the
pad since this reflects the size of the cyphertext. Subsequent
messages MUST use the last CBC encryption block from the previous
message as their initialization vector.
Why do we need to do so much work to generate this IV? I realize that
we want some sort of uniqueness guarantee, but this is absurd. I know
this sort of calculation is cheap for many implementors, but it both
takes extra CPU cycles and extra code space to implement while adding no
additional security.
I would suggest using the cookies to generate this IV. The cookies are
with us from the beginning, so we don't have to delay this calculation
any longer than necessary. (Has anyone tried to produce a state machine
for ISAKMP/Oakley?). If not, perhaps an XOR of the two DH values would
be okay. Either way, neither end can compromise the security for both
ends.
Please don't dismiss this message as creating unnecessary changes "at
this late date". I have been hearing that for nearly six months, while
the WG is seeming to stagnate under the burden of an unnecessarily
bloated protocol. There are many simple changes such as this which
would make the protocol much more implementor-friendly, while not
negatively affecting the security at all.
ben
Follow-Ups: