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]

Message-ID: <534A8594.8070604@bindshell.nl>
Date: Sun, 13 Apr 2014 05:39:48 -0700
From: Jeremi Gosney <epixoip@...dshell.nl>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] The best of the best, IMO

On 4/13/2014 12:22 AM, Solar Designer wrote:
> 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.

I was hoping that password crackers would jump at an opportunity to
optimize new algorithms, but maybe I'm being too optimistic :)

> 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.

Well, I think it answers half the question. Knowing how the defense
optimized code performs is significant. And I think using JTR as a
testbed is a decent way to benchmark the defense optimized code, and
provides a good starting point for attackers to start optimizing code.

> For Pufferfish and battcrypt, I think there may be significant speedup
> from interleaving of multiple instances for attack.  Someone needs to
> implement that.

Yeah, I was going to implement this in the attack-optimized JTR patch
for Pufferfish, but was short on time. I was able to kind of fake it
with MPI though by running 4 threads per core instead of 2 (CPU has HT),
I think this achieved a similar effect.

> 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?

In the attack optimized code I am, yeah. I think this is one of the rare
instances where its use isn't totally inappropriate.

> Also, we need GPU attack implementations.

Agreed, but there's a bit of a logistics problem with that, in that I
highly doubt we're going to be able to get 23 kernels written. Jens has
stated offlist that he plans to write kernels for his 6 favorite
algorithms, maybe we'll all get lucky and his 6 will align with the ones
we feel should be finalists.