[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: what I am proposing re HMAC
In message <9603011844.AA42869@hawpub.watson.ibm.com>, you write:
>> Any key negotiation
>> protocols that exist do not replace the meaning of "use the 1828
>> transform" with using HMAC -- they think of HMAC as a new
>> transform. I do not want the new RFC to "supersede" 1828 as a
>> replacement RFC would.
>
>It is a question of what transform will be mandatory and what won't.
>HMAC should be the mandatory one, for several good reasons.
I guess I may be missing something. People are talking as if RFC-1828
is totally worthless and HMAC is the holy grail, yet I'm not seeing any real
data that justifies this conclusion.
We know of no *feasable* attacks on RFC-1828, right? And how long have
cryptographers been playing with envelope MACs? Now, we have this new MAC. It
is probably better. It looks better to us. But it is still new enough that
we don't really know.
Why the mad rush to replace RFC-1828 with HMAC as the mandatory
minimum? First, this obseletes all current implementations. Sure, it's not that
difficult to update this, but that doesn't mean you still don't have to do
the work and then go through testing cycles again. Second, we're moving from a
known to an unknown. How many people have implemented and tested HMAC-based AH?
I don't know of any, though the IBM people probably have.
At the very least, it doesn't seem like a very good idea to change
RFC-1828's status until more people have *implemented* HMAC AH.
-Craig
References: