In addition, XChaCha20 also appears to not have the message length or number restrictions that ChaCha20 does:

The XChaCha20 variant, introduced in libsodium 1.0.12. It can safely encrypt a practically unlimited number of messages of any sizes, and random nonces are safe to use.

The version at https://godoc.org/github.com/aead/chacha20 was written by @aead who has crypto code in the standard library and /x/crypto.

Is there a strong reason why it hasn't been included in /x/crypto (or was it just that nobody has had the time to work on it)?

(For others' reference, https://github.com/aead/chacha20poly1305 is a full AEAD implementation using @aead's chacha20 library that supports XChaCha20.)

Broader support for XChaCha would indeed be great.

A longer nonce can prevent foot-shooting with custom protocols, and is XChaCha is trivial to add to an existing ChaCha implementation.

@cyphar IIRC the main focus of the C20P1305 implementation in x/crypto is TLS. For example there is special asm code for TLS. I think XC20P1305 is useful if:

• you want to en/decrypt many messages under the same key.
  This is probably useful if you're en/decrypting many messages while the nonce cannot be some kind of counter. I think that's a valid use case - even though I don't know whether it's a common one.
• you want to en/decrypt very long messages (longer than ~ 64 * 2^32).
  However, I don't think that this is a valid use case at the moment since cipher.AEAD requires the message to be in RAM. I don't think en/decrypting more than 256 GB under the same key-nonce pair is common; esp. if the whole data must be in RAM.

If this is a proposal/feature request - I think adding XC20P1305 may be useful. We may have to think about a clean API and add hchacha20 functionality. If anyone wants to send a CL - feel free to use any code of https://github.com/aead/chacha20poly1305 and https://github.com/aead/chacha20

However I cannot make any decision about proposals - so check with Adam and/or Filippo.

We tend to avoid variant proliferation in x/crypto, but an AEAD supporting random nonces is something I do eventually want in the standard library. (See also gtank/cryptopasta#14.)

I guess the API would just be NewX(key []byte) (cipher.AEAD, error).

However, maybe we should just wait for SIV.

@FiloSottile Should this proposal be put on hold for now?

See #24885.

Typo in bug number. I believe it should be #24485 .