[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 12 Apr 2012 16:04:05 -0500
From: "jfoug" <jfoug@....net>
To: <john-users@...ts.openwall.com>
Subject: RE: JTR against 135 millions MD5 hashes
Should likely burn though 1/2 (or more) of candidates in quick order. The
largest amount of time, will be in the fileIO trying to crack it, load it
multiple times, and then stripping out the already found items.
It might even take a binary type 'reduction'. Cut into 4 parts. Run,
strip, merge. Cut into 2 parts, run strip merge, and then be able to run it
'comfortably' on a single instance. If you can run 1/4 of the candidates,
then you would have to remove 75% of them, before being able to run all of
them (all left), at one time.
Also, in doing this, I am pretty sure one would want to hand strip off the
found items, and NOT have those 75% found located in the running john.pot
file.
That IS a big list though. It certainly is pushing JtR in ways that are
beyond what people have been doing up to this point.
Jim.
>From: Simon Marechal [mailto:simon@...quise.net]
>
>Le 12/04/2012 19:40, websiteaccess@...il.com a écrit :
>> After 20 minutes, JTR begin to crack MD5, but it very very slow, in
>fact JTR seems frozen, I can hear the hard drive running and running.
>> JTR display also -> "excessive partial hash collisions detected"
>
>It swaps on my 16Gb desktop. The only sane way to tackle this on a
>standard computer is to break it into pieces (look at the split
>command), crack a large part of it, and try to fit what is left in a
>single process.
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.
