Subject: [MLS] ChaChaX

From: Brendan McMillion <[email-masked]>
Date: Mon, 10 Aug 2020 11:02:34 -0700

Hello mls@

I wanted to quickly poll the list on a somewhat annoying issue. Currently,
every time we encrypt with our AEAD we use an unstructured nonce: sender
data encryption is properly random, while HPKE and message encryption use
the output of a KDF which is as good as random. Accordingly, we should be
using ChaChaX instead of ChaCha.

Does everyone else agree? Should I open these PRs?

---

From: Richard Barnes <[email-masked]>
Date: Mon, 10 Aug 2020 15:30:49 -0400

Hey Brendan,

I'm not sure I follow.  Could you clarify what you mean by ChaChaX, and how
it's different from base ChaCha?  Where by "base ChaCha", I mean RFC 8439.

https://tools.ietf.org/html/rfc8439

Thanks,
--Richard

On Mon, Aug 10, 2020 at 2:03 PM Brendan McMillion <brendan=
[email-masked]> wrote:

> _______________________________________________
> MLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mls
>

---

From: Brendan McMillion <[email-masked]>
Date: Mon, 10 Aug 2020 12:36:22 -0700

Sorry, I suppose the real name is XChaCha and it's defined here:
https://tools.ietf.org/html/draft-irtf-cfrg-xchacha-01

XChaCha has a 24 byte nonce and is meant to be more suitable for randomly
generated nonces

On Mon, Aug 10, 2020 at 12:31 PM Richard Barnes <[email-masked]> wrote:

> Hey Brendan,
>
> I'm not sure I follow.  Could you clarify what you mean by ChaChaX, and
> how it's different from base ChaCha?  Where by "base ChaCha", I mean RFC
> 8439.
>
>> I wanted to quickly poll the list on a somewhat annoying issue.
>> Currently, every time we encrypt with our AEAD we use an unstructured
>> nonce: sender data encryption is properly random, while HPKE and message
>> encryption use the output of a KDF which is as good as random. Accordingly,
>> we should be using ChaChaX instead of ChaCha.
>>

---

From: Richard Barnes <[email-masked]>
Date: Tue, 11 Aug 2020 15:53:27 -0400

Ah, thanks.  It seems like this is mainly a question of limits / how many
ciphertext you can send within an epoch -- you get more reuse with longer
nonces.  Cf. https://tools.ietf.org/html/draft-wood-cfrg-aead-limits-00

Note also that this primarily mattes for sender data encryption.  For
content encryption, you're effectively using a fresh key *and* nonce each
time, so you more space.

--Richard