Re: [MLS] reusing HPKE keys from welcome messages

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 713DB3A107C for <>; Fri, 17 Apr 2020 01:22:36 -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 JqcCwO3oQgvr for <>; Fri, 17 Apr 2020 01:22:34 -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 5B06A3A1078 for <>; Fri, 17 Apr 2020 01:22:31 -0700 (PDT)
Received: from ( [IPv6:2001:67c:2050:105:465:1:2:0]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 493Tbn3NXDzQlJR for <>; Fri, 17 Apr 2020 10:22:29 +0200 (CEST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by ( []) (amavisd-new, port 10030) with ESMTP id BgH-VInzR5y7 for <>; Fri, 17 Apr 2020 10:22:24 +0200 (CEST)
References: <>
From: Konrad Kohbrok <>
Message-ID: <>
Date: Fri, 17 Apr 2020 10:22:24 +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: 42F45174A
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:22:37 -0000

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.


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