Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 10 Jul 2012 18:22:02 +0800
From: myrice <>
Subject: Re: Get hash number in cmp_all()

On Tue, Jul 10, 2012 at 10:40 AM, Solar Designer <> 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.


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.