phc-discussions - Re: [PHC] Re: Updated tests document (version 2)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAOLP8p5Am14szxONxwRoHvG1cY-GgoCBLw_cTNQfX4iV=Aw4EQ@mail.gmail.com>
Date: Mon, 27 Apr 2015 16:55:33 -0700
From: Bill Cox <waywardgeek@...il.com>
To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: Re: [PHC] Re: Updated tests document (version 2)

On Mon, Apr 27, 2015 at 7:14 AM, Milan Broz <gmazyland@...il.com> wrote:

> I tried to update linetypes, it should be better now for you,
> please check it.
>

Thank you!  These charts are very easy for me to read.  It does look like
there's a grouping of the front-runners in memory hashing speed: Argon2d,
Lyra2, and Yescrypt, with POMELO close behind.  I had trouble seeing that
before.

> (Unfortunately I found only usable color palette for 8 series, so
> here it repeats colors just with different symbols - but is should be
> readable.)
>

I always see repeated colors, so this does not bother me at all :-)

> The other thing is that we're still missing what I feel is the most
> > important charge for your use case: full disk encryption.  There is
> > simply no reaon not to use the multi-core capability of the machine.
> > Most entries do not have a parallelism parameter, but it is an
> > absolutely critical feature for FDE.
>
> yes, but the whole testsuite is based on using PHC() function prototype.
>
> So either we should implement an another common interface for all
> candidates
> or I can run some targeted tests later (on finalists).
>

I see.  It does seem odd to ask the testing volunteer to create his own
interface to the candidates.

I think there are just 3 candidates now supporting multiple threads.  It is
surprisingly hard to guestimate parallel thread performance from parallel
process performance.  The reasons remain mysterious to me, but the short
version is that each thread seems to want sole access to it's own page.
Mixing nearby read/writes between threads thrashes something, maybe the
translation lookaside buffer?

I guess I'd like guidance from the PHC panel on this issue, if they want to
see multi-threaded performance.  It seems like an important attribute to
me, and there's no knob in the PHS interface.

Bill

Content of type "text/html" skipped