[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+TsHUCU5DPYU0Z3GSDrRmcLDodKyjSojzgc2bXVf1_mseeZVQ@mail.gmail.com>
Date: Mon, 2 Apr 2012 08:14:39 +0530
From: SAYANTAN DATTA <std2048@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: JtR: GPU for slow hashes
On Mon, Apr 2, 2012 at 1:21 AM, Solar Designer <solar@...nwall.com> wrote:
> Hi Sayantan,
>
> On Sun, Apr 01, 2012 at 08:57:00PM +0530, SAYANTAN DATTA wrote:
> > I was looking at the cuda_mscash2_fmt.cl code but was unable to
> understand
> > the use of int binary_hash_x(void *binary) and the int get_hash_x(int
> > index) functions properly.
> > More specifically why are there so many functions for each of the above
> > type in the cuda code.
>
> This is not specific to the CUDA code, it is part of the formats
> interface. First, binary_hash*() functions return hash values (suitable
> as indices into hash tables) for the provided binary ciphertexts (full
> hashes loaded for cracking and already converted to binary). Then,
> during cracking get_hash*() functions return compatible hash values
> (suitable as indices into the same hash tables) for computed hashes
> (that correspond to candidate passwords being tested). There are many
> functions of each kind because there are many hash table sizes that we
> can use (depending on the number of hashes loaded for cracking).
>
> binary_hash*() are not performance-critical (they may affect startup
> time only). In fact, in the next revision of the formats interface I am
> likely to combine them into one function that will accept the desired
> size as an extra argument.
>
> get_hash*() are performance-critical (they're used during cracking if a
> hash count threshold for hash table use is reached). The use of many
> separate functions provides a little bit of speedup (specialized code).
>
> > It would be very helpful if you could give an example use of the above
> > two functions.
>
> You don't need to use them - you provide them for the rest of JtR to
> use. That said, you may see binary_hash*() called from loader.c:
> ldr_init_hash_for_salt(). This function also sets salt->index to point
> to the right get_hash*() function. The latter is called from cracker.c:
> crk_password_loop().
>
> Alexander
>
> P.S. On your replies, please try to quote relevant context only (but do
> quote some).
>
Hi Alexander,
I think the concept of get_hash() and binary_hash() is clear.The bit length
of the indices returned would vary as the number of hashes stored in the
table increases.As for example a two bit index is sufficient if the hash
table has only four hashes to store(just an example).
*I have one more doubt though.The full ASCII ciphertext has a format
"$DCC2$username#128bit
hash as hexstring".Now while converting this ascii ciphertext to binary ,do
we convert only the "128bit hash as hexstring" to binary or the entire
ciphertext. *
*
*
Regards,
Sayantan
Content of type "text/html" skipped
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.
