Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 15 Jul 2012 21:25:03 +0400
From: Solar Designer <>
Subject: Re: xsha512-cuda & xsha512-opencl testing

myrice -

On Mon, Jul 09, 2012 at 07:41:02AM +0400, Solar Designer wrote:
> Can you please start testing these formats with the following kinds of
> test files (generate them first):
> 1 hash (and thus 1 salt)
> 100 hashes, 100 salts
> 10000 hashes, 10000 salts
> 10000 hashes, 100 salts (100 hashes per salt)
> 10000 hashes, 1 salt (10000 hashes per salt)
> 1000000 hashes, 1000000 salts
> 1000000 hashes, 1000 salts (1000 hashes per salt)
> 1000000 hashes, 1 salt
> No need to test single crack mode (we know it'll behave poorly), but
> with e.g. -i=all8 it should be possible to get all of these to run
> faster than CPU.  Note that JtR reports "effective" c/s rate while
> cracking - that is, combinations of {candidate password, target hash}
> tried per second.  So for 1M hashes with just 1 salt, you should see a
> huge figure there (like "50000G" if you get this to run optimally, which
> might not be easy).  (Yes, I need to improve reporting to include raw
> c/s rate as well.)

Thank you for working on this.

I notice that you're running the tests in wordlist mode.  This is fine
for correctness testing, but not for benchmarking, where it adds a
bottleneck.  I suggest that you use -i=All8 instead - and interrupt
after a few minutes.  You'll look at the c/s rate then.  The test hashes
should be such that no password will get cracked during these runs
(well, or very few, not affecting the speed significantly).


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.