[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20080204203444.GA14021@openwall.com>
Date: Mon, 4 Feb 2008 23:34:44 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: faster hash file loading
On Mon, Feb 04, 2008 at 07:35:38PM +0000, helleye wrote:
> with this change managed to load 95mb file in 17 seconds
This sounds about right, but it should not require the change.
> instead of in 10min + (was lazy to let it finished loading)
That's really weird. Must be a hash type supported with a crappy patch
that doesn't bother to supply working binary_hash[]() functions. If so,
the patch should be fixed because this also affects cracking speed.
Oh, here's another thought: all of my load time benchmarks were for Unix
crypt(3) hashes, which are salted - so a separate hash table was used
for each salt. If your hashes were saltless, then all of them were
sharing one 4096-entry hash table. 95 MB could mean around 1 million of
hashes, so that loop you've removed could actually be doing around 250
iterations on average, which is quite a lot. Maybe JtR should support
even larger hash tables for saltless hashes.
Alexander
--
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.
