John the Ripper jumbo - advanced offline password cracker, which supports hundreds of hash and cipher types, and runs on many operating systems, CPUs, GPUs, and even some FPGAs
As @AlekseyCherepanov noticed, running "single crack" mode against bcrypt hashes on CPU without OpenMP is wasteful because our bcrypt implementation computes 3 hashes at a time, whereas SINGLE_HASH_MIN is 8, which isn't a multiple of 3. We should probably modify the code such that it rounds to a multiple of min_keys_per_crypt.
While looking into this, I see that for logging from john.c we try and infer the chunk size using SINGLE_HASH_MIN, but the actual code in single.c is now more complicated. So we may get logging inconsistent with what we actually do next. Fixing the above issue could introduce yet another inconsistency of this sort. In particular this message might be wrong:
if ((options.flags & (FLG_SINGLE_CHK | FLG_BATCH_CHK)) && chunk < SINGLE_HASH_MIN)
chunk = SINGLE_HASH_MIN;
if (chunk > 1)
log_event("- Candidate passwords %s be buffered and tried in chunks of %d",
min_chunk > 1 ? "will" : "may",
chunk);
As @AlekseyCherepanov noticed, running "single crack" mode against bcrypt hashes on CPU without OpenMP is wasteful because our bcrypt implementation computes 3 hashes at a time, whereas
SINGLE_HASH_MINis 8, which isn't a multiple of 3. We should probably modify the code such that it rounds to a multiple ofmin_keys_per_crypt.While looking into this, I see that for logging from
john.cwe try and infer the chunk size usingSINGLE_HASH_MIN, but the actual code insingle.cis now more complicated. So we may get logging inconsistent with what we actually do next. Fixing the above issue could introduce yet another inconsistency of this sort. In particular this message might be wrong: