Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 21 Jul 2012 17:31:24 +0400
From: Solar Designer <>
Subject: Re: int crypt_all(count, salt)

myrice -

On Wed, Jul 18, 2012 at 02:10:41PM +0400, Solar Designer wrote:
> 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.)

I think you never replied to the above.  Please do.

> 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).


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.