Date: Wed, 18 Jul 2012 14:10:41 +0400 From: Solar Designer <solar@...nwall.com> To: john-dev@...ts.openwall.com Subject: Re: int crypt_all(count, salt) myrice - On Wed, Jul 18, 2012 at 01:52:03PM +0400, Solar Designer wrote: > For the sake of simplicity, I am using the existing salt->index() hash > function, although this involves converting from thread offset + index > in thread to global index and back. A "standalone" implementation (like > one running on GPU) would implement a hash function of its own and would > access its own bitmap, hash table, etc. BTW, how did you locate the hashes corresponding to the current salt on GPU in your existing (now lost?) implementation of loaded hashes? Did you possibly implement some hash table lookups by salt value? Or do you assume that crypt_all() is called for all salts sequentially (in the same order they were seen before)? (This might be risky.) Having a struct db_salt pointer is great on CPU, but it's still not quite it on GPU. So maybe in GPU-enabled builds you need to add an "unsigned int id;" field to struct db_salt, fill these fields with sequential numbers (as salts are allocated), pass them to GPU from crypt_all() (this will be as simple as passing salt->id), and use them as array indices there (you know the salt count from reset()'s db->salt_count, so you can allocate this array to the right size). Sounds good? 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.