2
$\begingroup$

KeePassXC supports Argon2, which is great for security. However, there's a quirk that's been bothering me. Every time I save modifications to the database, it seems to stretch (derive) the key again, resulting in a 10-second delay. I should clarify that I'm perfectly fine with the 10-second delay when I type my passphrase to unlock the database (I specifically choose the settings for this).

Why does KeePassXC perform key stretching when saving edits to the database? Wouldn't it be more efficient to use the same key that was used to decrypt the database? It's symmetric encryption, right?

Is there a security risk of reusing the key for symmetric encryption in this case?

Edit: My proposal is to implement a two-step key derivation process. Initially, a slow and memory-intensive KDF like Argon2 is used during login, followed by a faster KDF for deriving a new key. When the user clicks the save button, only the second step is executed again. Are there any potential issues or concerns with this two-step process?

At the moment, I'm employing a two-step process with the help of an external key stretching script (SlowKDF and DoubleSlow). However, it would be more user-friendly if this two-step process were integrated seamlessly within the password manager itself.

$\endgroup$
5
  • 1
    $\begingroup$ Why do you have a 10s delay set? That implies you've got a horribly weak master passphrase, and are just hoping that the KDF stretching will prevent brute force. A 1s delay is more than enough for any reasonably strong (>= 7 randomly chosen words from the EFF Long list) passphrase. KeePassXC erases the KEK from memory while running to help avoid leaking it due to side-channel attacks, so it has to be re-derived to save. $\endgroup$ Oct 21, 2023 at 15:26
  • $\begingroup$ But the passphrase (or a hash from the passphrase) is kept in memory anyway. Nothing is stopping the attacker from stealing it. If the passphrase is kept in memory (RAM) why not keep also the middle hash (produced after the first round of the process I propose)? Or keep the hash from the first round instead of the passphrase? I am not required to write again my passphrase when I click the "save" button, therefore it's saved in RAM (or a hash of it is saved in RAM). It make sense to store in RAM a hash, not the passphrase (in case the passphrase is reused). $\endgroup$ Oct 24, 2023 at 20:20
  • $\begingroup$ "A 1s delay is more than enough for any reasonably strong (>= 7 randomly chosen words from the EFF Long list) passphrase." This is not a fact, it's a speculation. There are unknown factors: we don't know how quantum or conventional computers or other advancements may speed up the algorithms used for the key stretching, we don't know how many of the typed symbols are captured by the security (or hidden) camera. $\endgroup$ Oct 24, 2023 at 20:28
  • $\begingroup$ It's more of a fact than it is speculation. A sufficiently strong passphrase is immune to brute-force even by quantum computers using the entire energy budget the surface of the Earth gets from the Sun for thousands of years, and operating at the ultimate limits of possible computational efficiency (far beyond what we've achieved in practice). If you've got a camera watching you, then any passphrase will be insecure and the delay is pointless. $\endgroup$ Oct 29, 2023 at 23:15
  • $\begingroup$ We can't be sure that your understanding of the physics of the computation is correct (Landauer's principle, etc.). What if the quantum computer have enough memory in a superposition state? If the recording with the camera is a bad quality only some of the letters will be recognized. $\endgroup$ Oct 31, 2023 at 21:19

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.