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.