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