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

[briansmith]

This is needed for Paseto version 2; see https://github.com/paragonie/paseto/tree/master/docs/01-Protocol-Versions#version-2-recommended

[djc]

The CFRG folks didn't seem to care much for PASETO: https://mailarchive.ietf.org/arch/search/?email_list=cfrg&gbt=1&index=4YQH6Yj3c92VUxqo-6wJrXabFk4

[x448]

XChaCha: eXtended-nonce ChaCha and AEAD_XChaCha20_Poly1305
draft-irtf-cfrg-xchacha-03 (Jan 10, 2020)
https://tools.ietf.org/html/draft-irtf-cfrg-xchacha-03

It includes developer-friendly test vectors.

[djc]

@briansmith if I worked on this, would you have bandwidth to review it?

[zonyitoo]

It have been a year, what's the status of this issue? @djc @briansmith

[x448]

I don't see any progress on the draft RFC I mentioned. Maybe it (or a new draft from scratch) needs somebody like @agl to give it momentum and turn it into an approved RFC. People like Adam don't grow on trees so I've no idea if he'll ever have time.

Having 192 non-key bits during initialization of the cipher can be useful for simplifying the creation of new protocols that leverage those extra bits in novel ways to make it even easier for regular developers to avoid pitfalls involving nonce, counter, csprng, entropy, etc.

[AaronKutch]

I have to use the XChaCha20 from the chacha20poly1305 crate, and it seems that crate is just all around slow for whatever reason. The performance is the limiting factor in a code path I use. Replacing the XChaCha20 with the ChaCha20 from ring results in a 500%+ speedup, but I absolutely need the XChaCha20. From what I have seen, XChaCha20 should only be a little slower than ChaCha20 even with small inputs, so I'm supposing a ring version should be much faster. It has better API structure as well. What would it take to implement? I would consider jumping in but there are so many abstraction layers going on that it is difficult to understand.

edit: I have figured out for my use case that I won't be relying on XChaCha20 for performance, but it still would be nice to reduce dependencies.