Re: [Content-MD5 and Message Digest Authentication.], MD5 broken.

Roy writes

>The obvious way to handle a new digest algorithm like SHA is
>
>   Content-SHA: 2A1238912371239587
>
>which is exactly how the HTTP protocol is designed.  Leave it be.

This means that each time the digest algorithm has to be changed 
we should issue an RFC for a new version of HTTP. It would be nicer
to be able to simply add an entry in the IANA registry.

I disagree with Roy, I know of no other tag where the algorithm is 
embedded. We do not have Content-Text-HTML, we dont have 
Content-GZIPPED. I think that HTTP is designed in exactly the 
opposite manner. 

One of the reasons why protocol specifications should not have 
dependencies on the security on particular algorithms is that 
it means that if the algorithm is compromised a few days before
its due to be published it is not necessary to consider late
changes.

For the sake of getting the spec out the door, I'll agree with Roy 
provided he agrees not to object to my proposals for Content-SHA,
Content-RIPEMD and Content-MD6.



Paul writes:

>Digest Auth already has the algorithm as a parameter. The name
>"Content-MD5" can't be changed for historical reasons.


The problem with digest auth that I hadn't anticipated is that as presently 
stated the spec means that if you change the keyed digest algorithm you also 
need to exchange a separate shared secert.

This is bad practice cryptographically, (mea culpa). The shared secret 
generation step uses only the one way property of MD5. The authentication 
function uses the collision resistance funtion and the one-wayness. Its only the 
collision resistance that is compromised, not the one-wayness. Ie refering to 
the spec where we have

Digest = H ( H(A1), nonce, H(a2))

A1 = username : realm : password
a2 = Method : URI

The password file stores H(a1), so it is convenient to use a single digest 
function for all keyed digests ie we have


Digest = SHA ( MD5(A1), nonce, SHA(a2))

Its the SHA(a2) component that is really sensitive.


	Phill

Received on Friday, 26 April 1996 17:18:01 UTC