[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKGDhHUmHLBaPyFppHV=egSSch79Y4cJ-uV+ypvAEjQAJROEoQ@mail.gmail.com>
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.
