4
$\begingroup$

I am looking at a cryptographic protocol in a somewhat unusual environment: the communicating parties can share arbitrarily long secret keys over a secure channel.

If forward secrecy is not required, it seems that one can simply encrypt/authenticate a (random) 256-bit key using the 256-bit shared secret, and then start sending messages encrypted using ChaCha20-Poly1305 (or AES-GCM). This seems to be trivially secure assuming that the underlying ciphers are secure (Proof: The attacker cannot forge or reorder messages after the first without breaking the AEAD or knowing its key -- but to obtain the key the attacker would need to break XSalsa20-Poly1305 or the CSPRNG used, or the 192-bit nonce of XSalsa20-Poly1305 would need to be reused, or the shared secret would need to be leaked. The AEAD and XSalsa20-Poly1305 are both widely believed secure, the shared secret must be assumed secret, and the probability of a 192-bit nonce collision is negligible). A counter starts at 0 each time, serving as both message sequence number (to prevent reordering) and nonce.

TLS-PSK is designed for this, but it is extremely complex. This seems much simpler.

Improve this question
$\endgroup$
2
  • $\begingroup$ This seems secure, but what is the advantage over just using XSalsa20-Poly1305 alone? $\endgroup$
    – otus
    Jan 28, 2016 at 10:12
  • $\begingroup$ @otus The associated data (here the message length and sequence number). $\endgroup$
    – Demi
    Jan 28, 2016 at 15:05

1 Answer 1

Reset to default
1
$\begingroup$

Yes, this is secure.

Even simpler would be to just use XSalsa20-Poly1305 and the long term key directly. You could authenticate any additional data with the Poly1305 just as well as in the case of the ChaCha-based combination. However, if you use e.g. libsodium where the former interface does not support additional data and the latter has a short nonce, then combining them like you suggest is OK as well.

Note, regarding your comment: there is no need to authenticate the message length separately. The whole message is already authenticated by default so you can just calculate its length.

If the only additional data you need to authenticate is a sequence number, you could include it as part of the 192-bit nonce and use XSalsa20-Poly1305 only. 128-bit random part and 64-bit sequence number would be fine, and 160/32 would be even better.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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