[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120718101041.GA3740@openwall.com>
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.
