[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091101221412.GA26765@openwall.com>
Date: Mon, 2 Nov 2009 01:14:12 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: JTR 1.7.3.4 with patches V2 - dict limits.
> On Sun, 1 Nov 2009 22:39:59 +0300, Solar Designer wrote:
> > This is the expected behavior for a 32-bit build of JtR when a wordlist
> > exceeds 2 GB in size. You need a 64-bit build for wordlists this large.
[...]
On Sun, Nov 01, 2009 at 10:03:57PM +0100, websiteaccess wrote:
> JTR (raw-md5) compiled with macos X 64 is 2 times slower than macos X
> sse2
Yes, you have to make this unfortunate choice - either better c/s rate
at raw MD5 or extra-large wordlists, not both at once. This is just the
current state of these unofficial/development patches. It is great that
those patches do exist (thanks, Jim and all!), and it is great that
you're testing them (thanks, W.A.!), but we can't be "demanding" "too
much" right away.
What if you didn't know that the 2x better c/s rate was even possible on
your machine? Would you be happier? I'd guess so. ;-)
Do you really need wordlists this large? I seriously doubt it. There
are some valid uses for extra-large wordlists, but much more often
they're just misused (better results could be achieved differently).
If I were you, I wouldn't bother with pre-mangled wordlists for very
fast saltless hashes such as raw MD5. I see no reason for this
combination. You just incur more overhead by having the system read
those wordlists from disk, lowering your c/s rate. You could have
achieved better results by letting JtR mangle a smaller wordlist on the
fly, even if that would result in a certain small percentage of
duplicates.
In case you're possibly having JtR apply its rules twice (saving the
output to a file via "unique" the first time), then this does make some
sense to me, but you'd probably want to keep this intermediary
one-time-pre-mangled wordlist not too large (under 2 GB) for reasons
unrelated to the limitation we're discussing here.
That said, the software could definitely use some improvement - better
raw MD5 code for 64-bit builds and/or support for Large Files in 32-bit
builds. There are lots of other possible improvements to make as well.
Alexander
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.
