Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150818214116.GA12513@openwall.com>
Date: Wed, 19 Aug 2015 00:41:16 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Long duration formats' many-salts figure incorrect in short benchmarks (was: 7z's KDF is unsalted)

On Tue, Aug 18, 2015 at 11:31:52PM +0200, magnum wrote:
> [...] the benchmark timer ends before we even get to try the second 
> salt even once!
[...]
> Longer runs show better figures (within limits). This problem is with 
> "your code", but it never surfaces in non-Jumbo. I'm not sure whether to 
> fix this, or how. Should we simply ensure the while loop runs long 
> enough for both salts to be tested at least once? Maybe that would end 
> up showing a mere 2x boost in this case? Should we ensure the loop does 
> all BENCHMARK_MANY virtual salts? But that would likely end up in some 
> GPU formats benchmarking for hours...

Yes, there's this problem with no obviously correct solution.  Testing
every salt at least once makes sense to me because we've already done so
during the self-test.  This might increase the test+benchmark time by
more than a factor of 2, though, since the self-tests run up to a lower
crypt_all() count argument for most of its invocations.  But it
shouldn't be worse than 4x overall.  What's worse is that, as you
correctly point out, this might not achieve the full BENCHMARK_MANY
speed, requiring the user to manually increase the benchmark duration to
see that.

> BTW this also boosts the CPU format figure:
> 
> $ ../run/john -test=4 -form:7z
> Will run 8 OpenMP threads
> Benchmarking: 7z, 7-Zip (512K iterations) [SHA256 AES 32/64]... (8xOMP) DONE
> Speed for cost 1 (iteration count) of 524288
> Many salts:	9606 c/s real, 1356 c/s virtual
> Only one salt:	41.7 c/s real, 5.4 c/s virtual
> 
> A four second test yields a 219x boost instead of the original 187x. 
> (BTW I see now I recalled incorrectly; BENCHMARK_MANY isn't 500 but 256, 
> so the theoretical max boost is < 256x in this situation).

Right.

Alexander

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.