Re: [MLS] reusing HPKE keys from welcome messages

Konrad Kohbrok <> Fri, 17 April 2020 08:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 470853A1077 for <>; Fri, 17 Apr 2020 01:23:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7A1dpPgu_Hz0 for <>; Fri, 17 Apr 2020 01:23:55 -0700 (PDT)
Received: from ( [IPv6:2001:67c:2050::465:202]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CFA363A1080 for <>; Fri, 17 Apr 2020 01:23:54 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 493TdM4VJJzQlHD for <>; Fri, 17 Apr 2020 10:23:51 +0200 (CEST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by ( []) (amavisd-new, port 10030) with ESMTP id iiy9GI1GhuyH for <>; Fri, 17 Apr 2020 10:23:39 +0200 (CEST)
From: Konrad Kohbrok <>
References: <> <>
Message-ID: <>
Date: Fri, 17 Apr 2020 10:23:39 +0200
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: de-DE
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 5B94517F6
X-Rspamd-Score: -5.25 / 15.00 / 15.00
Archived-At: <>
Subject: Re: [MLS] reusing HPKE keys from welcome messages
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, 17 Apr 2020 08:23:57 -0000

Ah, replied to the wrong mail. This was meant to be a reply to "somewhat better
PCFS for cheap". Sorry about that!


On 17.04.20 10:22, Konrad Kohbrok wrote:
> Hi everyone,
> nice catch! Although I have to say I'm surprised this is how it's currently
> defined in the draft. I just checked back in draft-8 (which is what we're
> currently analyzing) and back then it was like your proposed Option 2 (if I
> understand it correctly).
> I think deriving a key/secret from an HPKE private key is a very bad idea in
> terms of key separation. I must have missed this change and the corresponding
> discussion back when it got into the draft.
> What was the reason for the change from how it worked in draft-8 in the first
> place? If it doesn't break anything, I would very much like to adopt one of the
> options proposed by Joël & Sandro. If it does break something, we should still
> reconsider the current design.
> Cheers,
> Konrad
> On 17.04.20 09:47, Joel Alwen wrote:
>> Hey Everyone,
>> Sandro Coretti and I have a few suggestions. To keep threads on the list topic
>> specific I'm putting the suggestions in separate emails so please excuse the
>> spam. Here goes.
>> Issue: HPKE Key Reuse
>> Suppose Alice (commits to a proposal that) invites Bob to a group. For this she
>> uses a Key Bundle for Bob with an HPKE pub key in it. That pub key has 2
>> functions (and correct me if I'm wrong here). On the one it becomes the HPKE key
>> in Bob's leaf in the new ratchet tree. On the other hand, the Welcome message to
>> Bob is also encrypted to that HPKE key.
>> Problem: Bob must keep around the corresponding HPKE secret until he updates or
>> leaves the group. Thing is, that same HPKE sec key lets you reprocess that
>> welcome message. Ergo, until he does an update we have no FS for all MLS epochs
>> after his join. (See PS. at end of email for more.)
>> Proposed Solution: Separate HPKE keys for welcome message and initial leaf key.
>> E.g. Key Bundles registered on the Key Server have two HPKE keys. One for the
>> welcome message only and the other used as new leaf's HPKE key. As soon as Bob
>> processes the welcome message he deletes the HPKE key he used for it.
>> Thoughts?
>> - Joël & Sandro
>> PS. For those familiar, this is basically a special case of the FS issues with
>> TreeKEM we address with RTreeKEM in eprint/2019/1189. But normally attacks on
>> the FS of some TreeKEM epoch msg still requires u to somehow know the previous
>> epochs init_secret. Thats why, normally, FS attacks on TreeKEM "only" translate
>> to PCFS attacks on MLS. But for the welcome message variant that's different.
>> The whole point of the welcome message is to bootstrap from that one HPKE secret
>> key all the way to full-state MLS (including current key schedule). So the
>> attacker no longer needs an extra init_secret if they leak that one HPKE secret
>> key. Thus, this goes from the usual PCFS attack for MLS to being a plain FS one.
>> _______________________________________________
>> MLS mailing list