Is it safe to reuse the same nonce for decryption an indefinite amount of times in this context?

Question

I'm creating a password management application and I'm considering using the following procedure to keep passwords safe:

1. Asking the user for raw_password, for example "MyLongMasterKeyPassword"

2. Generating master_key from raw_password with Scrypt and a random salt

3. Storing the salt (kept public)

4. Asking for raw_message (the password to store)

5. Generating cipher using AEAD-ChaCha20Poly1305IETF and generating a random nonce, and then asking for AD(Additional authentication)

6. Storing the nonce

7. Encrypting raw_message with cipher, nonce, and AD, then using the nonce once for encryption, that returning cipher_text

8. Storing the cipher_text

9. Decrypting cipher_text with stored salt and nonce, then asking for AD and raw_password to regenerate the master_key with the stored salt, and then generating a cipher with the master_key and stored nonce, which returns the decrypted_message (a password, probably)

Now, the question is, is this procedure safe? Specifically, is it safe to re-use the same nonce for decryption an indefinite amount of times, if you only use it once for encryption?

Answer 1

Specifically, is it safe to re-use the same nonce for decryption an indefinite amount of times, if you only use it once for encryption?

Indeed, all good security definitions (under which ciphers are proven secure) will place no restrictions on the input of the decryption algorithm. The intution behind this is that the the input to the encryption algorithm will be send over the network at which point anything can happen to it.

Security only breaks down if you encryption two different messages using the same key-nonce pair.

Now, the question is, is this procedure safe?

Yes. In fact the encryption scheme is essentially a reinvention and instantiation of PKCS#5's PBES2 which is provably secure¹ (even if you were to use a fixed nonce). Your parameter choice in this case is to use randomized-nonce ChaCha-Poly for encryption and scrypt for key-derivation.

---

_{1: Our local pedants may note that the security definition of LORX from that paper only implies CPA-security, but an extension to CCA-security definitions should be straightforward as the proof essentially relies on hiding the key from the adversary and then "inheriting" the encryption scheme's security properties.}