Re: [Cfrg] Multi-recipient public key authenticated encryption

Robert Moskowitz <> Wed, 29 April 2020 22:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0DC623A08A6 for <>; Wed, 29 Apr 2020 15:16:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Xli8zxl85eGB for <>; Wed, 29 Apr 2020 15:16:50 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 82FB43A08B7 for <>; Wed, 29 Apr 2020 15:16:42 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9A5C36212C; Wed, 29 Apr 2020 18:16:40 -0400 (EDT)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id 1iYjhDTsBaSy; Wed, 29 Apr 2020 18:16:29 -0400 (EDT)
Received: from (unknown []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 0A5E362111; Wed, 29 Apr 2020 18:16:29 -0400 (EDT)
To: Neil Madden <>, CFRG <>
References: <>
From: Robert Moskowitz <>
Message-ID: <>
Date: Wed, 29 Apr 2020 18:16:27 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------6DE035DB39F9B504540DE41C"
Content-Language: en-US
Archived-At: <>
Subject: Re: [Cfrg] Multi-recipient public key authenticated encryption
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 29 Apr 2020 22:16:53 -0000

I am probably missing something here,,,

but this sounds like the problem MLS is solving?

Multiple recipients of an encrypted message.
Proof of single sender.

They had to invent? the ratchet tree.


On 4/27/20 10:12 AM, Neil Madden wrote:
> Hi all,
> I am working on an enhancement to the JOSE standards and would like 
> feedback from members of CFRG about solutions to a particular issue if 
> any of you have time.
> In JOSE currently if you wish to create a message that has both 
> confidentiality and sender authentication using public key 
> cryptography then the only option is to both sign and then encrypt the 
> message. This is expensive because it involves multiple passes over 
> the message and results in a very bulky nested message structure with 
> two layers of base64-encoding.
> Given that many uses of this sign-then-encrypt pattern do not require 
> the strong security properties of signatures, I have proposed [1] a 
> public key authenticated encryption mode based on NIST’s one-pass 
> unified model from SP 800-56A. This avoids the nested structure and 
> means that you don’t need multiple cryptographic primitives. The 
> proposed algorithm uses two ECDH key agreements: one between the 
> sender’s ephemeral private key and the recipient’s long-term public 
> key; and a second between the two parties’ long term keys. The two 
> shared secrets are concatenated and passed through a KDF along with 
> some context arguments. For a single recipient this achieves sender 
> authentication (subject to replay), and the single recipient case is 
> what I am primarily concerned about.
> (If you squint this is also roughly similar to the Noise framework “K” 
> one-way pattern, but my hands are waving quite a lot here).
> To support multiple recipients I copied the existing pattern used in 
> JOSE’s ECDH-ES+A256KW algorithm family in which the message is 
> encrypted using a random Content Encryption Key (CEK) and then the CEK 
> is encrypted for each recipient using AES-KeyWrap with the 
> ECDH-derived key. As I then mention in the security considerations 
> this leads to any recipient being able to produce a forgery using that 
> CEK and claim it came from the original sender:
>     When Key Agreement with Key Wrapping is used, with the same Content
>     Encryption Key (CEK) reused for multiple recipients, any of those
>     recipients can produce a new message that appears to come from the
>     original sender.  The new message will be indistinguishable from a
>     genuine message from the original sender to any of the other
>     participants.  To avoid this attack, the content SHOULD be encrypted
>     separately to each recipient with a unique CEK or a nested signature
>     over the content SHOULD be used.
> Because I am primarily interested in single-recipient use cases, this 
> seemed like an acceptable trade-off. However, I have since been 
> contacted by people who would like to use this draft for 
> multi-recipient messages and would not like to fall back on a nested 
> signature structure.
> An initial proposal was to solve this by simply including the MAC tag 
> from the content encryption in either the per-recipient payload 
> (encrypted using AES-KeyWrap) or as an additional context field to the 
> KDF. But the MAC is computed using the CEK that is known to all 
> recipients, so for this to be secure would require second preimage 
> resistance of the MAC with a known key, which cannot be guaranteed for 
> JOSE because it supports content encryption using AES-GCM for which 
> second preimages can be trivially computed if you know the key.
> Assuming that a per-recipient MAC is too much overhead, an alternative 
> would be to include a collision-resistant hash of entire ciphertext 
> (and IV and associated data) in the KDF. This is unfortunate as it 
> requires another pass over the entire message when we’ve already 
> encrypted and MACed, but it appears to be a solution and at least is 
> no more inefficient than the original signed-then-encrypted approach 
> which also needs to hash the entire message.
> So two questions:
> 1. Is including a hash (e.g., SHA-512) of the ciphertext (assuming 
> symmetric AE) in the per-recipient KDF calculation sufficient to 
> prevent forgeries in the multi-recipient setting?
> 2. Are there more efficient alternatives that don’t assume 2nd 
> preimage resistance of the underlying symmetric MAC?
> [1]:
> Kind regards,
> Neil Madden
> _______________________________________________
> Cfrg mailing list