[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 10 Jul 2012 18:22:02 +0800
From: myrice <qqlddg@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: Get hash number in cmp_all()
On Tue, Jul 10, 2012 at 10:40 AM, Solar Designer <solar@...nwall.com> wrote:
> myrice -
>
> On Mon, Jul 09, 2012 at 11:36:07PM +0800, myrice wrote:
>> Current my loaded hash on GPU have fixed size(4000).
>
> Is this in some released version of your code?
>
No, I haven't push to github yet. I just want to push to my github but
find a bug with TS. I am debugging it.
> Are you allocating space for loaded hashes per-salt or for all at once?
> In the latter case, how does your code know which hashes to compare
> against (for the current salt only)?
>
Refer to my last week report. I have two arrays: ld_hash and ld_salt.
They both have hash number size. If two hashes have same salt, the
salt will store twice. More specific, in cmp_all(), with each binary,
ld_hash[index] = binary and ld_salt[index] = current_salt. So I can
check the salt after crypt_all() to determine which hashes to compare.
>> I want to
>> allocate actually hash size when we get hash number. However, the hash
>> number in database is invisible to me. Here are 2 ways to get it.
>>
>> 1. Reallocate the memory when hash number exceeds the pre-defined
>> size. Is it a good idea to add mem_realloc() to memory.c?
>
> I am fine with that, but I don't see why you want to be allocating a
> copy of the hashes on CPU when you need that copy on GPU. Is this just
> an intermediate step, before you transfer the hashes to GPU?
>
Yes. I don't want to memcpy to GPU with small size of a hash. I will
record hashes/salts in an array in CPU and copy them to GPU at once.
>> 2. Remove "static" and declare database as extern variable in my format
>
> What would you be removing "static" from, exactly?
>
In john.c, the variable database recorded number of hashes/salt. It
would be helpful if I can use the variable. The "static" modifier
restrict the scope only in john.c. I don't know if it's good to expose
it to other file.
> I think it'd help if you refer to your current implementation more
> specifically, so that we discuss these proposed changes while looking at
> the actual code.
>
Yes. I will post my code when I finish debugging. The details can be
found in my last week report also.
Thanks
myrice
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.
