[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Unnecessarily bloated IV calculation
This is utterly ridiculous! IPSec is done, well-done in my opinion.
1] I'd like to release IPSec products.
2] My customers want me to release IPSec products.
3] The market wants me (and you) to release IPSec products.
What the hell are we trying to do at this late stage anyways? And why
are we arguing about something that takes less than 1% of the exchange
time. Gee, why don't we get rid of DH since it takes way too long to
generate secret keys? ;-)
Let's close off IPSec and if we want to add or modify anything, then
lets do it in IPSecond.
>-----Original Message-----
>From: Ben Rogers [SMTP:ben@Ascend.COM]
>Sent: Tuesday, February 10, 1998 10:11 AM
>To: Marcus Leech
>Cc: ipsec@tis.com
>Subject: 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
>