Re: [CFRG] XChacha20 counter size

[Loup Vaillant-David <[e-mail]>]

> As the author of the XChaCha RFC draft, I view making XChaCha20-
> Poly1305 incompatible with the IETF's ChaCha20-Poly1305 a non-goal.

Understand that my proposal *is* compatible.

On section 2.3.1 of your draft, you specify the following pseudocode:

    xchacha20_encrypt(key, nonce, plaintext, blk_ctr = 0):
        subkey = hchacha20(key, nonce[0:15])
        chacha20_nonce = "\x00\x00\x00\x00" + nonce[16:23]

        return chacha20_encrypt(subkey, chacha20_nonce,
                                plaintext, blk_ctr)

The only difference between that and Libsodium is what happens when the
message exceeds >256GiB. A use case that as far as I understand RFC
8439 does not define. Implementations have 3 realistic choices when
dealing with such undefined behaviour:

1. Wrap the counter back to zero, and trigger an insecure stream reuse.
   This is what happens when we naively implement XChacha20 on top of
  
RFC 8439. This would disclose the authentication key, one of the
  
worst vulnerability possible.

2. Panic, crash, or report an error. This is typical of misuse aware
   libraries. I have no problem with this behaviour. It's a bit
   limiting, but at least it's secure.

3. Increment the next word, currently occupied by the nonce. This is
   what naturally happens when we derive XChacha20 from DJB's Chacha20.
   As much as we may disapprove of gigantic messages, this one at least
   does not break all security, and is a nice alternative for libraries
   who cannot (or will not) report an error.

I don't want incompatibility with RFC 8439. All I'm asking here is that
we disallow (1), and allow (3).

Loup.