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

Support new KeePass algorithms #2502

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions