Re: [MLS] [Metadata encryption]

[Pascal Junod <[e-mail]>]

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

On Thu, Oct 31, 2019 at 12:50 PM Benjamin Beurdouche <
[e-mail]> wrote:

> 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
>