[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 21 Jul 2012 17:27:00 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: int crypt_all(count, salt)
myrice -
On Wed, Jul 18, 2012 at 01:52:03PM +0400, Solar Designer wrote:
> 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.)
As discussed on IRC yesterday, attached is a patch that implements "int
*count", but not set_mask() yet. As discussed, for your initial
experiments you may hard-code generation of candidate passwords in your
hack of raw-md5-opencl - e.g., append [a-z][a-z] to all passwords -
which should be good enough for test runs and for us to see how to
enhance the interface further.
The crypt_all() description became rather complicated, unfortunately:
/* 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.
* Note that output indices don't have to match input indices (although they
* may and usually do). The indices passed to get_key(), get_hash[](),
* cmp_one(), and cmp_exact() must be in the 0 to crypt_all() return value
* minus 1 range, although for infrequent status reporting get_key() may also
* be called on indices previously supplied to set_key() as well as on indices
* up to the updated *count minus 1 even if they're beyond this range.
* The count passed to cmp_all() must be equal to crypt_all()'s return value.
* 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
* match *count the way it is after the crypt_all() call.
* The count is passed by reference and must be updated by crypt_all() if it
* computes other than the requested count (such as if it generates additional
* candidate passwords on its own). The updated count is used for c/s rate
* calculation. The return value is thus in the 0 to updated *count range. */
int (*crypt_all)(int *count, struct db_salt *salt);
I've attached two files implementing the same changes:
john-1.7.9.6+crypt_all+LM-crypt_all-pcount-1.diff - relative to the
patches I posted before (applies on top of tree patched with
john-1.7.9.6-LM-1.diff along with all previous patches).
john-1.7.9.6-crypt_all-pcount-1.diff - applies on top of clean 1.7.9.6
as found in CVS.
Alexander
View attachment "john-1.7.9.6+crypt_all+LM-crypt_all-pcount-1.diff" of type "text/plain" (15693 bytes)
View attachment "john-1.7.9.6-crypt_all-pcount-1.diff" of type "text/plain" (31268 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.
