Date: Wed, 18 Jul 2012 13:52:03 +0400 From: Solar Designer <solar@...nwall.com> To: john-dev@...ts.openwall.com Subject: int crypt_all(count, salt) myrice, all - I've revised crypt_all() to be as follows: /* Computes the ciphertexts for given salt and plaintexts. * For implementation reasons, this may happen to always compute at least * min_keys_per_crypt ciphertexts even if the requested count is lower, * although it is preferable for implementations to obey the count whenever * practical and also for callers not to call crypt_all() with fewer than * min_keys_per_crypt keys whenever practical. * Returns the last output index for which there might be a match (against the * supplied salt's hashes) plus 1. A return value of zero indicates no match. * If an implementation does not use the salt parameter or if salt is NULL * (as it may be during self-test and benchmark), the return value must always * be exactly count. */ int (*crypt_all)(int count, struct db_salt *salt); This is an intermediate step before even further changes to it. (The next change to crypt_all() will likely be to make "int *count" - that is, let crypt_all() modify the count when it computes more hashes than there were keys, due to set_mask(). Yes, set_mask() is to be introduced at the same time with that change.) Attached to this message are 3 patches: john-22.214.171.124+reset-crypt_all-2.diff - makes the crypt_all() declaration and semantics changes to match the description above, patch relative to john-126.96.36.199-reset-1.diff that I posted before. john-188.8.131.52-LM-1.diff - makes use of the above changes to speed up LM hash cracking in OpenMP-enabled builds. This is a quick and dirty implementation not taking full advantage of the crypt_all() changes yet, but it does illustrate how the interface may be used. This implements initial hash comparisons within the same parallel region that computes the hashes, and by the same threads that computed the hashes (so it can't happen that one thread computed a hash, but another does the comparison, which would be slower). I've actually measured an almost 2x speedup in a certain OpenMP-enabled build running against 10k hashes. For the sake of simplicity, I am using the existing salt->index() hash function, although this involves converting from thread offset + index in thread to global index and back. A "standalone" implementation (like one running on GPU) would implement a hash function of its own and would access its own bitmap, hash table, etc. I primarily had myrice's project in mind when working on this example. In fact, I wouldn't be working on it right now otherwise. john-184.108.40.206-crypt_all+LM-1.diff is the same as above, but relative to clean 220.127.116.11 as found in CVS. myrice - if you'd like to experiment with these new interfaces on bleeding codebase (so that you can use them with a GPU format), you may move all *_fmt_plug.c files out of the tree so that you have fewer formats to modify to use the new conventions (or disable manually in Makefile and john.c). I actually recommend that you do this. You may also proceed to experiment with your own formats interface changes in a similar way (and propose successful ones in here). Thanks, Alexander View attachment "john-18.104.22.168+reset-crypt_all-2.diff" of type "text/plain" (14411 bytes) View attachment "john-22.214.171.124-LM-1.diff" of type "text/plain" (1701 bytes) View attachment "john-126.96.36.199-crypt_all+LM-1.diff" of type "text/plain" (24320 bytes)
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.