Re: [MLS] [Metadata encryption]

[Benjamin Beurdouche <[e-mail]>]

> On Oct 31, 2019, at 3:42 PM, Pascal Junod <[e-mail]> 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