I am writing a simple application, mainly as a fun challenge, but also to hopefully someday use as my password manager.
I'm using pynacl's SecretBox
, which provides an extremely simple API to encrypt and MAC (presumably encrypt-then-mac, although the docs are a bit sparse on these details) data. In my application, the user is prompted for a password, which is then run through pynacl's KDF module to generate the key for the SecretBox.
Obviously, it's important to supply the KDF with a randomized salt, and if I want the file to be usable, I have to store that salt. At the moment, I am storing the salt in the first 32 (set by the pynacl constant SCRYPT_SALTBYTES
); to read the file the application reads the first 32, stores that in a variable as the salt, and then reads the rest and passes that on to the SecretBox.
As a result, my salt has no integrity protection at all. The downside of the simplicity of the SecretBox API (literally a constructor, and encrypt
and decrypt
methods) is that there's no obvious way to sneak this extra bit of data into the MAC, and I'd rather avoid implementing my own encrypt-then-MAC scheme if possible as I'm not a crypto expert (A big part of why I chose this API is because of how idiot-resistant it appears).
Are there any concerns with allowing an attacker to modify the password salt in this context?