[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120329130132.GA26680@openwall.com>
Date: Thu, 29 Mar 2012 17:01:32 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: fast hashes on GPU
On Thu, Mar 29, 2012 at 02:23:38PM +0800, myrice wrote:
> Well, I know there are "one salt" and "many salts". I still think we have
> to copy same bunch of passwords to GPU with each salt. Look at the code in
> bench.c(function benchmar_format):
...
> With index > 1, (salts >1, many salts). We execute line 236 to set a salt.
> Then line 237, in crypt_all, we transfer all candidate passwords to GPU
> with just one salt that 236 set. Actually, we transfer same bunch of
> passwords by "salts"(index) time to GPU.
What exactly happens here depends on how you implement the functions.
set_key() may set a flag like keys_changed, crypt_all() may check that
flag and only send the candidate passwords to GPU if the flag is set
(and then crypt_all() should reset the flag).
Alternatively, you may be sending individual passwords right in
set_key(), but that will likely be a lot slower (many small transfers
instead of one larger transfer).
With either approach, you don't send the same candidate passwords over
and over when only the salt has changed between crypt_all() calls.
> However, I hope we could transfer
> all salts with a bunch of passwords to GPU. After these are tested, we
> switch to next bunch of passwords. This is what you previous said that we
> compute one bunch of passwords with lots of salts and then move to next
> bunch of passwords.
Please see above as it relates to not resending the same candidate
passwords. As to the salts, with the current interfaces they have to be
sent one by one by crypt_all(), and that's sort of fine - these data
transfers are tiny and you interact with the GPU at that time anyway
(you ask it to go ahead and process the previously provided bunch of
candidate passwords with the next salt). There's room for improvement
here, but it's primarily about not interacting with the GPU at these
times at all (so it's not a trivial improvement to make), not about
avoiding those tiny data transfers.
Alexander
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.
