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

Re: Unnecessarily bloated IV calculation

Marcus Leech writes:
> > 
> > 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.

However, if you were designing IP today, would you design it around hash
codes or around a simple checksum?  My point (though I seem to have
failed in making it very eloquently) was that a hash code or checksum
would provide essentially the equivalent functionality.  Why add the
additional processing requirement when it is not needed?

Instead of arguing against a pedantic and cooked example, perhaps you
could describe to me the reason that the hash gives us more
functionality than the simple XOR I suggested.  It certainly takes more
procesing power.  Yes, we do have more processor to spare than they did
in the 1970s, and yes, key negotiation doesn't happen that frequently.
However, that is not justification for making the protocol more
complicated.  I guess I still hold onto the philosophy of "Keep It
Simple, Stupid".  (No offense is intended for anyone here -- I just
don't know a more effective way to express the same concept.)

> 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 :-)

I'm willing to pay for them during per-packet processing because it is
necessary to have a cryptographically strong hash for that purpose.
However, I'm not willing to do extra computation _anywhere_ unless I get
something in return for it.  Can anyone describe to me what we get in
return for the extra hash computation?


ben
References: