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

Re: SHA + generic auth specs? (was Re: AH-MD5)




Yikes!

The goal is INTEROPERABILITY.  Please don't define a zillion
alternatives just out of some desire to document all the suggestions
that come along.

I don't think it makes that much difference whether we use MD5 or SHA.
I personally favor SHA, but MD5 is what has always been "decided" at
the WG meetings at the IETF meetings and is the Internet standard.

We need documents to progress to a reasonable proposed standard.  I'd
be happy to do this with documents with either MD5 or SHA.  I don't
think everyone should have to implement both.

Donald

From:  "Perry E. Metzger" <perry@imsi.com>
To:  ipsec@ans.net
Cc:  bsimpson@morningstar.com, smb@research.att.com
In-Reply-To:  Your message of "Sat, 28 Jan 1995 17:51:43 EST."
	                  <199501282254.AA04430@interlock.ans.net> 
Reply-To:  perry@imsi.com
X-Reposting-Policy:  redistribute only with permission
>
>***NOTE***: serious question for thought at the end of this document!
>If you skip it, don't be suprised if you see something odd in upcoming
>documents!
>
>smb@research.att.com says:
>> If we're shooting for the long run, we need SHA.
>> 
>> SHA (and for that matter Skipjack) were designed to meet a stated
>> a priori requirement of 80 bits of strength.  That number seems reasonable
>> to me, given the historic hardware speed-doubling time.  There's already
>> been progress at brute-force cracking of MD5; see the paper by Wiener
>> and someone else at the November '94 Fairfax conference.
>
>There have also been some partial attacks made against MD5 by Bert den
>Boer and Antoon Bosselaers -- not really practical attacks, but SHA
>doesn't suffer from the same problem.
>
>> (On the other hand, one could argue that there's no point in our
>> authentication function being much stronger than our cryptosystem...)
>
>The 3DES document is done; 3DES with independent keys is thought to
>have about 112 bits of strength. (Note that because of clever attacks
>it doesn't actually have 168 bits of strength, but two independent
>keys systems have no more than 108 bits of strength so it is probably
>worth having three keys -- anyone who disagrees should speak up now!)
>
>I'll happily cooperate with people in drafting their documents for
>their favorite systems (IDEA comes to mind).
>
>INTERESTING BIT COMES HERE:
>
>Now on another serious note, I've discovered an opportunity for a
>design fix in the way I'm doing combined crypto+auth under the
>ESP.
>
>Mostly, the auth systems are based on hashes and are orthogonal to the
>cipher systems. However, we don't want to use the AH combined with a
>cipher-only ESP for combined privacy and auth because it wastes too
>much space and causes two passes through the section of the kernel
>dealing with the crypto (which costs!). (We allow people to combine
>them, but we don't want to force people to do things that way).
>
>We (meaning I) were thus going to do combined cipher+hash ESP
>documents for those wanting both, like DES-CBC+MD5. However, as I sit
>down to write those documents, it has occured to me that I'm about to
>write the DES+MD5, 3DES+MD5, IDEA+MD5, DES+SHA, etc, etc, documents,
>on ad infinitum, with the number of documents approaching
>#ciphers times #hashes -- not a good thing, especially since the
>ciphers and hashes don't interact terribly much in these documents.
>
>I'd like to know if people think its okay if we specify a generic any
>cipher+MD5 ESP and a generic any cipher+SHA ESP. Were I to do that, it
>would reduce to two the number of outstanding transform documents I'd
>have to write and would mean that any newly defined cipher document
>would automatically have an authenticated version, and that any new
>MAC or hash would automatically work across all ciphers. This would,
>however, complicate key negotiation and the like.
>
>Perry


Follow-Ups: References: