Subject: RE: DIGEST-MD5: Family of mechanisms?

From: "Paul Leach" <[email-masked]>
Date: Thu, 29 Mar 2001 12:51:47 -0800

Well, it's conceptually not hard, but:
1. The spec explicitly expects the length of the hash to be 128 bits in
many places, such as the definitions of H, KD, HEX
2. The key derivation explicitly uses MD5, not H or KD.
3. The key derivation only gets you 128 bits of keying material; it's
silly to use AES with that small a key. And that's why the 3DES is 2 key
3DES in the spec, for example.
4. The block size of the cipher is explicitly called out in the privacy
protection section

Also, if we add these, there will not exist two interopable
implementations; won't that guarantee a recycle?

Finally, if I were doing such an addition, I'd use PKCS#5 as part of the
derivation of the key (A1) from the password. It can generate arbitrary
length keys, and it is designed to take a long time (e.g., 100 ms, but
tunable) on the client, making attacks on challenge/response pairs much
harder. (The server can precompute, so it doesn't get loaded.)

As a result of all that, I'd be inclined to do this as "DigestV2".

> -----Original Message-----
> From: Alexey Melnikov [mailto:[email-masked]] 
> Sent: Wednesday, March 28, 2001 7:43 PM
> To: Kurt D. Zeilenga
> Cc: Keith Burdis; [email-masked]
> Subject: Re: DIGEST-MD5: Family of mechanisms?
> 
> 
> "Kurt D. Zeilenga" wrote:
> 
> > At 05:58 PM 3/27/01 +0200, Keith Burdis wrote:
> > >One possible change to the Digest-MD5 specification could 
> be to make 
> > >it specify a family of mechanism, each using a different one-way 
> > >function. This would mean that the same mechanism could be 
> used with 
> > >new and existing one-way functions, and would minimise the 
> problems 
> > >caused by a weakness being found in any particular one-way 
> function.
> > >
> > >This specification would still be upwardly compatible with 
> the HTTP 
> > >\"md5-sess\" algorithm, since Digest-MD5 would be the same 
> as before.
> > >
> > >Does anyone think that such a change would be useful?
> 
> I support the idea.
> 
> > What are
> > >the potential drawbacks of this change?
> >
> > We just need to be careful not to cause DIGEST-MD5 to unnecessarily 
> > recycle at Proposed.
> >
> > I did chat with JeffS and he thought we likely can add AES as an 
> > alternative cipher without recycling.  We might be able to 
> add SHA1, 
> > or at least the framework for additional hash functions, without 
> > recycling at Proposed.
> 
> I believe you are right. Section 1.1 of the RFC 2831 says:
> 
> >1.1  Conventions and Notation
> >
> [skipped]
> >   Let H(s) be the 16 octet MD5 hash [RFC 1321] of the octet 
> string s.
> 
> This seems like an intention of the authors to be able to use 
> different hashing algorithms.
> 
> Alexey
> 
> 
>