Discussion:
Why would crypt_all() need/want to generate additional candidate passwords?
(too old to reply)
Frank Dittrich
2017-11-14 18:04:32 UTC
Permalink
Hi,

I just read the formats.h comment for the crypt_all function:


/* Computes the ciphertexts for given salt and plaintexts.
[...]
* 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. */


Why would crypt_all() generate additional candidate passwords on its own?
Are there any sample formats which make use of this weird feature?


Frank
Solar Designer
2017-11-14 18:17:32 UTC
Permalink
Post by Frank Dittrich
Why would crypt_all() generate additional candidate passwords on its own?
Are there any sample formats which make use of this weird feature?
This was one of several formats interface changes I introduced in April
2013, and we're making heavy use of this feature for on-device (GPU and
FPGA) mask mode support (including along with other modes).

I also envisioned making use of this feature for faster LM hash support
on CPU, where crypt_all() would alter already-transposed bitslice DES
key buffers according to a mask (or maybe in an LM hash specialized
simpler exhaustive search mode), but we never cared to implement that.

Alexander

Loading...