|
Message-ID: <CANJ2NMOa02va-4KocMPKrAMF91Su07K20n1yAb5iM1z4EMgJ6w@mail.gmail.com> 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.