phc-discussions - Re: [PHC] The best of the best, IMO

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]

Date: Sun, 13 Apr 2014 11:22:08 +0400
From: Solar Designer <solar@...nwall.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] The best of the best, IMO

On Sat, Apr 12, 2014 at 11:59:36PM -0700, Jeremi Gosney wrote:
> On 4/12/2014 11:49 PM, Solar Designer wrote:
> > Great.  Now, a way battcrypt might win over Pufferfish anyway is if we
> > determine that it performs better even when both are compiled to native
> > code (defensive).  This will take some testing, for both defense and
> > attack.  Are you doing this sort of testing? :-)
> 
> I included JTR patches for both the reference version and the optimized
> version in my submission, and plan to write patches for some of the
> other candidates as well.

Thank you for that!

> I was hoping we could reach out to the
> community (john-users mailing list?) for help with this, as I really
> don't want to implement all 22 by myself.

We can, and you're welcome to do that!

However, for this to be of help to PHC decision-making we need
attack-optimized implementations (in addition to defense-optimized
ones), and it's unclear whether JtR community members would have
sufficient incentive for that.  Chances are that almost all of the 23,
if wrapped into JtR formats, will (initially) be using mostly
defense-optimized code for attack, which is suboptimal and does not
(yet) significantly help us answer the questions we need answered.
It is nice extra testing anyway, though.

With yescrypt's default settings, there's some excessive instruction
level parallelism included, so I am confident that on currently typical
CPUs it performs almost as well for attack as it does for defense, with
no separate implementation needed yet.  (I think there's some room for
further optimization for both defense and attack, though.)  Of course,
this is assuming the native API is used, so that the memory
(de)allocation overhead is kept out of loop.

For Pufferfish and battcrypt, I think there may be significant speedup
from interleaving of multiple instances for attack.  Someone needs to
implement that.  And indeed the memory (de)allocation overhead should be
out of loop for attack as well.  IIRC, you're using alloca() to avoid it
in the JtR patch, correct?

Also, we need GPU attack implementations.

Alexander