Using a nonce as a salt for key derivation

Question

I'm currently playing a bit with PyNaCl (python binding to libsodium) and I want to use the secretbox for symmetric encryption between two parties, which means they both must know the (in my case randomly generated) nonce, so I would just send it with the ciphertext. I derive the secret key with argon2id from a password, but this needs a salt. So I was wondering whether it would be dangerous to use parts of the nonce as the salt, so I only have to transmit the nonce. I don't think it would be problematic because the salt is just used to prevent rainbow table attacks etc. I know it is dangerous to reuse a (key,nonce)-pair, but since the key is derived from both a password and the salt and the nonce is randomly generated every time, I don't see this as a problem.

Am I correct or is there a problem I'm not thinking about? Or is there a better approach? Also I'm asking more from the academic side of things and less from my implementation, that was just to explain how I came to the question.

In case there is already a similar question, please point me towards it, I did try the search but nothing really fitting came up.

Tl;dr: Is it generally cryptographically problematic to use a part of nonce for an AEAD scheme as a salt for a KDF ?

Answer 1

I derive the secret key with argon2id from a password, but this needs a salt. So I was wondering whether it would be dangerous to use parts of the nonce as the salt, so I only have to transmit the nonce.

Yes, the salt is used to eliminate the rainbow tables. Keep in mind that the rainbow tables can be build up to some degree. If we consider that the Bitcoin miners agree to build a rainbow table instead of mining, they can build a table the can most cover $\approx 2^{92.8}$ passwords in a year. This is not considered the case that the slowness of the password-based key derivation functions, like PBKDF2, scrypt, Argon2. If we consider that they are parametrized to slow like $2^{20}$ then the coverage is reduced to $\approx 2^{72.8}$.

Within the Kerckhoffs's_principles - that is all but the key is known to the attackers - the attackers will always choose the shortest path to achieve their target whenever they see that. If you use the nonce and send it in public, they will try to find it. If the password is not good, they will find it! However, if the passwords have good entropy like diceware or bip39 is used to generate one, there is no problem. Keep it above 128-bit entropy then your password is safe and the derived the key. Keep in mind that, the users tend to have bad passwords. Either you should educate them about using better passwords like generated by the diceware method or enforce them on some stupid rules that cause hard to remember passwords xkcd:936. In your case, you should generate a good one beforehand. You should also put an expire date-usage for the password, too. Or better, use a randomly generated key!.

Or is there a better approach?

Use Diffie-Hellman Key Exchange(DHKE) to exchange (establish better) the keys. One should prefer the Elliptic version of that ECDH. After the key is established then use HKDF to derive the key of the required length. Remember to use all of the exchanged keys. DHKE/ECDH That will provide you the forward secrecy as long as you and your friend deleted the keys after using them.

Actually, there is already a solution in the library; Crypto_box.