Re: MD5 Myths
- From: "John E. Hadstate" <jh113355@xxxxxxxxxxx>
- Date: Sat, 25 Aug 2007 13:37:52 -0400
"JuiceMan" <jaysgeneral@xxxxxxxx> wrote in message
news:1188047121.167747.91470@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
MD5 which I leaned on for support has not
withstood the test of time.
That's an over-broad indictment of MD5. People have found
ways to deliberately create collisions; that is, they have
found ways to create source strings that will hash to a
value that is the same as a given value using less work than
the minimum suggested by its 128-bit size. Whether those
created source strings contain anything meaningful in the
context of a higher layer of application is of little
concern. From the point-of-view of cryptographic strength,
it's unacceptable.
I want to add this has nothing to with
on-line commerce, and this is not part
of my password authentication
So are you saying that you have little concern for
cryptographic strength and are mainly looking for a decent
hash?
I keep track of what the user is doing,
when they last logged in and some other
status indicators in an MD5 digest
This makes absolutely no sense to me. You can't reverse the
hash, so how do you "keep track of what the user is doing"?
As the user navigates through the site
they submit data to me I check it, if I can
figure out what there doing fine, keep going...
Same observation as above. How do you "figure out what
there [sic] doing" when you can't reverse the hash?
Ok so I'm deciding whether to put more trust
in the MD5 digest to do more and/ or redesign
the new application.
What's the maximum loss you could incur by having a user
engineer a string whose value hashes to a value acceptable
to you? If there is no real loss, then there is no real
risk. Also, if there is no real probability that the user
can do that, then there is still no real risk.
I'd like to test some of the truths I've
clung to over the years.
1. For a string of about 80 characters
can MD5 produce a unique digest?
Maybe, depending on restrictions that you might place on the
source string (ASCII characters only, must parse according
to certain rules, etc.) However, as rossum pointed-out, 80
characters is 640 bits, while MD5 is 128 bits so the
possibility of collision is there.
2. In the circles that I run in, I was
told that if I took the classic "abc"
and got a digest, then took that digest
and got a digest for that -- repeated
about 1000 times what I come up is
something that is much better/ more
difficult to crack? (True/ False).
The answers from Kristian and rossum are both correct. The
marginal advantage mentioned by Kristian is explained by
rossum: it will take the attacker longer to engineer a
collision.
Now, what do you mean by "more difficult to crack"?
It sounds to me like you don't really need the security or
strength of a cryptographic hash. In that case, MD5 should
be no problem for your application. If you are really
concerned about engineered collisions, you might consider
changing from a pure MD5 hash to HMAC-MD5. HMAC is an
algorithm for using a secret key with a cryptographic hash.
It is defined in FIPS 198a:
http://csrc.nist.gov/publications/fips/fips198/fips-198a.pdf
or RFC 2104:
http://www.ietf.org/rfc/rfc2104.txt
.
- References:
- MD5 Myths
- From: JuiceMan
- MD5 Myths
- Prev by Date: Re: MD5 Myths
- Next by Date: Auto decrypt morse code
- Previous by thread: Re: MD5 Myths
- Next by thread: Re: MD5 Myths
- Index(es):
Relevant Pages
|
|
