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://126.96.36.199/~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
Powered by Openwall GNU/*/Linux - Powered by OpenVZ