AEAD: XChaCha20-Poly1305
Closed this issue · 17 comments
The main difference between XChaCha20-Poly1305 and the original ChaCha20-Poly1305 is that the nonce size is 24 bytes instead of 8 bytes. The first 16 bytes of the nonce is used, along with the key, with HChaCha20 to derive a key, which is then used in ChaCha20-Poly1305.
The advantage of this extended-nonce variant is that you can use the same key for 2^96 messages before worrying about nonce reuse (the birthday bound), rather than 2^32 messages.
XChaCha20-Poly1305 is implemented in libsodium.
What would the steps be to get XChaCha20-Poly1305 considered for inclusion in OpenSSL for EVP encryption (i.e. for building application-layer cryptography protocols with OpenSSL)? Do I need to convince the IETF to bless it for inclusion in TLS first, even if that's presently a non-goal of my feature request?
No, it doesn't have to be in TLS, but some external third-party has to review (and approve) this before we will consider it. And it seems highly doubtful that it will be done in time for the upcoming release.
That's fine, I wasn't aware of an upcoming release and have no qualms about tabling its inclusion until the upcoming release has concluded. I just wanted to open the discussion about its inclusion now so, when it's reviewed/approved/ready, the developers who use OpenSSL have the chance to use an extended-nonce AEAD mode.
Is it standardised? We only accept standardised crypto.
@mattcaswell The CFRG has made it working group item, and an IETF RFC is expected in the near future.
Nothing stops anyone from making a separate provider that provides this. In fact, there could be a separate project producing a provider with algorithms that haven't been accepted in the OpenSSL main source yet (and possibly never will). A little like, in the C++ universe, Boost is a set of C++ templates that haven't been accepted into the STL yet (and possibly never will)
Is it standardised? We only accept standardised crypto.
The IETF now has an active Internet-Draft for this protocol:
https://tools.ietf.org/html/draft-irtf-cfrg-xchacha-03
https://datatracker.ietf.org/doc/draft-irtf-cfrg-xchacha/
Does that meet this requirement so that this protocol can be considered to include in OpenSSL? Or would you require it to reach a final RFC first?
It has to reach a final RFC first.
It has to reach a final RFC first.
That wasn't the case for TLS 1.3.
It has to reach a final RFC first.
That wasn't the case for TLS 1.3.
We held the release for the final RFC.
Getting the code in earlier (and incrementally) was okay, because we knew in advance that we were going to hold the release for TLS 1.3.
The key point is the work started well before the RFC was published, and your comment implied, at least to me, that nothing will start until the RFC is published which is not correct. (We also did some CMS update work IIRC)
It is not going to be "included in OpenSSL" until the final RFC is published. (Not my decision, for what little it counts.) Whether it means anything to "consider" it beforehand is probably subjective...
FYI for Go programmers watching this ticket: it's fairly straightforward to get fast* XChaCha20-Poly1305 by combining HChaCha20 from Go x/crypto with EVP_chacha20_poly1305 from OpenSSL.
If there is interest, I can make my implementation importable as a library.
* 5 x faster than x/crypto/chacha20poly1305 on armv7
Hi @rfjakob
Your approach is quite interesting, I was wondering if such approach would support streamed encryption/decryption. That is processing large files that wouldn't normally fit in RAM, whilst using Poly1305 to generate/verify authenticated tag.
Are there any updates on this?
I do not think there is any official standard specifying XChaCha20-Poly1305 so there is no progress. I am going to close the PR. Please re-open or open a new issue if there is any official standard for this algorithm.
Welp, this sucks especially since XChaCha20-Poly1305 is used in WireGuard. Time to switch to sodium.