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.37k stars 2.11k forks source link

Make BitLocker CPU format feature complete #3310

Open kholia opened 6 years ago

kholia commented 6 years ago

Currently, the BitLocker OpenCL format (bitlocker-opencl) format support more hash formats than the CPU version.

It would be great if the CPU format (bitlocker) could be made more feature complete.

CC @e-ago Hi, I am still waiting for the high-level description of the algorithm+steps which are implemented in the BitLocker OpenCL kernel. I don't want to spend hours trying to reverse-engineer the heavily unrolled code in this kernel.

@e-ago Can you please work on making the CPU format feature complete?

magnumripper commented 6 years ago

Was this fixed recently or was that something else?

kholia commented 6 years ago

This is still pending. The CPU format doesn't understand all the hash sub-formats that the GPU format does.

The GPU kernel code is not easy to read for me -> Hence, I can't extend the CPU format to support all the hash sub-formats myself. This is where I need @e-ago to help us out.

solardiz commented 5 years ago

Our users keep running into this issue and are confused and we spend time explaining that they have to use the OpenCL format.

We'd very much appreciate work on this issue from you, @e-ago. Thanks!

Edit: related but different issues are #2895, #2517.

solardiz commented 4 months ago

Maybe rather than add functionality to the CPU format, we should deprecate the recovery key support in the OpenCL format and bitlocker2john - e.g., have them print warnings that people trying to attack recovery keys are generally wasting their time? I have yet to hear of a case where such attack would have been realistic. I imagine someone could have written a recovery key down and have just a few digits illegible and needing recovery, but somehow I've never heard of this in practice. People who actually end up running attacks on recovery keys are simply misguided, in part by our support for this in code and in the documentation, so it could be something for us to fix (discourage such use). I'd appreciate your comments, @e-ago.

solardiz commented 2 weeks ago

I just noticed that while BitLocker-OpenCL had minimum password length and default benchmark password length set to 8, we didn't have a minimum in our BitLocker CPU format and we benchmarked it at length 7. I'm now setting these to 8 as well (in a pending commit). I hope that's correct, @e-ago @holly-o?