2
$\begingroup$

I'm working on a local, client-side password manager. I want to hash a master password with argon2 to store it safely in an SQLite database. This will be how a user could login and be authenticated. (Also I'm using Rust for this project, with sodiumoxide, a rust wrapper for libsodium)

I was also planning on somehow using the master password to generate encryption keys. Obviously, that's what argon2 does, and that's what will be stored in the database for the master password, but I don't want to use what's freely available in the database in case the local db file is stolen or compromised.

So, other than argon2, how else can i use the master password for encryption keys (maybe pbkdf2?), should i even do so? should i even be worried about a local db file being compromised? Thanks!

Improve this question
$\endgroup$
2
  • $\begingroup$ Are you looking for some kind of "context string" to be used as parameter to the KDF? $\endgroup$
    – DannyNiu
    Commented Nov 3, 2023 at 1:47
  • $\begingroup$ Usually master password would be provided by the user when opening database and Argon2 would generate all necessary keys (every time). Only salt and encrypted database would be saved. $\endgroup$
    – LightBit
    Commented Nov 3, 2023 at 9:16

1 Answer 1

Reset to default
2
$\begingroup$

Argon2 is capable of outputting more than one secret or keys. If it couldn't you could use a KBKDF such as HKDF to create multiple keys from the output of Argon2. These secrets are initially kept in memory, not stored.

To authenticate you could store one of those secrets together with the used salt and iteration count in your DB and compare while logging in. This would provide the authentication. You could use the other key to derive any amount of encryption keys using the KBKDF.

This has a disadvantage though. If you would derive the encryption keys of the passwords directly or indirectly using Argon2 then those keys would be dependent on the password, the iteration count and of course the salt (+ any additional parameters used). That means that if you would like to change the passwords that you would have to reencrypt all the data in your DB.

It might be a better idea to use the key to encrypt a set of random data encryption keys. That way the user is able to change the password by simply re-encrypting the data keys instead of reencrypting the entire DB. Of course, with the current computers you could also decide to simply encrypt the DB itself.

Yes, of course you should be worried about the DB being compromised. If you wouldn't then you would not need to encrypt anything. Could I suggest a good AEAD encryption primitive to make sure that the DB cannot be altered either?

Improve this answer
$\endgroup$
1
  • $\begingroup$ Wow, when reading on Argon2 I completely glossed over the capability to generate multiple keys; An oversight on my part! Also, I really like the idea of using the master derived key to encrypt random data keys for encryption to save computation power and time when changing the master password. As for your last point, up until now I've been concerned only with encrypting the data within the database, but I would be very interested to learn how to prevent the alteration of or encrypt the database itself. $\endgroup$
    – dvub
    Commented Nov 4, 2023 at 20:41

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.