Add XChaCha20-Poly1305 AEAD.

[briansmith]

Implement XChaCha20-Poly1305 using the IETF construction only, as done here.

This is blocked on us finding (or writing) a clear security analysis of the XChaCha20-Poly1305 construct. In particular, how safe is it to use a randomly-generated nonce with XChaCha20-Poly1305? To what extent should a XChaCha20-Poly1305 nonce include non-random components? Should we suggest that users construct the nonce with some substructure that reduces the dependency on the PRNG being secure, analogous to IETF Fixed+Counter construct at https://tools.ietf.org/html/rfc5116#section-3.2?

I believe that the same feature was was added in libsodium in jedisct1/libsodium#461. In particular, see crypto_aead_xchacha20poly1305_ietf_encrypt_detached and crypto_aead_xchacha20poly1305_ietf_decrypt_detached. We should use the test vectors from that patch to verify that we interop with libsodium. Note that libsodium also implements the non-IETF DJBian construction of ChaCha20-Poly1305 and XChaCha20-Poly1305, but I explicitly do not want to support that construction, only the IETF construction. See jedisct1/libsodium#462 for some context regarding what libsodium decided to do. See also codahale/chacha20#4.

Besides implementing the construct and adding the test vectors, we might also consider updating the ring::aead API documentation to give clear advice about when to use the XChaCha20 construct.

The ring code currently relies on the fact that nonces for all currently-supported AEADs are 96 bits, so the existing code would need to be refactored to remove that assumption in a separate commit before the XChaCha20-Poly1305 code is added.

[briansmith]

I think we should first try to define and implement some SIV mode for ChaCha20-Poly1305 as described in #413. if/when we run into unsolvable problems with the SIV mode, or if the XChaCha20-Poly1305 becomes really important due to some protocols adopting it, then we can do this.

[briansmith]

See also the original XSalsa paper: Extending the Salsa20 nonce.

[tarcieri]

@briansmith to my knowledge libsodium's XChaCha20 is IETF only

[briansmith]

@briansmith to my knowledge libsodium's XChaCha20 is IETF only

That seems to be true as of jedisct1/libsodium@1686da3. Awesome!

[djc]

The description here has three questions:

• In particular, how safe is it to use a randomly-generated nonce with XChaCha20-Poly1305?
• To what extent should a XChaCha20-Poly1305 nonce include non-random components?
• Should we suggest that users construct the nonce with some substructure that reduces the dependency on the PRNG being secure, analogous to IETF Fixed+Counter construct at https://tools.ietf.org/html/rfc5116#section-3.2?

From subsequent comments, it's not completely clear if these have answers already, and if not, what could be done to get them.

[briansmith]

it's not completely clear if these have answers already, and if not, what could be done to get them.

I agree. That's the main reason it hasn't been done. However, that's also the case if you were to use AES-GCM or ChaCha20-Poly1305, except for them we already know the answer to the first question, "how safe are random nonces," is "not really safe."

That said, I think it would be fine to add XChaCha20-Poly1305 to ring without having great answers to those questions, if somebody contributes the implementation and tests, because I know people want this kind of functionality and people seem happy enough with XChaCha20-Poly1305, even if I'm not quite convinced personally.

[briansmith]

See https://twitter.com/BRIAN_____/status/832326564343734272