Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 09 Jun 1996 09:03:47 -0700
From:      Jim Binkley <jrb@cs.pdx.edu>
To:        Steve Reid <root@edmweb.com>
Cc:        freebsd-security@FreeBSD.org
Subject:   Re: MD5 broken 
Message-ID:  <199606091603.JAA29242@sirius.cs.pdx.edu>
In-Reply-To: Your message of "Fri, 07 Jun 1996 17:05:25 PDT." <Pine.BSF.3.91.960607162222.175E-100000@bitbucket.edmweb.com> 

next in thread | previous in thread | raw e-mail | index | archive | help

I'm afraid I'm going to muddy the waters a bit...

I have been following the IETF IPSEC (Ip layer security) group for a
long time (seems like a long time...).  E.g., see RFCS 1825-1829.
IPSEC has designed two headers for security, AH (authentication) and
ESP (encryption/privacy), with the assumption that these headers would
be used in ipv4 and ipv6.  "Transforms" (i.e., specific algorithms for
specific crypto algorithms more or less) for the headers have been
defined too; e.g., for ESP the transform is *changing* from DES-CBC to
an authenticated version of DES-CBC.  With AH, the transform *was*
keyed MD5 (see RFC1828.txt).  IPSEC has decided that keyed MD5 needs to
be retired, primarily because of paranoia over the attacks described.
There are going to be two required replacements, hmac-md5,
and hmac-sha.  hmac-md5 and hmac-sha could loosely be described as
tougher versions of keyed-md5.

If you want to look at the drafts for said transforms,
visit an Internet ftp site (e.g., ftp://ftp.isi.edu/internet-drafts)
and look at:
draft-ietf-ipsec-ah-hmac-sha-00.txt
draft-ietf-ipsec-ah-hmac-md5-00.txt

The above is just fyi on the situation.  Now for an opinion.  I agree
with Poul-Henning Kemp.  The situation isn't that serious at the moment.  
IPSEC has several kinds of people in it at least, cryptographers (not me), 
security types, and network engineers (i'll accept that).  Crypto people are 
paranoid by definition and IPSEC has to worry about both ipv4 and v6
long-term.  On the other hand, it may be itime to start thinking about a 
replacement.  Over time, all crypto algorithms will have to get stronger 
as computers get more powerful.

				regards,

				Jim Binkley
				jrb@cs.pdx.edu
				psu cs dept.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606091603.JAA29242>