openwall/john

Support new KeePass algorithms

kholia opened this issue · 8 comments

magnumripper commented

I'd like to see an OpenCL format as well. (Edit: OK, that's #2471)

kholia commented

Here are some sample KeePass databases for testing.

kholia commented

ChaCha20 support is done. Argon2 stuff needs work.

kholia commented

Steps for building KeePass under Linux. Tested on Fedora 25.

Install monodevelop package

Download and extract KeePass-2.36-Source.zip

cd Build

sh PrepMonoDev.sh

cd ..

xbuild /p:TargetFrameworkVersion="v4.5"
HEELcaT666 commented

Hi! Has this issue been fixed yet? I would be deeply grateful if you could please resolve this problem.

  • 👍1
BobForCat commented

Hi guys,
I have successfully implemented a python parsing (less than 200 lines) of the keepass v4 file using the KeePassJava2 code+documentation and I would like to propose this as a python keepass2john.py for john, but that will also impact hashcat when it will be implemented

I'd like that we (or in fact : you two, or whoever you think needed for this) decide the exchange format (for both hashcat and john) we change for that new version of file.

Actual john format

Actuat format contains in this order

transformRounds     --> deprecated
algorithm  
masterSeed  
transformSeed         --> deprecated
initializationVectors  --> not needed anymore  
expectedStartBytes  --> not needed anymore

v4 format idea

As the new format contains a HMAC of the header using the password (or +keyfile) I'd suggest the new format contains

algorithm
masterSeed  
kdf_params    --> details below
validation_hmac_sha256
full_header              --> to compute the hmac and validate

The kdf_params consists of a mutliple key pairs, where keys are a single uppercase letter and value either a number of bytes. I tought we could

  • write value as number if number, else hex of bytes
  • write pair like k=v
  • join every pair with *

For argon2 (with in order: version, iteration,memory,parallelism,salt) it would look like

UUID=ef636ddf8c29444b91f7a9a403e30a0c*V=19*I=2*M=1048576*P=2*S=388336bb577ac102077622356bac26141893528edf7687026fe0d6f79e220b27

My questions are

  • is this a good idea to put the full header there to validate on ? Or would it be better to use the hmac of the first encrypted bloc instead ?

  • As I write in python it's very easy for me to decide the separators, the format, ... but in C it's different, so I don't know if how the parameters are written is a nice way. Like we could add a field nbKdfParams to help or whatever

Final possible format

$keepass$*2*2*5663db9dd04368094676903cd2bc447ec2d92d175a7913471fc6ff8a606138bf*6*UUID=ef636ddf8c29444b91f7a9a403e30a0c*V=19*I=2*M=1048576*P=2*S=388336bb577ac102077622356bac26141893528edf7687026fe0d6f79e220b27*910a4315635e59579a531444cb73cca06c9d0003a4652f4b782a4ce048f5d81f*03d9a29a67fb4bb5000004000210000000d6038a2b8b6f4cb5a524339a31dbb59a03040000000100000004200000005663db9dd04368094676903cd2bc447ec2d92d175a7913471fc6ff8a606138bf0b8b00000000014205000000245555494410000000ef636ddf8c29444b91f7a9a403e30a0c040100000056040000001300000005010000004908000000020000000000000005010000004d080000000000100000000000040100000050040000000200000042010000005320000000388336bb577ac102077622356bac26141893528edf7687026fe0d6f79e220b2700070c0000004bbdce257080e13ce35337db00040000000d0a0d0a

pings to @jsteube @kholia hashcat/hashcat#1013

solardiz commented

@BobForCat Thank you! Once we agree on the encoding and have the script, what is the plan to have this actually supported in JtR and/or hashcat? Do you intend to work on that as well, or know who will?

BobForCat commented

@solardiz Nope, no development on the cracking side for me, and I don't know anyone for that task

I also discovered that https://github.com/libkeepass/pykeepass did a parsing for v4, but I'm unsure if we can use a python dependency into a JtR extraction script