Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 27 Mar 2012 13:22:09 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Hello, interested on slow hash and fast hash on GPU

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

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ