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

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


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