HMAC Mismatch occurs on computer restart, and the kbdx file cannot be opened or repaired.

[propagating]

Expected Behavior

The kbdx should be able to be opened without issue, or, in the worst case, repaired.

Current Behavior

Open KeepassXC after a restart, and when entering the password (unchanged from the previous sessions), the database cannot be opened due to an HMAC mismatch. It cannot be repaired due to the same error. This even occurs in the most recent backups of the kbdx file that was open at the time.

Possible Solution

Currently, the only solution is restore a previous version of the database, but, backups made within the last few hours of the computer restart also tend to be corrupted, requires a backup that is usually a day older.

Steps to Reproduce

I'm sorry, I can't reliably reproduce this. There were 2 instances of corruption that were expected - a BSOD, and a Chrome Crash while connected through the new KeepassXC Browser Integration. But in both cases, there were also multiple backups of the open database that were also corrupted, not just the version of the kbdx open in KeepassXC.

Context

I've lost passwords, been unable to access PGP credentials, cc information, external keyfiles, and other information that is stored in KeepassXC. It occurs across multiple unique databases.

The kbdx file is always saved successfully, even with the BSOD and Chrome Crash, there was no active changes in the kbdx file, and it was successfully saved and backed up, it just happened to be open at the time.

Now, this is not always an issue when I can restore it, but I there are cases where that is not possible. In some cases, credentials are lost and the account they are tied to is unrecoverable as a result. Thankfully this hasn't occurred for anything too serious and I've made a point to spread out things into multiple locations to try and mitigate that.

Debug Info

KeePassXC - Version 2.3.4
Revision: 6fe821c

Libraries:

• Qt 5.11.1
• libgcrypt 1.8.3

Operating system: Windows 10 (10.0)
CPU architecture: x86_64
Kernel: winnt 10.0.17134

Enabled extensions:

• Auto-Type
• Browser Integration
• Legacy Browser Integration (KeePassHTTP)
• SSH Agent
• YubiKey

[droidmonkey]

Where are you saving these database files? The act of restarting should have absolutely nothing to do with the database being corrupt or not. UNLESS it is being corrupted on an SSD due to flushing not occurring prior to the BSOD or crash. KeePassXC does not maintain an active link to a file. The only time a file is open and written to is at time of saving. If the application is causing corruption then it would occur with or without a reboot/crash/etc. I certainly have never experienced this issue on Windows 10, although I never experience BSOD either. It's probably a sign that you have significant underlying hardware issues.

[propagating]

Primary kdbx and their backups exist on 2 machines running the same version of Windows 10:

1. Desktop SAS self-encrypting HDD - different SED for the main file, and backups
2. Laptop PCI-E SSD - both on same drive
3. Google Drive - used as a staging ground on a 3rd SED on desktop, and a second PCI-E SSD on the laptop.

I know that's a bit much, but after the first time I experienced this issue, I lost a month or so of data and it took a while to recover it. The google drive versions aren't used concurrently, ever.

This issue primarily occurs on the desktop, so I initially thought there could be something interrupting the hardware encryption, but it happens to the backups versions that aren't in use, and saved successfully.

Same situation on the laptop tho, and those aren't SEDs. Normal reboot/shutdown and then the next power up, the kbdx keeps throwing back the HMAC mismatch error, as due the most recent backups made.

The Laptop and Desktop are running identical hardware outside of hard drives and CPU. The desktop uses a Haswell-E chip, laptop Kaby Lake.

[propagating]

Still getting this behavior every few days. I've been trying to pin down anything that causes it consistently. Looking back to when it first started, it was around the time I changed the encryption settings from the default to the following:

ChaCha20: 256-bit
Argon2
16 Transform Rounsd
1024 MB Memory Usage
16 threads

[droidmonkey]

Wow those are huge settings for Argon2. It is very likely there is something funky going on while the key derivation is chugging along. Try lowering those settings to something like 16 / 256 / 4. What does the 1-second benchmark produce?

[propagating]

I’ll try those settings and report back in a few days. Glanced over that initially as it completes in a few seconds, but it would be great if that’s I need to fix it.

[propagating]

@droidmonkey One second bench throws up 3 or 4 transform rounds. I also clocked the time it takes to unlock the database with the original settings, and it was usually about 2.5 seconds.

One second bench with 256 MB and 4 threads is at 10 transform rounds

[droidmonkey]

I have mine set to 10 / 32MB/ 1 thread which gives me decent performance on my laptop and mobile device. Anything much more than that and I cannot open it on mobile without waiting several minutes.

[propagating]

So far, I haven't run into an issue with the reduced settings. I'll give it a few days to be sure, but at the very least I haven't run into in the last 2 days which is promising.

[propagating]

Doesn't seem to be an issue with the reduced transformation rounds for Argon2.

[propagating]

This started occurring again today. Only this time, it wasn't after a reset. It was after waking my computer up from sleep.

[droidmonkey]

Make sure you don't have the key file checkbox checked.

[propagating]

It's not, never has been.

[droidmonkey]

Just making sure because that has caused issues with other people.

[propagating]

No worries! I know that a lot of issues can come down to overlooking something small. I've been trying to do some additional troubleshooting. Because a KDF has to be deterministic, at least I assume it has to be?, I think you're probably right in assuming a potential hardware bug, maybe occurring during the transformation rounds after reset? Is there a way to log or test the values passed into the KDF originally, and between rounds to see if that's a potential issue?

[droidmonkey]

You could try running the unit test cases for kdbx4 many many times. These run through several permutations of the algorithm with known conditions.

[propagating]

I'll give it a go, thanks.

[propagating]

Turns out PC had a ram issue but laptop is still having issues, but I'll live with 1 for 2.

[kiprasmel]

I thought I experienced this issue, but turns out that I was just entering the wrong password!
Just a heads-up lol

[phoerious]

Make sure you only have boxes checked for things you have in your key (so uncheck key file if you don't have one). KeePassXC 2.5 will improve the usability of the unlock dialogue in this regard.

[propagating]

The issue temporarily resolves itself by accessing an older (sometimes weeks older) version of the database, and then immediately recur on that same database after relocking/unlocking, New KeepassXC versions haven't made a difference. Something is corrupting the kbdx on 2 separate machines, but not on a 3rd.