[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOLP8p61+6b-rs0jHB63=1rJ3x_iAkUm2KhjOHp9iuzGauz9Lg@mail.gmail.com>
Date: Tue, 24 Mar 2015 17:06:49 -0700
From: Bill Cox <waywardgeek@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Re: Another PHC candidates "mechanical" tests (ROUND2)
Excellent work! It looks like Lyra2 is deep into usable Scrypt replacement
territory. This is on 2 threads, right? Also, this is with 1 reduced
round, compared to Yescrypt with 6, right?
For a better comparison, can you run Yescrypt also with 2 threads and 1
hash round? This is closer to how I would recommend using it in LUKS
Another plot I would love to see is memory hashed vs runtime.
Thanks,
Bill
On Mar 24, 2015 3:51 PM, "Milan Broz" <gmazyland@...il.com> wrote:
> On 11/10/2014 09:22 AM, Milan Broz wrote:
> > Hi all,
> >
> > I run some simple tests with almost all PHC candidates
> > (plus Catena2 and RIG2 submitted here).
> >
> > Maybe it could be useful, it is in fact it is kind of an independent
> extension
> > what Bill Cox sent here for reviews.
> >
> > The long description with pictures here
> >
> http://htmlpreview.github.io/?https://github.com/mbroz/PHCtest/blob/master/output/index.html
> >
> > Code and raw output is on github https://github.com/mbroz/PHCtest
>
>
> I promised to update libraries to contain new candidates and
> repeated/added some tests...
>
> The updated test report (draft) is here
>
> https://github.com/mbroz/PHCtest/blob/master/output/phc_round2.pdf
>
> The runtime measurement of used memory should be probably compared with
> limits just
> posted here by Steve (but is it seems to fit quite well).
>
> Anyway, in short:
>
> - added separate tests for optimized variants (Argon-AESNI, Lyra2-SSE,
> POMELO-SSE, yescrypt-SSE)
>
> - updated to tweaked versions, added "new" algorithms (Argon2*, Catena*fly)
>
> - no problems with Dieharder run
>
> - a lot of illustrative graphs produced
>
> - battcrypt, MAKWA, Parallel and yescrypt produces the same output on
> big-endian system.
> All other candidates are broken there (probably quite easy fixes
> possible).
>
> - Some candidates need code fixes to be usable in Linux (and with gcc
> compiler in general).
> (Argon/Argon2i is the most problematic. See section 1.3 in document and
> separate patches in git.)
>
> - I added some test case for my intended use (KDF for LUKS) for few
> functions.
>
> Please let me know if it is useful (and correct me if something is wrong
> there or should
> be added).
> (It was intended as appendix in some work about KDF replacement but it can
> extend
> existing tests as well or so ...)
>
> Thanks,
> Milan
>
>
Content of type "text/html" skipped
Powered by blists - more mailing lists