Message-ID: <1732661568.37240545.1427260799752.JavaMail.root@larc.usp.br>
Date: Wed, 25 Mar 2015 02:19:59 -0300 (BRT)
From: Marcos Antonio Simplicio Junior <mjunior@...c.usp.br>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Another PHC candidates "mechanical" tests (ROUND2)

----- Mensagem original -----

> De: "Solar Designer" <solar@...nwall.com>
> Para: discussions@...sword-hashing.net
> Enviadas: Quarta-feira, 25 de Março de 2015 1:49:15
> Assunto: Re: [PHC] Another PHC candidates "mechanical" tests (ROUND2)

> On Tue, Mar 24, 2015 at 11:50:44PM +0100, Milan Broz wrote:
> > The updated test report (draft) is here
> >
> > https://github.com/mbroz/PHCtest/blob/master/output/phc_round2.pdf

> Thank you!

> I think you should include more info on your two test platforms. Most
> notably, the specific CPU types and clock rate.

> The charts showing real memory usage and real time vs. the cost
> parameter values might be useful, but it would also be useful to see
> a
> cross-chart of real memory usage vs. real time (with the lowest time
> cost
> setting supported by each scheme) and with growing memory cost
> setting
> (this is how you'd control the real time).

> > - battcrypt, MAKWA, Parallel and yescrypt produces the same output
> > on big-endian system.
> > All other candidates are broken there (probably quite easy fixes
> > possible).

> To other candidate authors: I may provide SSH access to a
> FreeBSD/mips64
> toy machine (64-bit big-endian) that I use for testing. It's just
> like
> this one: http://rtfm.net/FreeBSD/ERL/ Please e-mail me off-list if
> interested.

That is great! We will try to work this out (actually, it has already been done in an independent implementation we are aware of, so probably it will be a matter of copy+paste) 

> > - I added some test case for my intended use (KDF for LUKS) for few
> > functions.

> Lyra2 is surprisingly fast. That's nice. Your table does not give
> exact numbers for candidates meeting your requirements, though -
> maybe
> you can add that (for their lowest supported t_cost)?

Minimum parameters is good, but probably it is also necessary to consider the number of calls to the underlying function as previously suggested by Steve Thomas. After all, in most cases it is not hard at all to raise or reduce the minimum t_cost (if that remains secure against attacks, however, is a totally different history...) 

> As to yescrypt taking 1.3s for 1 GB, I'd say that consuming 1 GB
> isn't a
> goal per se. The goal is attack resistance. Quite possibly yescrypt's
> 6 sequential pwxform rounds (each with two S-box lookups and one
> multiply) per sub-block provide more attack resistance in the time
> factor of the area-time product than Lyra2's higher memory filling
> speed
> does in the area factor (if you measured these two at the same
> running
> time, so with different memory usage).
As a reminder, we also tried to dwell on the "multiplication-hardening" domain by creating a tweaked version of Blake2b that uses multiplications (following the great suggestion by Samuel Neves). The results are in the new version of Lyra2's documentation and also in the code provided, so maybe it would be good to have it independently benchmarked too. Anyhow, as the whole idea of Lyra2 is to allow the user to define their preferred underlying sponge-based algorithm, there may be other good alternatives too: we never know when the user does have a hardware co-processor and, thus, good hardware performance à la Keccak would be preferred... We are currently trying to do hardware benchmarks to analyze that aspect :-) 

> Besides, yescrypt tries not to
> bump into the memory bandwidth prematurely, thereby letting you use
> multiple threads to a greater advantage.
Analysis on that aspect would indeed be very helpfull: in our machines, we were able to test Lyra2 and yescrypt with up to 4 cores without running into too many bandwidth issues, while both started to lose efficiency with 8 cores... Maybe more tests will show the "breakpoint" of each algorithm (but, without any further tweaking, Lyra2 is indeed likely to fill the machine's bandwidth earlier). In that aspect, we are currently working with GPU-based implementations of candidates. If we finish the tests in time, we will try to submit it to the PasswordsCon . 

> If you do not intend to use
> multiple threads and want to maximize the memory filling speed by
> your
> one thread (even if at expense of possibly reducing the attacker's
> area-time product, via the potentially much lower time factor), you
> may
> reduce yescrypt's pwxform round count from 6 to 1 as Bill suggested.
> In
> yescrypt-simd.c, simply delete 5 of the 6 repetitions of
> PWXFORM_ROUND
> in the PWXFORM cpp macro. I got to make this runtime tunable (easy),
> even if just to show that yescrypt is (more) competitive. ;-)

> Thanks again,

> Alexander

Content of type "text/html" skipped

Powered by blists - more mailing lists