3
$\begingroup$

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?

|improve this question
$\endgroup$
  • $\begingroup$ if you're curious why I'm writing my own pass manager, it's because this paper's discussion of the weaknesses of popular password database formats prompted me to think: "why not just encrypt it all?". $\endgroup$ – user371366 Aug 10 '17 at 22:20
  • $\begingroup$ I don't understand the last paragraph. What do you want to sneak where and why? $\endgroup$ – Elias Aug 11 '17 at 14:35
  • $\begingroup$ @Elias I was saying that ideally, I would have the salt be authenticated by the SecretBox's MAC function, without also getting encrypted (which would create a chicken-and-egg problem). So I would have to inject the salt in after the encryption stage, but before the MAC stage, hence "sneak it in" $\endgroup$ – user371366 Aug 11 '17 at 21:11
1
$\begingroup$

No, integrity protecting the salt is probably not required.

  • For confidentiality this is pretty obvious because changing the salt only throws away information for the attacker.

  • Concerning integrity things are a bit more complicated. Suppose, these files are stored on a central server where an attacker can manipulate them and suppose that some client will automatically retry downloading the file if decryption failed or something like that. Can an attacker learn anything about your password from knowing about decryption failures or the like for different salts?

    You could construct KDFs where this is possible but for any decent KDF (it just needs domain separation) it won't be. If you have domain separation changing the salt will never influence your password in a useful way and this makes incremental testing impossible.

|improve this answer
$\endgroup$
  • $\begingroup$ I couldn't think of any way that this could have an effect, but I've read about some esoteric attacks I don't really understand that seemed to suggest this was something to be careful about. But, if I'm reading you correctly, as long as I'm using a good KDF this isn't a problem? $\endgroup$ – user371366 Aug 11 '17 at 21:44
  • $\begingroup$ Yes, you should be fine with a good KDF. Of course, I could be wrong as well. ;) $\endgroup$ – Elias Aug 12 '17 at 21:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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