[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120402064156.GA9277@openwall.com>
Date: Mon, 2 Apr 2012 10:41:56 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: JtR: GPU for slow hashes
Hi Sayantan,
Since apparently you did not read my P.S., I'll start with this now:
On your replies, please quote relevant context only (but do quote some).
On Mon, Apr 02, 2012 at 08:14:39AM +0530, SAYANTAN DATTA wrote:
> 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.
Right.
> As for example a two bit index is sufficient if the hash
> table has only four hashes to store(just an example).
We do not use the hash tables to "store" hashes, we use them to "lookup"
hashes quickly. I guess this is what you meant.
In fact, the hash tables are optional and are not always used at all:
for very low numbers of hashes loaded for cracking (for a given salt, if
applicable), hash tables are not used (because e.g. it is quicker to
compare against one or two hash values directly than to perform a hash
table lookup). When hash tables are in use, then any one hash bucket
may contain any number of hashes from 0 to the total number loaded
(although the latter case is extremely unlikely). The hash table sizes
to use are determined per-salt using pre-tuned thresholds. Currently,
the thresholds are such that most buckets will contain 0 hashes, so we
instantly determine that there's no match (the typical case when testing
candidate passwords). (In fact, in post-1.7.9 code I also implemented
bitmaps, which are used before hash table lookups and let us reject most
candidate passwords without going for full hash table lookups. The
bitmaps are much smaller than hash tables (one bit vs. one 32- or 64-bit
pointer per entry), which improves the locality of reference and thus
makes better use of CPU caches.)
> *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. *
As Lukas correctly replied, only the 128-bit hash is the "binary
ciphertext" for JtR's interfaces. The salt (username in this case)
becomes the "binary salt" (in this case you don't need to decode it,
the username substring is to be treated as "binary salt" as-is).
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.
