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

Re: Unnecessarily bloated IV calculation

> 
> 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.
>
To be annoyingly pedantic, your example is cooked.  IP has been around for
  rather longer than cryptographic hash functions have been widely deployed
  and understood, and it was designed to run fast on hardware of 1970s vintage.
  I doubt that IPSEC would have been considered as feasible at all in the
  environment that IP germinated in.
 
> 
> 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.
> 
Let's take a look at it another way.  You'd like to save a couple of MD5 calculations
  during key negotiation, but are willing to pay for them during per-packet processing.
  Even if you change keys every 100 packets, your extra MD5 in the key negotiation
  isn't going to matter very much.  I'm certainly unwilling to have a system in which
  key agreeement is blindingly fast, and per-packet processing is horribly slow, so I
  propose that we drop both MD5 and anything more sophisticated than ROT13, in the
  interest of saving underprivileged CPUs from having to work up too much of a sweat :-)
Follow-Ups: References: