Date: Fri, 17 Apr 2015 20:14:22 +0200 From: Agnieszka Bielec <bielecagnieszka8@...il.com> To: john-dev@...ts.openwall.com Subject: Re: [GSoC] John the Ripper support for PHC finalists Solar, thank you very much for the advice It's very helpful 2015-04-17 3:12 GMT+02:00 Solar Designer <solar@...nwall.com>: > Agnieszka, > > I've just suggested to you (off-list) that you work on the PHC finalists > in a specific order. (We may revise it later, though.) I'd like to > provide the rationale and additional advice: > > POMELO - you're already working on it. > > Parallel - it's the simplest, and also one where good performance on GPU > is expected. Although Parallel can efficiently be run on GPUs defensively, > with a high parallelism setting, I suggest that in your implementations > you take advantage of the higher-level parallelism coming from having > multiple candidate passwords. That way, you'll be able to exploit SIMD > and GPUs even when attacking Parallel hashes that use a low parallelism > setting. > > Lyra2 - it already includes some CUDA code. You may look into > integrating that into JtR, as well as translating it to OpenCL (so we'd > have lyra2-cuda and lyra2-opencl). > > yescrypt - it's relatively complex, so may be tricky to implement in > OpenCL. OTOH, there's significant overlap with scrypt, which isn't a > PHC finalist per se, but is a (legacy) mode of operation of yescrypt, > and which we need supported on GPU anyway. We already have scrypt > supported in JtR on CPU. There are also performance numbers for scrypt > on GPU from other projects, such as from the many Litecoin miners for > r=1 and from the Hashcat project as well as from another team for other > settings. So we'll be able to verify how close to optimal your > implementation got by checking it against those other implementations > and their published speed figures. (For yescrypt's native modes, > though, your results would be brand new.) Another aspect is that scrypt > (but not yescrypt's native modes) is deliberately time-memory tradeoff > (TMTO) friendly. So you'd practice with exploiting TMTO while you work > on this. Do not be afraid, in the case of scrypt it's easy and we're > readily familiar with it, so will provide guidance. > > Makwa - its author has recently made the bold claim on the public PHC > discussions list that Makwa is as GPU-unfriendly as bcrypt (even though > for different reasons). We should try to confirm or disprove it. > > battcrypt - it should be similar to bcrypt, albeit more complex to > implement in OpenCL (needs not only Blowfish, but also SHA-512). > We should verify that it's also behaves bcrypt-like or worse in terms of > GPU attacks. > > Catena - I listed this one closer to the end in part because there are > as many as four default instantiations of it. I think we'll need to > only implement two: Catena-Dragonfly and Catena-Butterfly. I think we > would not need to implement the -Full instantiations of these. But it > may be clearer which ones of the four PHC focuses on by that later time. > > Pufferfish - it's fairly clear how this one will behave, which on one > hand provides a way to test your optimizations against the expected > outcome, but on the other hand makes this relatively uninteresting. > Also, Pufferfish as currently specified has recently been found to be > buggy for above 2 MB m_cost, and also to be arguably too slow to be > chosen as a PHC winner even for its primary intended range of m_cost. > So it isn't a likely winner, at least in its present form, and thus is > of relatively little interest. > > Argon or Argon2 - the PHC panel has not decided yet whether to let > Argon2 into the competition or not. So it is not clear which one of > these we'd want implemented and benchmarked yet. Once things clear up, > maybe the right Argon should be moved up the list. > > I suggest that you start new john-dev threads for each PHC finalist when > you approach starting work on it, or even separately for each finalist's > C and OpenCL implementations. This current thread is covering too many > related yet distinct topics now. > > Thanks, > > Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.