Re: [MLS] [Metadata encryption]

Pascal Junod <> Thu, 31 October 2019 14:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 315451200FF for <>; Thu, 31 Oct 2019 07:42:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SNdrGBsKxrDv for <>; Thu, 31 Oct 2019 07:42:38 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 044B21200B8 for <>; Thu, 31 Oct 2019 07:42:38 -0700 (PDT)
Received: by with SMTP id p8so5615182ilp.2 for <>; Thu, 31 Oct 2019 07:42:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6ubR83+FjiWON+kjODzjw3sLoEsKqfW82LWILa2ervg=; b=T0xdxnAkMnsLaKa/J3UZef0s0bCMuYNnw0wTeKUAZGD+Lo+pCwEjeA4q24Ht9nnbJG 8U5C9pg8KbRBVaAJbB8aNXqfMNhjs2TcEW5WEicURE8F9x5BkYjPnXabVpnzTZmEbgQj fcjoXW8Z9RGv1WVFMIgpD0bDuHBTwjIpzBFBA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6ubR83+FjiWON+kjODzjw3sLoEsKqfW82LWILa2ervg=; b=Nc35gZkRlx57sq5V6gGz4RKtKXs9etyRdGV+bX4uLmj8xcNznq3UFusyVlddRPudy4 CZX7kVKpbM4W+L4+CqOOblvZoYpIkYx5gh4vu4eTWPYuDBDvWz0Vqns9nABUG28gkub8 FhX/dplxUayiIMgn1gWcYvQidx9VlRNEMZ5GilNAgqv/6tmc7nZ2+i67++iMTULon518 o9HSm0R/e6J/cx96TkkNLCV3ffKMKQoMXVG6b9c5MKH4DH1XAC5XetIEHs/y1jiYKp7m 7x+2ps81YL2p02oo2dZrTKGUwPD3mo8kgbc6VWWYjpBpM0w4N8ZnLlEDrNpEPwkwnqWu nZHQ==
X-Gm-Message-State: APjAAAWKVzV4UBtWx52kYGH/TSVA4skW6l+k0RY/juGO73DNwGTGIqdI 7qO5Rtp3LbmzQnuM+kMTrTAwc8xfuJ6+2Vt46uFtCQ==
X-Google-Smtp-Source: APXvYqzkauAYYjwKdmu6lEiG6ijTvfX9XC6IjSUBdFmbD6RdvvposeD9LZhP+RcENXRQVYfOf+76+6YQkrM1H6b+bgc=
X-Received: by 2002:a92:db0c:: with SMTP id b12mr6611919iln.71.1572532950569; Thu, 31 Oct 2019 07:42:30 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Pascal Junod <>
Date: Thu, 31 Oct 2019 15:42:19 +0100
Message-ID: <>
To: Benjamin Beurdouche <>
Cc: ML Messaging Layer Security <>
Content-Type: multipart/alternative; boundary="000000000000eac8ba059635db92"
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 14:42:39 -0000

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

- 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

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 ?



On Thu, Oct 31, 2019 at 12:50 PM Benjamin Beurdouche <> 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