[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20130924144801.GB10341@openwall.com>
Date: Tue, 24 Sep 2013 18:48:01 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Rafael's weekly report #15
Rafael,
On Tue, Sep 24, 2013 at 01:01:10AM +0200, Rafael Waldo Delgado Doblas wrote:
> 2. Move to the new task related with jumbo. It's partially done but I need
> info about _binary_hash() and *_get_hash() do to finish it.
I provided some info on this in:
Date: Mon, 23 Sep 2013 23:32:31 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: [john-dev] Rafael's weekly report #14
Here it is again:
[...] regarding the 7 get_hash* and binary_hash* functions, they're
for 7 different hash table sizes, where a given size is used depending
on the number of hashes loaded for cracking (for a given salt, if
applicable). See the comments in formats.h, inside the definition of
"struct fmt_methods". Also see PASSWORD_HASH_* in params.h, and the
corresponding arrays in params.c. (I thought you knew this already,
from your work on an scrypt format for JtR.)
The most important reference here is to the comments in formats.h.
In case you haven't bothered looking at them yet, here they are:
/* These functions calculate a hash out of a binary ciphertext. To be used
* for hash table initialization. One of them should be selected depending
* on the hash table size. */
int (*binary_hash[PASSWORD_HASH_SIZES])(void *binary);
/* These functions calculate a hash out of a ciphertext that has just been
* generated with the crypt_all() method. To be used while cracking. */
int (*get_hash[PASSWORD_HASH_SIZES])(int index);
The purpose of these functions is to speedup comparisons of computed
hashes against those loaded for cracking, when many hashes were loaded
(for the same salt, if applicable). Rather than directly compare each
computed hash against each loaded hash, a bitmap lookup and then
possibly a hash table lookup are made. Usually, the bitmap lookup
instantly indicates "no match" (since the bitmap size is chosen to be
large enough for that). When the bitmap and hash table lookups indicate
that there might be a match, entries in the corresponding hash bucket
(which are fewer than the total number of loaded hashes for that salt)
are directly compared against the computed hash. This is implemented in
cracker.c.
Is this enough info?
Alexander
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.
