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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to
"[EMAIL PROTECTED]"
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
