Hashing: avoid MD5 and SHA-1; use SHA-2 or Whirlpool
Chip Salzenberg
but MD5 just got its ass kicked!" - with apologies to Private Hudson
It's been known for some time in the crypto world that MD5 is weak, that
there are shortcuts to finding hash collisions. Recently, that weakness
has turned into a full-fledged failure: It is now possible to quickly
and easily craft two very different files with identical MD5 hashes.
MD5 is dead. Don't use it.
Similarly, we should avoid SHA-1 for any permanent purpose, though in
the short term it's not quite dead yet. No one has demonstrated an
ability to create SHA-1 collisions on demand (as far as I've heard,
anyway), but SHA-1 is "a wounded fish in shark-infested waters"[*], and
an MD5-scale failure may be just a matter of time.
So what should we use for hashing? Two good choices I know of:
* The SHA-2 family (including SHA-256 and other variants) is showing no
signs of weakness AFAIK.
* Whirlpool [**] seems strong enough too; Bruce Schneier describes it
as "a good choice".
Ah, crypto is such fun.
[*] http://www.networkworld.com/news/2005/110105-nist-crypto.html
[**] http://paginas.terra.com.br/informatica/paulobarreto/WhirlpoolPage.html
--
Chip Salzenberg <ch...@pobox.com>
Chip Salzenberg
> * The SHA-2 family (including SHA-256 and other variants) is showing no
> signs of weakness AFAIK.
> * Whirlpool [**] seems strong enough too; Bruce Schneier describes it
> as "a good choice".
Not to make a long discussion of this, but there's also:
* RIPEMD160
http://homes.esat.kuleuven.be/~bosselae/ripemd160.html
I'm getting the feeling that the real lesson is that any hash header
system we build will require pluggable hash algorithms, because
anything we pick as strong today may be broken tomorrow (or in ten
years).
--
Chip Salzenberg <ch...@pobox.com>
Brent 'Dax' Royal-Gordon
>> Similarly, we should avoid SHA-1 for any permanent purpose, though in
>> the short term it's not quite dead yet. No one has demonstrated an
>> ability to create SHA-1 collisions on demand (as far as I've heard,
>> anyway), but SHA-1 is "a wounded fish in shark-infested waters"[*], and
>> an MD5-scale failure may be just a matter of time.
My understanding is that the best attack on SHA-1 which can find two
plaintexts with the same hash value in 2^63 operations. (Brute force
for this is 2^80 operations; cryptographers consider 2^64 to be
practical, although it'd still take tremendous resources to attack in
any reasonable time.) The attacker has to control both plaintexts; he
can't use this attack to find a collision for an existing plaintext.
For an example attack, imagine that Parrot has a security scheme in
which extra privileges are granted to code by signing a SHA-1 hash of
the code with a particular key. (Public-key signing is so slow that
hashes are always used with digital signatures.) This attack means
that, in 2^63 operations, an attacker could generate two pieces of
bytecode with the same hash value. If he could get one of them signed
(say, the one that draws pictures of cute kittens on the screen), he
could then attach its signature to the other one (say, the one that
installs a rootkit and sends all your credit cards to Russia).
Note, however, that the attacker needs to control *both* plaintexts.
Finding a collision for bytecode in the standard libraries would still
require a brute-force attack.
Basically, SHA-1 isn't a problem for us yet, but it's looking weak.
> I'm getting the feeling that the real lesson is that any hash header
> system we build will require pluggable hash algorithms, because
> anything we pick as strong today may be broken tomorrow (or in ten
> years).
From what I've read, that was one of the conclusions of NIST's recent
hash workshop. (The other is that cryptographers need to do a lot of
theoretical work on hashing--they don't really know how to design a
strong algorithm yet.)
--
Brent 'Dax' Royal-Gordon <br...@brentdax.com>
Perl and Parrot hacker
Chip Salzenberg
> My understanding is that the best attack on SHA-1 which can find two
> plaintexts with the same hash value in 2^63 operations.
> Basically, SHA-1 isn't a problem for us yet, but it's looking weak.
OK. Thanks for quantifying that, I'd missed the numbers.
> > I'm getting the feeling that the real lesson is that any hash header
> > system we build will require pluggable hash algorithms [...]
>
> From what I've read, that was one of the conclusions of NIST's recent
> hash workshop.
I think we've been reading the same blog. :-)
--
Chip Salzenberg <ch...@pobox.com>