search

briansmith / ring

Safe, fast, small crypto using Rust
Other
3.75k stars 704 forks source link

Add XChaCha20-Poly1305 AEAD. #411

Open briansmith opened 7 years ago

briansmith commented 7 years ago

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 https://github.com/jedisct1/libsodium/pull/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 https://github.com/jedisct1/libsodium/issues/462 for some context regarding what libsodium decided to do. See also https://github.com/codahale/chacha20/issues/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 commented 7 years ago

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 commented 7 years ago

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

tarcieri commented 7 years ago

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

briansmith commented 7 years ago

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

That seems to be true as of https://github.com/jedisct1/libsodium/commit/1686da3d3cf1d3c40a6985f8c515d20feb451bf8. Awesome!

djc commented 7 years ago

The description here has three questions:

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

briansmith commented 7 years ago

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 commented 7 years ago

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

briansmith commented 6 years ago

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

djc commented 6 years ago

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 commented 4 years ago

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 commented 4 years ago

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

zonyitoo commented 3 years ago

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

x448 commented 3 years ago

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 commented 1 month ago

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.