Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 03 May 2015 17:45:03 +0200
From: magnum <>
Subject: Re: optimization idea for salted hashes

On 2015-05-03 00:02, Aleksey Cherepanov wrote:
> It is possible to lift some computations from the loop for some salted
> hashes.
> As the base, I consider a loop over all pairs salt + candidate. So if
> a part of code is computed only for salt not depending on candidate
> then it is possible to precompute it once for each salt. Similarly if
> a part of code is computed only for candidate not depending on salt
> then it may be computed once per candidate (it may be easy to
> implement if we have "for each candidate { for each salt { ... }}"
> structure of the loop).
> Is the optimization implemented in john?

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.


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.