[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unnecessarily bloated IV calculation

Daniel Harkins writes:
> >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'm not claiming it can't do the additional hash, but claiming only that
it is unnecessary.  Certainly IP could have been written to use the
first 16 bits of an MD5 hash instead of a simple checksum, but it
doesn't because the checksum gives about the same functionality for far
fewer cycles.

> > 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.

Pardon.  I was hoping everyone on this list would be able to draw their
own conclusions, or at least ask if it weren't clear.  How about an XOR
of the cookies.  Repeated (perhaps with bitwise NOT's) if necessary to
generate a longer IV.  Will you pass on this quite so simply?

> 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. 

Noise tends to add up.  Especially in the case of ISAKMP/Oakley.  I
don't know how many of these sorts of things I've seen, but figured it
would be helpful to test the waters with one of the more glaring
problems.

Moreover, unless you can say with certainty you know the optimizations
_every_ implementor might make with respect to certain costly operations
(DH, RSA, DSS, etc.), the above statement is logically flawed.  I can
certainly think of real-world scenarios where the single hash
calculation I mentioned would be more expensive than the DH and PK
operations combined.  For example, on many CPUs, it might be impossible
to do the DH calculations in reasonable time, requiring a bignum
co-processor for the box to support Key Exchange at all.  Since RSA is
also bignum based, this can also be offloaded.  However, the processor
is sufficient to handle the crypto requirements of IPsec and ISAKMP
other than the ones I've already mentioned.  In this case, an
unnecessary HASH calculation isn't as trivial as you might think.

[Personal attacks deleted]

Dan,

It was my intention to only pose the question of why we were doing a
completely unnecessary calculation.  I didn't intend to make any
statements about either your document or your person.  I realize that
your position is an extremely difficult one to be in.  However, you
don't need to make it more difficult by taking personal offense from
innocent questions and/or starting unnecessary flame wars.


ben
Follow-Ups: References: