[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120718095203.GA3494@openwall.com>
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-1.7.9.6+reset-crypt_all-2.diff - makes the crypt_all() declaration
and semantics changes to match the description above, patch relative to
john-1.7.9.6-reset-1.diff that I posted before.
john-1.7.9.6-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-1.7.9.6-crypt_all+LM-1.diff is the same as above, but relative to
clean 1.7.9.6 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-1.7.9.6+reset-crypt_all-2.diff" of type "text/plain" (14411 bytes)
View attachment "john-1.7.9.6-LM-1.diff" of type "text/plain" (1701 bytes)
View attachment "john-1.7.9.6-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.
