[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 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.
If you're product can't do an additional hash to generate an IV then the
problem isn't this requirement, it's your product.
> 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.
"using the cookies" is a particularly vague suggestion: pass.
XORing the DH public values is an alternative to hashing the DH public
values. I'm not sure, though, how it frees you from the apparent crushing
burden this bloated protocol is putting on you. It might save a few CPU
cycles but compared to the rest of what you're doing-- Diffie-Hellmen
exponentiations, probably 3 public key operations (sign, verify peer's cert,
verify peer's signature), etc-- it's noise.
You're not the only person writing code for an embedded system that has
to run on a variety of platforms each with differing memory and speed
constraints. You're just the only one who can't seem to stop whining about it.
> 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.
I've been hearing that you have these simple, implementor-friendly changes for
about the last 8 months. This one is quite pointless, trivial, and unnecessary
and even though you said please I can't wait forever to hear the rest: it's
too late.
For those of you who are wondering, the I-O resolution document will be
finished in the next day or two. I have a few editorial changes to make.
Just for the record, one of the things I've been waiting on was a simple,
generic CBC-MAC paper that a certain vocal I-O resolution document critic
had promised to write so I could reference it. Alas, it never materialized
and we'll just have to live without it.
Dan.
Follow-Ups:
References: