[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110405231028.GA21782@openwall.com>
Date: Wed, 6 Apr 2011 03:10:28 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
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? -
http://openwall.info/wiki/john/patches
Thanks,
Alexander
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.
