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


Powered by blists - more mailing lists