[prev in list] [next in list] [prev in thread] [next in thread] 

List:       john-dev
Subject:    Re: [john-dev] Hello, interested on slow hash and fast hash on GPU
From:       Solar Designer <solar () openwall ! com>
Date:       2012-03-27 9:22:09
Message-ID: 20120327092209.GC14695 () openwall ! com
[Download RAW message or body]

On Mon, Mar 26, 2012 at 04:48:26AM +0800, myrice wrote:
> 1) I read papers you recently posted. And I emailed author of qhasm-cudasm
> for requesting the tool.

Please let us know if/what you hear back.  (BTW, I think that multiple
authors contributed to it.)

> 2) The bitslice implementations of SHA-256 or SHA-512 on GPUs are worth
> discussing. I read your bitslice implementation of MD5. It takes advantages
> of sse2 to compute MD5 hashes at one time. Now raw-sha256-cuda
> implementation already use SIMD and/or bitslice.

Just where did you find any "SIMD and/or bitslice" in the
raw-sha256-cuda implementation?  While the compiler can auto-vectorize
(at least theoretically), I don't see that in the source code.

We only have non-bitslice implementations of these currently (except for
my experiment with MD5 on CPUs that you saw), and it is not known
whether non-bitslice SIMD or bitslice will be faster (it may vary by
target architecture, etc.)  This is why I suggest that whoever works on
this should try both approaches.  My guess is that non-bitslice (with
SIMD where appropriate) will be faster on currently common CPUs/GPUs
(speaking of SHA-256 and SHA-512), but it does not hurt to try bitslice
as well.

> I tried use more
> threads(than now just 1) to compute one hash. However, the data dependence
> make it hard to implement. I am looking forward ideas of optimization.

You should be computing many hashes, not one.

> 3) As you suggested, I am starting write DES format on cuda. I will make
> another post to track my progress and clarify questions on it.

OK.  This was not exactly my suggestion to you - I was merely answering
questions on what remains to be done in terms of JtR/GPU, and the DES
stuff is among tasks that haven't been approached yet (as it relates to
JtR/GPU only).

Alexander
[prev in list] [next in list] [prev in thread] [next in thread]