search

openwall / john

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
https://www.openwall.com/john/
Other
10.31k stars 2.1k forks source link

(Some formats) auto-tune OpenCL for actual loaded hashes (as opposed to test vectors), if applicable #2538

Closed magnumripper closed 7 years ago

magnumripper commented 7 years ago

This is very notable in the DMG format. I believe auto-tune is always done with test-vector iteration counts of 1000, while real-world hashes of today are in the hundred-thousands.

Should be easy, most things are in place already. Oh, and bitlocker-opencl should do the same, off the top of my head.

magnumripper commented 7 years ago

BTW if we're really lucky, this can be a fix in shared auto-tune code that would affect all OpenCL formats with little effort.

claudioandre-br commented 7 years ago

this can be a fix in shared auto-tune code that would affect all OpenCL formats

This is not possible 'as is'. You need decide when auto-tune (first or second call of reset()). Look at:

static void reset(struct db_main *db)
{
  if (db==test_vector && JtR_is_cracking) //it is NOT a run to benchmark, self-test, ...
     do_nothing(); //1st call of reset()
  else // db contains loaded hashes (if applicable)
     auto_tune(db); // 2nd call of reset; 1st call for a --test run.
}

You can't move this decision to shared code because reset() itself might need to do its tasks before or after tuning: move data to GPU, kernel (re)build, etc.

magnumripper commented 7 years ago

Ah, yes. But anyway it's a fairly trivial change in each format (any many formats don't really need this).

magnumripper commented 7 years ago

@claudioandre I found a way to do it in shared code. But it needs testing/review.

magnumripper commented 7 years ago

Ooops, terrible bug fixed in ff70033