Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 4 Feb 2008 23:34:44 +0300
From: Solar Designer <>
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.


To unsubscribe, e-mail 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.