[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070615175759.GA4583@openwall.com>
Date: Fri, 15 Jun 2007 21:57:59 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: a faster md5 brute force algorithm ?
On Fri, Jun 15, 2007 at 06:07:33PM +0200, Slythers Bro wrote:
> hi i'm the author of fuckmd5.cpp
> http://packetstormsecurity.org/Crackers/fuckmd5.cpp
> it use one shortcut (just a SAT) for win 1/3 times of a full brute forcing
This is quite impressive. Too bad it didn't get the attention it
deserves on full-disclosure:
http://lists.openwall.net/full-disclosure/2007/01/05/11
http://lists.openwall.net/full-disclosure/2006/08/23/6
Also relevant is:
http://81.57.125.106/~slythers/qbyte%20and%20md5%20recomputation.rar
(I am posting these URLs for other john-users subscribers who might be
curious.)
I think that you should write a paper on the general approach and its
application to MD5. A real paper; your "MD5 recomputation.doc" with a
bit of French and some screenshots is not it. ;-)
> maybe we could implement the algorithm (or a variant) in john the ripper if
> you are interested
I'm afraid that it doesn't fit JtR well because of the order in which
candidate passwords are tried. JtR tries candidates that are considered
more probable first, whereas in your algorithm the order of candidates
for each given length is dictated by the algorithm, and the charset has
to be pre-defined.
Do you think the algorithm can be modified for trying candidate
passwords in arbitrary order?
Also, when cracking multiple hashes in parallel and when doing multiple
hash computations in parallel (for greater instruction-level parallelism
and to make use of vector instructions), the rate of false positives
will be higher, so the performance win will be less. But it's not a
practical problem for most uses of JtR as the number of hashes loaded
for cracking times the number of hashes computed in parallel will have
to be really high in order for the slowdown to become significant. At
such high numbers, hash table lookups would be taking a significant time
as well.
For others reading this: all of this applies to cracking raw MD5 and
maybe also other non-iterated MD5-based hashes, but not the MD5-based
crypt(3) hashes that JtR supports now. There's no point in avoiding 1/3
of computation of the last of 1000+ MD5 computations needed for those
hashes. (Raw MD5 support is available in contributed patches only.)
> i tried to contact the author of mdcrack but no answer from him
This would definitely fit MDCrack better.
Thanks,
--
Alexander Peslyak <solar at openwall.com>
GPG key ID: 5B341F15 fp: B3FB 63F4 D7A3 BCCC 6F6E FC55 A2FC 027C 5B34 1F15
http://www.openwall.com - bringing security into open computing environments
--
To unsubscribe, e-mail john-users-unsubscribe@...ts.openwall.com and reply
to the automated confirmation request that will be sent to you.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
