Security team successfully cracks SSL using 200 PS3's and MD5 flaw.

Sun Jan 4 20:38:35 UTC 2009

> Date: Sun, 04 Jan 2009 09:22:06 +0200
> From: Hank Nussbacher <hank at efes.iucc.ac.il>
> 
> At 06:44 PM 03-01-09 +0100, Mikael Abrahamsson wrote:
> >On Sat, 3 Jan 2009, Hank Nussbacher wrote:
> >
> >>You mean like for BGP neighbors?  Wanna suggest an alternative? :-)
> >
> >Well, most likely MD5 is better than the alterantive today which is to run 
> >no authentication/encryption at all.
> >
> >But we should push whoever is developing these standards to go for SHA-1 
> >or equivalent instead of MD5 in the longer term.
> 
> Who is working on this?  I don't find anything here:
> http://www.ietf.org/html.charters/idr-charter.html
> 
> All I can find is:
> http://www.ietf.org/rfc/rfc2385.txt
> http://www.ietf.org/rfc/rfc3562.txt
> http://www.ietf.org/rfc/rfc4278.txt
> 
> Nothing on replacing MD5 for BGP.

I don't see why this is an issue (today). As far as I understand it, the
vulnerability in MD5 is that, with time and cycles, it is possible to
create a collision where two files have the same MD5 hash, so the
counterfeit cert would check as valid. For the MD5 signature on a TCP
packet, this is not relevant.

Am I missing something? (I will admit to not being a cryptography person, so I
may totally misunderstand.)

I don't object to moving to a stronger hash, but, considering the
expense and time involved, I'd suggest waiting for the new hash
algorithm that the NIST challenge will hopefully provide.

In other words, stick to MD5 in places where it is not believed to be
vulnerable and where converting to SHA-1 or SHA-256 would be expensive.
Where it IS believed vulnerable, the cost/benefit ratio would have to
determine when the conversion is justified. For X.509 certs, I believe
the answer is clearly that it is justified and has been for at least 2
years. 
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 224 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20090104/0c9e1be6/attachment.sig>