The VariantMap is only an intermediate format here and is immediately converted to something more robust. KeePassXC and keepass-rs will remove any entries they don’t recognize. Correspondingly, all of KeePassXC, keepass-rs and kdbxweb currently ignore these parameters.Īlso, while it might look like the KdfParameters field could store some additional data, this data is not guaranteed to survive. Note that while key and associated data parameters are theoretically allowed, KeePass doesn’t currently set them. Memory usage in bytes, usually needs to be divided by 1024 The version number is followed by any number of entries using the following format: So 0x123 should be accepted here, 0x200 should not (keepass-rs didn’t get the memo). Implementors are told to ignore the lower 8 bits of the version number, only raising an error if the higher bits encode an unsupported version. They start with a UInt16 value encoding the format version. The VariantMap fields are a key-value storage. This is quite a footgun as many other tools will not be able to open such databases (KeePass and kdbxweb in particular won’t). As we’ll see below, KeePass has their own encryption authentication bolted on.įor some reason, KeePassXC does not merely support Twofish-CBC for legacy reasons but also allows creating new databases using this cipher. Note: ChaCha20 really means the unauthenticated ChaCha20 stream cipher without Poly1305. KeePass introduced support for the ChaCha20 cipher along with the KDBX4 format, and the plan is probably to make it the default in the long term. The default encryption cipher is AES256-CBC. It is unclear when this cipher was even used. Out of these, AES128 is generally unsupported. KeePass never rejects any fields, KeePassXC only fails when encountering no longer supported KDBX3 fields:
Implementors of KeePass and KeePassXC chose to be very forgiving however, resulting in unknown fields being dropped from the database silently. When reading KDBX4 files, it should be advisable to fail on unexpected fields. All other fields are required for the database to be decrypted. In practice however, only the PublicCustomData field is optional. Technically speaking, all of the fields listed are optional. The outer header ends when an EndOfHeader field is encountered. Unencrypted storage for arbitrary data, meant to be used by KeePass plugins (new in KDBX4) Parameters specific to the key derivation algorithm (new in KDBX4) Size is 16 bytes for CBC ciphers, 12 bytes for ChaCha20. Indicates the last header field, typically contains the byte sequence 0d 0a 0d 0aĬompression algorithm: 0 = None, 1 = Gzip I can only document the latest version of the format (KDBX 4.1), though I’ll try to highlight changes wherever I’m aware of them.
#Keepass 1 vs 2 code#
Let’s hope this documentation helps whoever else needs to work with that file format, and studying source code will no longer be required. For that, I looked at the source code of KeePass, KeePassXC, keepass-rs Rust library and the kxdbweb JavaScript library.
I’ll try to explain the format and the subtle details here. They all probably manage to handle common files in the same way, but each of them has subtle differences when handling underdocumented format features. With the starting point not being documented, these are only moderately useful.Īnd so it’s not surprising that the implementations I looked at aren’t actually implementing the same file format. All you get is a semi-intelligible list of changes from KDBX 3.1 to KDBX 4 and from KDBX 4 to KDBX 4.1. The KeePass developers themselves never bothered providing complete documentation. At best, you can find outdated and incomplete descriptions by random people. One aspect was rather surprising: given how many open source products use this format, it is remarkably underdocumented. I’ve been playing around with KeePass databases.
0 kommentar(er)
