Re: [MLS] Deniability without pairwise channels.

Raphael Robert <> Wed, 22 January 2020 15:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1424912087C for <>; Wed, 22 Jan 2020 07:54:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bmGSID_j0TtJ for <>; Wed, 22 Jan 2020 07:54:46 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D4287120639 for <>; Wed, 22 Jan 2020 07:54:45 -0800 (PST)
Received: by with SMTP id f129so7729836wmf.2 for <>; Wed, 22 Jan 2020 07:54:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wesCKHUbh35VVA78IwLSmw87fd1d4DzNLO9+HKAoSF8=; b=hpmZ9KcR1fWgowdTU7iTk+F9sbgC1lFcvKjbtmw/SbgXWcN/7yMTjG6GfLeEEUX3iX kOdDn0TrIV1BttG+m1PjkhjqY81TPVRvDZPJhJq1MFMpGfNekaIN59WJ3S9XLiFD9N8m 0D0PBlNIscjdVEbUMWuBvIXzTM9M0OwA3Lf6AXY45P7Ow0dYwrTvjmiZ+fecod3Alz5I sihpGXm29fn7N3pMk4rihKhNbNxPg/foTr8p3L8QqNZEF8fgiw2SPzlPuTkw7GKbK/yy pKMsMqh6VnkzbBiPp94i+WIHprfd51Tc7wtWMbTjtW7erTc0QPJj7yF9FG1sT6sjgwF4 +86g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wesCKHUbh35VVA78IwLSmw87fd1d4DzNLO9+HKAoSF8=; b=T40Ox8vKZsP8Qksoxen4b+Gn9vHm44CNW2IfFWFV/ii5tpylyL6AJEDu50zgW7JKUH zYuINfooRWAgkGVRxKiUXJoy4QVV2tQoPd3/0Nkas1n8SycvsVHmOzMzdBTvI0XJ/Mfy wJ/8ZdGswvIxVB/UiJ2ekpUQCIGETkMYLQZ/viOpAdU6HO8KUT+fd2JR0R9k2WL51tXk wNH3gvEKfE+RGs1oH2fJbzkXG+YUMtHQSA1vvjbKwKkYbt4rhivdK2SkIpVqyJo97Piv PRMAzEqo2tODgr+Vdt+mCBx267asFrb7Apz+uWGZBN1ZacWK60rAzV83zFSoAZPGLwF5 zTtA==
X-Gm-Message-State: APjAAAXkWjwqleZqSGLYTtr8YCW4VJx7vljTg2UsSVSMtTaCYL4icyXC T3dMNcNpHN7LXPESMZTi5+dDcmJwmz+ELg==
X-Google-Smtp-Source: APXvYqzPpHX1sFNwJtMjvfRALtjyoINs69flr+3fCvdTtsO8fSuu9IsiUPwNzLVGE4e+QaVpkwe5cQ==
X-Received: by 2002:a05:600c:2042:: with SMTP id p2mr3788654wmg.79.1579708484203; Wed, 22 Jan 2020 07:54:44 -0800 (PST)
Received: from rmbp.wire.local ( []) by with ESMTPSA id 124sm4835512wmc.29.2020. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Jan 2020 07:54:42 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.\))
From: Raphael Robert <>
In-Reply-To: <>
Date: Wed, 22 Jan 2020 16:54:41 +0100
Cc: Messaging Layer Security WG <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Mathias Hall-Andersen <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [MLS] Deniability without pairwise channels.
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: Wed, 22 Jan 2020 15:54:54 -0000

Hi Mathias,

For general context: Deniability is something that is being discussed right now and we should send some update to the list as soon as we have sorted things a bit better.

I hope I understood your correctly, you are essentially proposing a “sign & reveal” scheme. If not, I’m sorry, and please let me know.

What has become clearer in some of the discussion is that a “sign & reveal” scheme puts the burden of proof on the victim to some (large) extent. The attacker can publish a signature chain that starts with the public identity of the victim and ends with the signature of a specific message. This signature chain will most likely look valid to a third party at first sight. It then becomes the duty of the victim to prove that they indeed published secret keys and that therefore anyone could have signed the last part in the signature chain. For the victim, this is painful at best and impossible at worst. It would be much nicer if the attacker couldn’t publish such a signature chain in the first place.

There might be another problem, regarding synchronicity: since MLS is completely asynchronous no one should publish a secret key too early (i.e. before others have consumed the encrypted messages) otherwise we might not be able to trust the authentication any longer. 

But I fully agree that your proposal is obviously much more efficient than a 1:1 fanout.



> On 22 Jan 2020, at 15:34, Mathias Hall-Andersen <> wrote:
> Dear MLS group,
> In MLS: since all group members share the same secret,
> the application of an AEAD does not provide authentication within the group,
> MLS mitigates this using sign-then-encrypt with a long-term signing key.
>> [[ OPEN ISSUE: Signatures under the identity keys, while simple, have the side-effect of preclude deniability.
>> We may wish to allow other options, such as (ii) a key chained off of the identity key,
>> or (iii) some other key obtained through a different manner,
>> such as a pairwise channel that provides deniability for the message contents.]]
>> -- Section 12.2 Authentication
> If deniability (without pairwise channels) is a desired feature in MLS,
> has the group discussed the feasibility of applying a "sign & reveal" type scheme?
> There are essentially two different options:
> 1. Short-term credentials:
> Clients would generate temporary "credentials" pk_{temp} for the group,
> by creating a certificate under their long term credential pk_{long term}:
> S <- Sign(sk_{long term}, <Group Identifier, Expiry, pk_{temp}>)
> Publish (S, pk_{temp}) to the group.
> Then when sending messages apply sign-then-encrypt using the short-term credential:
> S_{msg} <- Sign(sk_{term}, m)
> c <- Seal(k, .., .., <S_{msg}, m>)
> Later, e.g. in lock-step with updates to the ratchet tree,
> the client publishes sk_{temp} to the group and generates a new short-term credential.
> 2. One-time credentials:
> When sending messages apply sign-then-encrypt using a one-time credential:
> S_{cert} <- Sign(sk_{long term}, <Group Identifier, Message Index, pk_{temp}>)
> S_{msg} <- Sign(sk_{term}, m)
> Then encrypt:
> c <- Seal(k, .., .., <S_{cert}, S_{msg}, sk_{old}, m>)
> Where k is the group key and sk_{old} is the sk_{temp} from the previous message.
> Best Regards,
> Mathias
> _______________________________________________
> MLS mailing list