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

Re: AH-MD5

-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MIC-CLEAR
Content-Domain: RFC822
Originator-Certificate:
 MIIBwDCCAWoCEQC43J7oZ50NWTRSVBShvvaXMA0GCSqGSIb3DQEBAgUAMFkxCzAJ
 BgNVBAYTAlVTMRgwFgYDVQQKEw9TZWN1cmVXYXJlIEluYy4xFzAVBgNVBAsTDlNl
 Y3VyZVdhcmUgUENBMRcwFQYDVQQLEw5FbmdpbmVlcmluZyBDQTAeFw05NDA0MDUx
 NzA2NDJaFw05NTA0MDUxNzA2NDJaMHAxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9T
 ZWN1cmVXYXJlIEluYy4xFzAVBgNVBAsTDlNlY3VyZVdhcmUgUENBMRcwFQYDVQQL
 Ew5FbmdpbmVlcmluZyBDQTEVMBMGA1UEAxMMQ2hhcmxlcyBXYXR0MFkwCgYEVQgB
 AQICAgQDSwAwSAJBDNmUqe2+nqg6iuUWzxaXegxki426RzmVNO6VHHYCV4nbo/WL
 X9a7Jn/2nWqZUK/l+RXqCHU/21Ur9jFIt4GNHhcCAwEAATANBgkqhkiG9w0BAQIF
 AANBAEY6kP5jHqK9B9PhZCCJ9mckYuKMufWr7l61LulXGwUTqFzjFC0MOYwXo5s+
 8lqrLQ7YpTzyE74pKR1cl5TAUU4=
MIC-Info: RSA-MD5,RSA,
 C6DHhVltQjFW7sG1nvHjifiXpZcSTB9vKtxUtYOhhNvffZ+YII7PpV2HKqEBUZxE
 ZH7duzPNfYcHVrg9BVtGNXE=

X-Sensitivity-Label: 1,CMW+3.0/SCO_2.1/sware.com,UNCLASSIFIED
X-Information-Label: 1,CMW+3.0/SCO_2.1/sware.com,UNCLASSIFIED

Colin Plumb writes:

> 
> I just figured out the attack on prepend-only MD5.
> Thanks to Perry Metzger for indirectly pointing it out to me.
> 
> If I hash "abcd", MD5Transform is invoked once, on the 16 words:
> 
>  'abcd'  80000000 00000000 00000000 00000000 00000000 00000000 00000000
> 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000020
> 
> The trailing "20" is the message length in bits (32 bits).
> If I have the hash of this, I can compose a message which begins
> with this information, then adds another block with additional data,
> and compute the hash on the larger message by adding the appropriate
> padding and (revised) bit count, and call MD5Transform to convert the
> original hash to the hash of the revised message.  I can do this even
> if I don't know the "ab" authenticator part of the message, but the
> recipient who's going to "verify" theh hash does.
> 
> In light of this, appending seems safer.
> 

I must admit that I do not understand this debate and side with Perry.
What is this purpose of this group?  I understood it to be the design of
a layer 3 security protocol for IP v4.  Well,

1) The purpose of any layer 3 security protocol is to protect layer 3
   PDUs including the security critical header information such as
   addresses.  Well, the PDU length is security critical information.

2) For all layer 3 protocols that I have seen:

	- the header includes the PDU length,
	- the header comes before the payload so that the PDU can be parsed.
	- the length field is contained within a known fixed length initial
	  portion of the header.

This meets all of the requirements for authentication using a hashing function
and a prepended key.  There is no need for an appended length, for as Colin
points out it is worthless.  There is no need for an appended key, it only
adds an extra MD5 cycle per packet.

True, if this approach is later used for some other layer 3 protocol and the
length is not included within a initial known length segment, it is open for
append attacks.  But what is a layer 3 protocol without the PDU length?  Talk 
about poor software engineering practices.  What is a layer 3 security 
protocol that does not include the PDU header (or selected components of it)?  
Insecure.

The only comment that I have heard that is really relevent to the security
of this approach are the rumors of some progress towards breaking MD5.  Does
anyone have real information on this?

Charles Watt
SecureWare, Inc.
-----END PRIVACY-ENHANCED MESSAGE-----
References: