From owner-freebsd-security@FreeBSD.ORG Mon Dec 3 23:02:16 2007 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03F6216A41B for ; Mon, 3 Dec 2007 23:02:16 +0000 (UTC) (envelope-from Rich@Murphey.org) Received: from whiteoaklabs.com (mail.whiteoaklabs.com [69.55.226.191]) by mx1.freebsd.org (Postfix) with ESMTP id 0465D13C45B for ; Mon, 3 Dec 2007 23:02:15 +0000 (UTC) (envelope-from Rich@Murphey.org) Received: from xa.home.org (c-98-194-157-148.hsd1.tx.comcast.net [98.194.157.148]) by whiteoaklabs.com (8.12.11/8.12.11) with ESMTP id lB3MjECW016206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 3 Dec 2007 14:45:14 -0800 Received: from [172.16.3.2] (inspiron.home.org [172.16.3.2]) by xa.home.org (8.13.6/8.13.6) with ESMTP id lB3MjOHo081283 for ; Mon, 3 Dec 2007 16:45:24 -0600 (CST) (envelope-from Rich@Murphey.org) Message-ID: <475486EA.5080907@Murphey.org> Date: Mon, 03 Dec 2007 16:44:58 -0600 From: Rich Murphey User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: freebsd-security@freebsd.org References: <20071203154412.461d0faf@meijome.net> <47540774.5080805@iang.org> In-Reply-To: <47540774.5080805@iang.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC--Metrics: whiteoaklabs.com 1113; Body=1 Fuz1=1 Fuz2=1 X-Mailman-Approved-At: Mon, 03 Dec 2007 23:05:42 +0000 Subject: Re: MD5 Collisions... X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2007 23:02:16 -0000 Here's a paper by Eric Thompson of AccessData on "MD5 collisions and the impact on computer forensics" published in the journal Digital Investigation. It makes a similar argument that the MD5 collisions have very limited practical impact on current use for evidence authentication in computer forensics. http://www.acquisitiondata.com/white_papers/md5-collisions.pdf Rich Murphey Iang wrote: > Norberto Meijome wrote: >> Hi everyone, >> >> Not sure if you've read >> http://www.win.tue.nl/hashclash/SoftIntCodeSign/ . >> >> should some kind of advisory be sent to advise people not to rely >> solely on MD5 checksums? Maybe an update to the man page is due ? : > > > my 2c worth: > > The attack is somewhat subtle, and doesn't really apply to the use > that is currently made of MD5. > > The attack with MD5 is that if you can create your own text, you can > create 2 texts with the same MD5. That however is very different to > you creating a new text with the same MD5 as my text. It is the > latter that is normal usage. > > In this case, if you are distributing your code with an MD5 signature > so others can check it, it is still not a useful attack. MD5 is still > good for that. > > Having said that, the general warning is more or less correct; move to > a longer hash, if designing new apps. > > However, it gets messier, as you need to chose a replacement: > > * SHA1 is good "for now", but expected to suffer in a few short > years. No point in picking that. > > * SHA256 and friends are also under some sort of skeptical cloud, > although they are likely good for a lot longer (ask 3 cryptographers > for 7 different answers here). While it could be good to pick SHA256, > etc, there isn't that total 100% theoretical pareto-complete > confidence that cryptographers insist on... > > * To address this, NIST just a couple of months back announced a SHA3 > competition. This will in the space of maybe 4-6 years announce a new > generation hash. Can you wait for that? > > There are then a handful of strategies that might help: > > a. switch to SHA256 now, and then SHA3 in 5 years time. > b. limp along on MD5 and plan on SHA3 when it is available. > c. add "hash agility" to all programs and allow apps to follow their > desires. > > Which you follow depends on where you are in the crypto-paranoia curve. > > Unless the app is an actual vector of validated attacks, I'd suggest > b. If you are part of the community and like inflicting crypto > turmoil on your users for fun and pleasure, do c. If you are some big > company and have to answer to others' ideas of compliance, do a. > > > >> " MD5 has not yet (2001-09-03) been broken, but sufficient >> attacks have >> been made that its security is in some doubt. The attacks on >> MD5 are in >> the nature of finding ``collisions'' -- that is, multiple inputs >> which >> hash to the same value; it is still unlikely for an attacker to >> be able >> to determine the exact original input given a hash value. >> " > > > That's fine as a description of the problem. What it lacks is any > advice as to what an application developer should do about it. A > tough issue :) > > iang > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to > "freebsd-security-unsubscribe@freebsd.org" >