Re: [MLS] Deniability as external to the MLS protocol

Natanael <> Fri, 13 November 2020 16:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D11F73A0EB6 for <>; Fri, 13 Nov 2020 08:27:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.133
X-Spam-Status: No, score=-0.133 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_DOTEDU=1.964] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vweynL4PSGAt for <>; Fri, 13 Nov 2020 08:27:53 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::543]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D54713A0EAA for <>; Fri, 13 Nov 2020 08:27:52 -0800 (PST)
Received: by with SMTP id cq7so11373009edb.4 for <>; Fri, 13 Nov 2020 08:27:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ELJtz0/BvAgDSt4SSLJtt2+ONK/+z/zUwRBozYc5R2s=; b=qa4HsJuXjOoC9k0Y1pngta2ofrjA2Dz466NrUt42cF1NHMojWmAMzXw8O0X5lsIypv gvcRwDrQXV23lSWWfKc3TEmBRLJA4e7w84m8BpGOy+0e2gH29jycyee1ReZ3RCAndlfU q1nO2k7dpLE3dcxvM0ZB3h3TjuzC/dRacE92ipSxzfpUdVmEXgRtLy9cwYCEU56WRrkj zfoX5lENEzdBbqhQkIVAMJnkmxHM541dURCWgGlZ8nNT9fsU9YAfldgQmL8DJ8bGneoA tI/HOxfUnGppnS52q+s/EqaAzsL1GvXyMzPeYhsGXfFgvBSIqx1SRMH5q1o7UidJ55vg YuXg==
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=ELJtz0/BvAgDSt4SSLJtt2+ONK/+z/zUwRBozYc5R2s=; b=eyl7KSm1xBa/l5PD/b9LcP5CuZng58h54xLxF+40xGk7gFBZnwKH9F3iGsaXt2RRvX ur6d1NH5Qqbg9dSJlUVfK4M30PM8uIRHQLEMR3cl4rnRwzb8Qelr2fJEYWR96uPzBXZB Vpno9UlfTjlfzllYmZo/8JIB38TmhrvmfbKK793H2zeHi9UiKlzA00rldT/s+50Alc3i md+q2quqmJs6h7JJOkC2h5SKUQa03N5h1K3xG3hwOAOmadS2IzieuQvxsuYuJwsSIKH+ R99Jl6HJRRu0qxykKOdd6kKiCPPxJ2jLIuPanBAtsYt7ZT04ORyp7WdqhHb0R3JLJFRC pFTw==
X-Gm-Message-State: AOAM532olCtrKyvHheU7ba/6h/0p8nXFaAT0Br4Jfxgnyj1DLa0+VEsO LDIQMC/WojvHTMsH9S9rdI++NeeEsSA5hvc6dEc=
X-Google-Smtp-Source: ABdhPJwFllDDRbwIBKVY1kvPu7Y3BUZZgXlhyY0uwLTzMvOY0EkAGBru6x8qUxgNDVizTZnYJL3znsf9+5XbxTPLHxk=
X-Received: by 2002:a50:fd19:: with SMTP id i25mr3168862eds.360.1605284866253; Fri, 13 Nov 2020 08:27:46 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Natanael <>
Date: Fri, 13 Nov 2020 17:27:33 +0100
Message-ID: <>
To: =?UTF-8?Q?Sof=C3=ADa_Celi?= <>
Content-Type: multipart/alternative; boundary="0000000000003768bd05b3ff82d4"
Archived-At: <>
Subject: Re: [MLS] Deniability as external to the MLS protocol
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: Fri, 13 Nov 2020 16:27:55 -0000

For deniable signatures I'd like to suggest taking a look at KeyForge (not
sure if it's ideal for MLS, see caveats below).

KeyForge was designed to make DKIM email header signatures deniable. It
uses a long term root key (good for usability and key management), and
derives a sequence of subkeys to be used for a certain period of time
(using signature context / tags) and then disclosed after use without
compromising the root key. Quote;

> At any given time, KeyForge can remain succinct because it generates a
neat tree of public/private keypairs where exposing a node’s private key
also results in also exposing that node’s children’s keys, but not it’s
parents. If you then tag each layer of the tree as a
Master/Year/Month/Day/15-minute “chunk”, you get something like this:
> KeyForge is a tree of keys, where revealing a node's private key will
also reveal all of it's childrens' private keys, but not its parents' keys.

> So, for this KeyForge layout, one can reveal the private key for, say,
December 2020, and it’ll result in all signatures generated from that
entire month being forgable.

Note that the simple way of doing this, adding in the MLS group context as
a tag, will make message contents deniable but leave proof of
participation. This has a security model very similar to the original OTR's
key disclosure mechanism.

Another way of doing this is by using the user's long term keypair with the
purely time based scheme to sign a group context specific message signing
keypair. This only proves the sender's identity to those who receives the
signature before the key is disclosed, so users who return after having
been offline for a while will need to request re-signing by those users
whose signatures they did not see in time.

Also keep in mind that for all variants of this which use time based tags,
your signature can be proven to be valid to non-participants within its
validity period.

If you want to guarantee that deniable context based signatures are always
fully deniable to non-participants, thus making both message contents and
participation deniable, then you need a method to derive a
per-user-and-group context for the signature where the signature context
tag itself can only be validated by participants but not by

Perhaps this can be done by using some kind of secure coin flip scheme
among participants and mixing it with the MLS group context. But I'm not
completely sure if this can be done securely, further research is likely

Den fre 13 nov. 2020 16:02Sofía Celi <> skrev:

> Dear all,
> As you know, we had many discussions on deniability and solving this
> problem is not an easy task, as evidence of this thread. To make sure we
> can work on this optional feature in the future, without modifying the
> core protocol, we believe that there are no changes needed to be added
> to the core protocol. Some minor relaxing of the phrasing in the
> document might be useful, though, and might help for future features as
> well, so I have submitted PR #437
> ( This rephrasing should
> allow deniability of application messages by allowing the usage of
> deniable signature keys. Please, let us know of any comments regarding it.
> Thank you,
> --
> Sofía Celi
> @claucece
> Cryptographic research and implementation at many places, but mainly at
> Cloudflare
> FAB9 3EDC 7CDD 1198 DCFD  4558 91BB 6B45 6F44 2D02
> _______________________________________________
> MLS mailing list