Subject: [MLS] [Metadata encryption]

From: Pascal Junod <[email-masked]>
Date: Thu, 31 Oct 2019 12:35:19 +0100

Hi !

I have a question regarding the current draft and related to section 8.1:
what is the purpose of including the sender_data_nonce into the attached
data? To cover AEAD schemes relying on a non-randomized MAC, like, e.g., an
AES-CBC-HMAC construction ? Are there plans to support ciphersuites of this
type in the future ?

Best,

Pascal

---

From: Benjamin Beurdouche <[email-masked]>
Date: Thu, 31 Oct 2019 12:49:56 +0100

Hi Pascal !

> I have a question regarding the current draft and related to section 8.1: what is the purpose of including the sender_data_nonce into the attached data? To cover AEAD schemes relying on a non-randomized MAC, like, e.g., an AES-CBC-HMAC construction ? Are there plans to support ciphersuites of this type in the future ?

To decrypt messages, a member must
1. Look at the group_id and the epoch number to find the correct secrets to decrypt in its local state.
2. Determine which sender encrypted the message.
3. Compute or retrieve the correct sender-specific decryption key from its state.

Since we want to protect the sender data for privacy reason, we have to encrypt
it under a group key. That group key is outputed by the key schedule so is fully deterministic
and independent of the sender that will encrypt. Since everybody could use that key,
we want to avoid them to also use a deterministic nonce, so we use a random nonce
that we have to prepend in the header of the message.

Most, if not all other messages are encrypted under member specific keys in MLS, 
so nonce reuse is less of a problem except in the case state loss and we have a pending fix for it… : )

Does this make sense ?
Best,

Benjamin

---

From: Pascal Junod <[email-masked]>
Date: Thu, 31 Oct 2019 15:42:19 +0100

Hi Benjamin ! Thank you for you answer. Actually, it does not really
answer my initial question, so let me be more specific:

 - starting from the sender_data_key (computed in a deterministic way from
the group secret) and a randomly generated (for obvious nonce-reuse-related
reasons) sender_data_nonce, we would like to encrypt sender metadata using
the AEAD scheme (which is AES128-GCM in both currently supported
ciphersuites).

- An AES-GCM API takes a key, a nonce, data to be encrypted, and additional
data to be authenticated, but not encrypted.

- The data to be encrypted are the ones contained in the MLSSenderData
structure (senderID + generation)

- The additional data to be authenticated are the ones contained in the
MLSCiphertextSenderDataAAD structure (group_id, epoch, content_type and
sender_data_nonce).

Why is the MLSCiphertextSenderDataAAD structure containing the
sender_data_nonce ? That nonce will in any case "influence" the AES-GCM
authentication tag, so there is no need to repeat it as attached data to be
authenticated, isn't it ? What did I miss ?

A+

Pascal

---

From: Benjamin Beurdouche <[email-masked]>
Date: Thu, 31 Oct 2019 16:32:28 +0100

> On Oct 31, 2019, at 3:42 PM, Pascal Junod <[email-masked]> wrote:
> 
> Hi Benjamin ! Thank you for you answer. Actually, it does not really answer my initial question, so let me be more specific:
> 
>  - starting from the sender_data_key (computed in a deterministic way from the group secret) and a randomly generated (for obvious nonce-reuse-related reasons) sender_data_nonce, we would like to encrypt sender metadata using the AEAD scheme (which is AES128-GCM in both currently supported ciphersuites). 
> 
> - An AES-GCM API takes a key, a nonce, data to be encrypted, and additional data to be authenticated, but not encrypted.
> 
> - The data to be encrypted are the ones contained in the MLSSenderData structure (senderID + generation)
> 
> - The additional data to be authenticated are the ones contained in the MLSCiphertextSenderDataAAD structure (group_id, epoch, content_type and sender_data_nonce). 
> 
> Why is the MLSCiphertextSenderDataAAD structure containing the sender_data_nonce ? That nonce will in any case "influence" the AES-GCM authentication tag, so there is no need to repeat it as attached data to be authenticated, isn't it ? What did I miss ?

Ah, ok sorry I am a bit exhausted…
Since we have to send the fresh nonce for the recipient to decrypt the encrypted sender_data
we place it in the header. If you look at the message format on the wire, we have the practice of
authenticating the entire prefix of what’s encrypted (because we can).

Hopefully the visualization will help here (don’t mind new field it is a thing we introduced in PR208).

The nice thing of doing that is that you don’t have to “construct” the AADs, they already are right there for you.

Does that help ? (Hopefully I understood this time xD... )
Best,

Benjamin

---

From: Benjamin Beurdouche <[email-masked]>
Date: Thu, 31 Oct 2019 18:14:18 +0100

> On Oct 31, 2019, at 4:43 PM, Pascal Junod <[email-masked]> wrote:
> 
> It does help, thank you! Still, the SenderDataAAD window could stop with "new field", this would decrease the number of AAD hashed bytes by 12 and be somewhat consistent with the ContentAAD window that does not contain the content nonce, right ?

Stylistically, maybe we could, but I liked having the explicit nonce under AEAD
just in case a malicious insider wants to play with it in some fancy ciphersuite.
It basically doesn’t cost much in terms of performance but might help us with
unforeseen cornercases … : )

B.