While looking at the ChaCha20 and Poly1305 AEAD construction as defined by RFC 8439, more precisely its use of the key and the nonce, I came up with the questions below. Maybe someone with some in-depth knowledge is willing to share it?

  1. The key and the nonce (usually a "number to be used only once") are used twice in this construction: first, to generate the Poly1305 one-time key using the ChaCha20 block function, and second, to encrypt the plaintext using the ChaCha20 function. Why is this reasonable and secure? Especially as both are using a related construction and its stated for ChaCha20 that the nonce "MUST not be repeated for the same key".
  2. In the AEAD construction, the nonce is not explicitly authenticated by the MAC. Is it still secure to include the nonce in the AAD as this could be treated (at least in some way) as a reuse of the nonce with the same key? I guess it is secure, but can someone explain why this is so?
  • 4
    $\begingroup$ (1): The counter value is different for ciphertext and Poly1305 key, $\endgroup$ – DannyNiu May 29 '20 at 13:15
  • $\begingroup$ @DannyNiu could you convert your comment into an answer? $\endgroup$ – kelalaka May 29 '20 at 15:10
  • $\begingroup$ 2) IV/nonce are not keys and no need to hide them. Only reuse or predictability can be problem. $\endgroup$ – kelalaka May 29 '20 at 16:02
  • $\begingroup$ @kelalaka What's wrong with a predictable nonce? I thought reuse was the only actual problem. $\endgroup$ – Joseph Sible-Reinstate Monica May 29 '20 at 17:44
  • $\begingroup$ @JosephSible-ReinstateMonica It is, actually, related to CBC. Search for CBC predictable IV. $\endgroup$ – kelalaka May 29 '20 at 18:00

Actually, by your own criterion, the same nonce is routinely used much more than twice, because each call to the ChaCha20 core function reuses the same key and nonce, except with a different counter value.

Here's the problem that's tripping you up: the prohibition on using the same key/nonce pair to encrypt more than one message applies to the construction's callers, not the construction's internals. The implied tension you're reading between the external requirement and the internal details just isn't real.

But, internally, the fact that each call to the core function within an invidual encryption operation uses a different counter value is relevant here.


Your Answer

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