1

I want to modify this peer-to-peer communications software to allow parties to specify a shared secret key and have all communications encrypted with it.

[The software uses tweetnacl.js for the cryptographic operations.]

Re-using the exact same shared secret key for every message does not seem very secure. I have two questions:

  • Is this concern addressed by the presence of the nonce in nacl.secretbox(message, nonce, key) thus making it safe to re-use the shared secret key as long as the nonce is different every time? (which is a requirement anyway obviously).

  • Would it be even safer to derive a unique shared key for each message by hashing some salt and sending the salt along with each message so that the other side can do the same to obtain the unique shared key for the message? Or is this redundant?

Chris McCormick
  • 177
  • 6

1 Answers1

3

Is this concern addressed by the presence of the nonce in nacl.secretbox(message, nonce, key) thus making it safe to re-use the shared secret key as long as the nonce is different every time?

Yes. But you still have to be careful about protocol level attacks, such as replays or re-ordered messages.

(which is a requirement anyway obviously).

Note that a nonce doesn't need to be unique by itself, it's only the key-nonce pair that needs to be unique. For example if you use a per-connection key you can use a simple counter as nonce, since each connection has a unique key.

Would it be even safer to derive a unique shared key for each message by hashing some salt and sending the salt along with each message so that the other side can do the same to obtain the unique shared key for the message? Or is this redundant?

That's unnecessary if 24-byte nonces are sufficient for your purpose.

Internally xsalsa20 hashes a 32-byte key together with the first 16 bytes of the nonce into a 32-byte key, which is then used together with the remaining 8 bytes of the nonce.

CodesInChaos
  • 24,841
  • 2
  • 89
  • 128