JKS KeyStore - Add support for cracking 'key passwords'

[kholia]

Note: This was done using gpt-5.3-codex CLI.

Side-note: I didn't have much luck with Gemini 3.x on this task.

Fixes: #5959, #2725, #3219

Samples:

KeyStore-Test.jks.txt
KeyStore.jks.txt

Passwords:

openwall
12345678
openwall123
testtest

[solardiz]

Thank you @kholia! I'm afraid I don't have time to seriously get into this and review it properly, but we certainly do want to merge your contribution anyway. You should probably submit the samples via a PR to https://github.com/openwall/john-samples

Maybe @Borim7 @wdormann @frankenstein91 @floyd-fuh who commented on the referenced issues would like to take a look, test, and comment.

[Borim7]

I have tested your code with multiple keystore files:

• Empty keystore only with master password does not work, the keystore2john script extract the hash, but john does not find it: no hash loaded
• Keystore with one password works ✔️
• Keystore with multiple password works ✔️

So regular use cases works as intended, corner case empty keystore only with master password can be improved ;)

Thanks for the work

[kholia]

Awesome and exhaustive testing work @Borim7 - thank you!

With the latest fixes:

user@zion:~/repos/john/src$ ../run/john  --format=keystore hashes -w=dict
Using default input encoding: UTF-8
Loaded 5 password hashes with 5 different salts (keystore, Java KeyStore [SHA1 256/256 AVX2 8x])
Will run 16 OpenMP threads
Press 'q' or Ctrl-C to abort, 'h' for help, almost any other key for status
Warning: Only 7 candidates buffered, minimum 128 needed for performance.
storePassword    (emptyStore.keystore)     
openwall123      (1.jks)     
12345678         (1.jks-mykey)     
openwall         (2.jks)     
testtest         (2.jks-mykey) 

https://stackoverflow.com/questions/37994315/how-to-create-an-empty-java-trust-store describes how to create empty KeyStore(s).

[floyd-fuh]

Sorry if I'm wrong, but I'm currently just on my phone, but: it looks to me like the implementation just attacks the private key password, while ignoring all the cracking speed improvements that were found. If I'm reading it correctly it xors the entire encrypted private key for each password attempt, which is unnecessary.

This is still a huge improvement: john will never attempt to crack a password that does not protect any data. Yes, jks is so old that they thought creating a "password" (the keystore password) that is used to calculate a hash to proof that the keystore was not corrupted by byte flips so just integrity protection is a good idea. Public keys are always cleartext in there. Private keys are protected by a password that might or might not be the same as for the integrity protection.

However, it's only necessary for a cracking step to calculate a sha1 over 20 bytes plus the password. It looks like this code shoves the entire encrypted private key in the sha1 calculation, is that correct?

So either I haven't read the code correctly or hashcat will still be much much faster.

[kholia]

The base implementation can go in first (once reviewed and found to be working) and then you can add your optimization patch.

[Borim7]

John works now for all my test files.Thanks

[kholia]

GPU testing:

user@zion:~/repos/john/src$ ../run/john  --format=keystore-opencl hashes -w=dict
Device 1: NVIDIA GeForce RTX 3060 Laptop GPU
Using default input encoding: UTF-8
Loaded 5 password hashes with 5 different salts (keystore-opencl, Java KeyStore [SHA1 OpenCL])
Note: Passwords longer than 42 [worst case UTF-8] to 127 [ASCII] rejected
LWS=64 GWS=245760 (3840 blocks) 
Press 'q' or Ctrl-C to abort, 'h' for help, almost any other key for status
Warning: Only 7 candidates buffered, minimum 245760 needed for performance.
storePassword    (emptyStore.keystore)     
openwall         (2.jks)     
openwall123      (1.jks)     
testtest         (2.jks-mykey)     
12345678         (1.jks-mykey) 

All good!