On Thu, 23 Dec 2010, Bob Proulx wrote:
mouss wrote:
John Hardin a ?crit :
Just out of curiosity, why? An MD5 hash is shorter than an SHA hash
(an important consideration when you're making lots of DNS queries of
the hash), MD5 is computationally lighter than SHA, and MD5 is robust
enough for this purpose, even though artificial collision scenarios
exist.
because it's good to abandon weak algorithms, once for all. the small
wanna be performance benefit that you might find is useless.
But the logical conclusion of that argument is that all hashes are
insecure and none should ever be used. Because even though SHA is
considered secure today the expected trend is that it will also fall to
attacks in the future and be replaced by something heavier.
we keep seeing people using weak stuff because "it's enough" and "it's
faster/lighter/..." with the results that you know.
And there is a reason for that. Right-sizing is also important. It
isn't good to use a large construction bulldozer when a single shovel
is all that is needed. If MD5 is the optimal size then it is the
right size to use regardless of vulnerabilities when used in a
security critical role.
One of my core points was this _isn't_ a security-critical role. I hope
you mistyped there, Bob.
MD5 is a well-known commonly-available computationally
relatively-inexpensive (near-)perfect hashing algorithm that allows us to
generate a fixed-length hash string that is DNS-friendly from an email
address that is of any length and contains any characters, including
characters such as periods that are _not_ DNS-friendly.
The rarity of collisions and the low (effectively nil) value of the target
mean that MD5 is still (IMHO) suitable for _this application_, and its
computational burden and hash size make it more attractive than SHA.
Quantifying _how much_ more attractive is a topic for discussion. The size
of IPv6 DNS queries is a good argument that the size of the hash isn't a
compelling factor, but I suggest that the brokenness of the MD5 algorithm
_isn't_ a good argument against MD5 _in this application_. So we're left
with relative computational burden.
if you're worried about performace, don't hash at all. would you use a
cesar/base64/... ? either you need security and you use an algorithm
that's not considered broken, or you don't.
Security in this context is a red herring. The most security desired for
this application is obfuscation to keep private email addresses from being
trivially recovered from third-party DNS server queries or logs of public
network traffic.
Simply base64-encoding the email address would make it DNS friendly, but
wouldn't hinder recovery.
You have hit the problem exactly. If we follow the line of logic you
have presented then we can never hash. Because there isn't ever going
to be a hash that doesn't ever have collisions.
To digress, I would suggest the solution to that (and what I wish PGP had
implemented from day one) is to sign using two different cryptographic
hash algorithms (e.g. MD5 _and_ SHA1). It's extremely unlikely that two
different hash algorithms would have the same collision failure mode -
i.e. it would be effectively impossible to generate a single plaintext
that would generate the desired hashes for _both_ algorithms.
Granted I wouldn't sign a legal document with it any more, but for a
private perfect hash of an email address, why not?
it's weak. don't use it anymore. we have many "secure" alternatives,
why go for "bugward compatibility"?
Until SHA falls too.
Again, in this application I argue that a truly secure (at least for the
moment) hash algorithm isn't critical. Other factors are more important.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhar...@impsec.org FALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
"Bother," said Pooh as he struggled with /etc/sendmail.cf, "it never
does quite what I want. I wish Christopher Robin was here."
-- Peter da Silva in a.s.r
-----------------------------------------------------------------------
2 days until Christmas
