[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <33be71413c6a6b350c49d211c70b5102@smtp.hushmail.com>
Date: Sun, 26 Jul 2015 22:17:43 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: PHC: Lyra2 vs yescrypt benchmarks 2
On 2015-07-26 15:40, Solar Designer wrote:
> On Sun, Jul 26, 2015 at 03:15:43PM +0200, Agnieszka Bielec wrote:
>> these speeds returned by auto-tuning seems be the same to these
>> returned by modified bench.c (for slow hashes, my bench.c uses rand
>> which makes a difference at cracking faster hashes, I saw the
>> difference at 150k/s)
>
> I think your modified bench.c should be committed to your tree anyway.
> Ideally, you'd have it skip the modifications when they are not needed
> or when they are harmful. e.g. you may introduce a new format flag, say
> call it FMT_RANDOM, and check for it in your formats that need it for
> proper benchmarking.
FWIW we already have a feature in Jumbo where (IIRC) a BENCHMARK_LENGTH
of eg. 1000 means actual benchmark 0 and scrambled passwords. It was
added for formats that can reject early during crypt_all() so benchmark
speeds doesn't get deflated from using test vectors for benchmarking
(they would otherwise always take the slow path).
I think it currently just xor's first character with something - maybe
Agnieszka could replace that with her code, and we'd use it in Jumbo.
The current code has a twist: It un-scrambles the test vectors
afterwards. I'm not sure that's needed.
magnum
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.
