Unsupported Keepass Database Version

[Roshan Fried]

Ijust upgraded to 2.50 and since, I'm unable to open my database that works with a combo of master password + key file (see attached picture for the exact error).

I've tried to revert back to 2.49 and even 2.48.1 but I now get the same error on each version.

I've been able to open my database earlier this week with the correct password and I'm 100% certain that there is no spelling mistake (I even typed each letter one by one to be sure that the issue isn't between the chair and the keyboard :) )

I'm wondering if the first launch of 2.50 this day may have changed a setting that also affect any previous version (which I think is unllikely, but it's the only logical explanation that I can find as of right now ...).

Side notes:

-I've tried multiple computer restarts

-I haven't change my password, nor the key file since the last sucessufull openning

-The OS hasn't identified a file change since the last sucessufull openning

Well, I have absolutely no memory of tweaking any parameters for a long while. It must either have been a long time since it has been change and the switch to 2.50 has shed lingth on the issue or I really inadvertently made a huge mistake recently.

Emergency sheet was here but came to no help unfortunatly. It has just been by chance that by trying to solve the issue, I duplicated the file and then didn't payed attention to the fact that the key file option wasnt' ticked.

I encountered something similar with 2.50.

I always use 2.50 on a portable version (unzipped 2.50).

Used a 64K file under my ryzen9 and all worked well (no external other stuff). Moved to my other laptop i7 no problems.

When I added some entries and size raised to 96K and trying to pass from the AMD ryzen9 to Intel i7, file continues to work on Ryzen 9 but stopped working to the i7 laptop raising following msg:

That is completely different, the message indicates you are not using a KeePass database file at all, or it is corrupt. If the password was wrong you would get a message saying the master key is invalid.

Thank you Paul for your suggestion.

I tried the search File > Open > Find Files > Quick and found hundreds of files ;-) [yes! I've been using KP since so many years and perhaps I archive too many stuff instead of deleting it :-(]

It was impossible to sort them by date and with about 300+ kbdx files I decided to go by hand :-)

If you can open the DB on any machine then it is OK.

If it fails to open on another machine and get an invalid signature message, then the copy failed for some reason.

Can you copy the DB another way?

Thanks Paul again for the valuable hint. They seem both good products... I'm going to evaluate them in Mac env (I think just StrongBox is OK for the Mac). I'm never been MAC fun, neither windows, to tell the truth... but I saw it growing so I know that environment quite well. In MAC I only like the console as it resembles the command.com prompt ;-)

cheers, Luca

Presumably, details of the binary format only ever change with a major format version. So a library determining whether it supports the format should be safe checking VersionMajor field only. KeePass itself refuses opening files with an unknown VersionMajor value and asks for a user confirmation when encountering an unknown VersionMinor value.

The outer header ends when an EndOfHeader field is encountered. Technically speaking, all of the fields listed are optional. In practice however, only the PublicCustomData field is optional. All other fields are required for the database to be decrypted.

When reading KDBX4 files, it should be advisable to fail on unexpected fields. Implementors of KeePass and KeePassXC chose to be very forgiving however, resulting in unknown fields being dropped from the database silently. KeePass never rejects any fields, KeePassXC only fails when encountering no longer supported KDBX3 fields:

While seemingly redundant, these two fields serve different purposes. The former is used to recognize data corruption, an operation performed before the access credentials are known. The latter is used to recognize malicious data manipulations once the credentials are available.

Altogether, there seem to be three possible sources of key data: a database password, a key file and some abstract key provider (typically a hardware device). Key providers are assumed to implement a challenge-response scheme, the challenge used to produce key data being the contents of the MainSeed header field. The details of key provider implementations differ depending on the product: in KeePass you can only have either a key file or a key provider, in kdbxweb you can have both, and KeePassXC even has provisions for multiple key providers. keepass-rs on the other hand does not support key providers at all.

All the various key sources are mashed together into a composite key. Since a database password has a wrong size, it is being hashed with SHA-256 first, resulting in 32 bytes. Then all key sources present are concatenated and hashed with SHA-256.

The composite key is used as the input to the key derivation algorithm, either AES-KDF or Argon2. This part is mostly straightforward, all the necessary parameters are in the KdfParameters field. You only have to keep in mind that KeePass stores Argon2 memory cost in bytes whereas all implementations take this value in kilobytes.

Now this could allow an attacker to maliciously manipulate the data: the blocks can potentially be reordered without affecting the signature. KeePass addresses this by using a different HMAC key for each block: SHA512(BlockIndex + HmacKey). Here, BlockIndex is a UInt64 value, encoded as eight bytes. The first signed block in the file gets assigned BlockIndex 0, the next one 1 and so on.

If you wonder about the complicated approach in the third step: the goal appears to have been allowing the database contents to be read as a stream in one pass. One HMAC signature for the entire file contents would have been sufficient. But then one would either have to read the entire file first to validate the signature before it can be decrypted. Or one would have to start processing decrypted data before it has been authorized.

Instead, each of these layers is meant as a stream wrapper. The file only needs to be read once, no more than 1 MB of file contents have to be buffered at a time, and all data coming out is already authenticated. Yes, I also suspect that there are simpler approaches.

As you note, the folks at KeePassXC have also done much solid work on documentation. Wonder if they are interested in updating their existing work? I'd be willing to help. Key point in all this is that Dominik Reichl would need to be on board with such an effort and as you mention, hasn't been all that interested for a very long time - and you know, well, it's his project and that's his prerogative!

I suggested a few smaller changes to the KeePassXC documentation and received some positive feedback, nothing has been implemented so far however. And the repository is set up in such a way that creating a pull request is impossible.

My point about the change in date encoding (in that thread) was that although you know from the format of the data which encoding it is, you do not necessarily know what the context of loading the file was, so having a flag to indicate which encoding is in use would be useful. Actually, saying what format you are using (3 or 4) in the meta element would suffice, so would not be burdensome as far as file size is concerned. Anyway, I have seen XML that contains both formats, so this is something you'd need to check "in the wild".

A couple of other ideas include that it would be useful to be able to indicate the format of a binary - perhaps via a mime type. There is an implication in V4 that the binaries in the headers are indexed according to their position in the header, which is slightly inconvenient as if you have removed binaries before saving you need to renumber the references.

Thank you for pointing me to this discussion. Now I have confirmation that people indeed considered data deserialization to be a major performance factor. There are no numbers given, and I wonder whether anyone measured those. To me, even looking into it for an application that does Argon2 key derivation is mind-boggling.

I have KeePass (.kbdx) database with key file (.keyx) that was created with KeePass2 on Windows. I'm able to open the database on Windows (KeePass2) or Mac (strongbox). However, on Ubuntu 20.04, which is a dual boot with the Windows machine and the databse is stored in a shared mount, I am unable to unlock.

In KeePassXC I get a an invalid credentials error which states that if this reoccurs the file may be corrupted; KeeWeb just refuses to open it. I can confirm the file is not corrupted as I can open after the error in Windows and am certain the password/keyfile are correct.

There are two versions of KeePassXC in the ubuntu software center... I should have checked the versions because I tried the second one on the list which was actually the latest version and it worked no problem

KeePassX is no longer developed - as announced on the KeePassX website on 2021-12-09. Our decision to fork KeePassXwas made some years prior, due to a sharp decline in code frequency at the time, combined with our wish to provideyou with everything you love about KeePassX plus many new features and bugfixes.

KeePass is a very proven and feature-rich password manager and there is nothing fundamentally wrong with it.However, it is written in C# and therefore requires Microsoft's .NET platform.On systems other than Windows, you can run KeePass using the Mono runtime libraries, but you won't getthe native look and feel which you are used to.

KeePassXC currently uses the KeePass 2.x (.kdbx) password database formats KDBX 3.1 and KDBX 4 as its native file formats.KDBX 2 files can be opened, but will be upgraded to a newer format. KeePass 1.x (.kdb) databases can be imported intoa .kdbx file, but saving a .kdbx file as .kdb would be lossy, and saving to .kdb is not supported by KeePassXC.

3a8082e126