Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.