john-users - Re: faster hash file loading

Openwall Project		/home Owl JtR Pro crypt pam_passwdqc tcb phpass scanlogd popa3d msulogin / Linux BIND / advisories presentations / services donations / wordlists passwords / community lists wiki CVSweb mirrors signatures
bringing security into open environments

Order Openwall GNU/*/Linux 2.0 on a CD with delivery worldwide

[<prev] [next>] [<thread-prev] [month] [year] [list]

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.