Re: [MLS] [Metadata encryption]

Benjamin Beurdouche <> Thu, 31 October 2019 11:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 487B2120099 for <>; Thu, 31 Oct 2019 04:50:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vMFDTH4MOd9T for <>; Thu, 31 Oct 2019 04:50:00 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1B03B12001E for <>; Thu, 31 Oct 2019 04:49:59 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.68,250,1569276000"; d="scan'208,217";a="409781525"
Received: from (HELO pc54.home) ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Oct 2019 12:49:56 +0100
From: Benjamin Beurdouche <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F7BB76C3-A9BE-40F0-BFBE-BE3F3537FEDE"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\))
Date: Thu, 31 Oct 2019 12:49:56 +0100
In-Reply-To: <>
Cc: ML Messaging Layer Security <>
To: Pascal Junod <>
References: <>
X-Mailer: Apple Mail (2.3594.4.19)
Archived-At: <>
Subject: Re: [MLS] [Metadata encryption]
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Messaging Layer Security <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 31 Oct 2019 11:50:02 -0000

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 ?