Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 3 May 2015 20:36:23 +0300
From: Solar Designer <>
Subject: Re: optimization idea for salted hashes

On Sun, May 03, 2015 at 05:45:03PM +0200, magnum wrote:
> It's well supported by john's format interface and most formats take 
> advantage of it. It should be reflected in a benchmark:
> $ ../run/john -test -form:dynamic_157
> Benchmarking: dynamic_157 [RIPEMD320(RIPEMD320($s).RIPEMD320($p)) 32/32 
> sph_ripmd]... DONE
> Many salts:	498176 c/s real, 498176 c/s virtual
> Only one salt:	483865 c/s real, 483865 c/s virtual
> For some reason, the "many salts" speed is not a lot higher here. Not 
> sure why.
> $ ../run/john -test -form:dynamic_12
> Benchmarking: dynamic_12 [md5(md5($s).md5($p)) (IPB) 128/128 AVX 4x4]... 
> Many salts:	11294K c/s real, 11294K c/s virtual
> Only one salt:	4434K c/s real, 4434K c/s virtual
> This example shows a better gain.

I'm not convinced these (and other) dynamic formats make use of the
optimization.  For MD5, the "many salts" speed could as well be 3x
higher than what you saw above.  At these high speeds, the difference
between many and one salt that you saw above could be for other reasons.
Both speeds look bad to me.

I don't understand the dynamics format code well.  I think no one but
Jim does.  dynamic_preloads.c has simply:

//dynamic_12 --> md5(md5($s).md5($p))
static DYNAMIC_primitive_funcp _Funcs_12[] =
	//MGF_FLAT_BUFFERS  MUCH faster using flat buffers

and I don't see how that list of functions implements the claimed format
with its 3 MD5's.  I did successfully implemented a few dynamic formats
in john.conf, but those definitions in dynamic_preloads.c puzzle me.


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.