Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 6 Apr 2011 03:10:28 +0400
From: Solar Designer <>
Subject: Re: sha256 format patches

On Tue, Apr 05, 2011 at 11:01:24PM +0200, ?ukasz Odzioba wrote:
> I had some free time and have created two patches for JtR. Both are
> capable to crack raw sha256 passwords.
> One of them runs on CPU, and other uses CUDA library. It's zero
> revision so performance is rather poor. I was focused on make it work
> but i'am going to do some improvements especially in CUDA version. In
> the next step i could try implement rest of SHA-2 family hashes, do
> profiling and squeeze much more from a GPU.

I suggest that to gain experience you try to turn this into a slow hash:
say, make it 5000 iterations of SHA-256.  Of course, unless you actually
implement SHA-crypt, this won't be a real-world hash type, yet you could
use it for benchmarking.  You'll create your own test vectors, and have
both the CPU and the GPU implementations tested with those (same ones).
If you do things right, you'll see a lot more of a performance
difference between CPU and GPU.

> I don't know what is the better distribution schematic:
>   1) Two independent patches for GPU and CPU versions (current)
>   2) One patch integrating both versions (what about users without
> cuda installed? add another make option?)
>   3) Patches from JTR1.7.6 to CPU and from CPU to GPU

For now, let's keep them separate.  In fact, before you proceed to add
iterations as I proposed above (making the patches unusable for any
real-world tasks), perhaps upload the two patches to the wiki? -



P.S. Please don't forget to apply to us under GSoC by April 8.

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.