Re: [Cfrg] Multi-recipient public key authenticated encryption
Robert Moskowitz <rgm-sec@htt-consult.com> Wed, 29 April 2020 22:16 UTC
Return-Path: <rgm-sec@htt-consult.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC623A08A6 for <cfrg@ietfa.amsl.com>; Wed, 29 Apr 2020 15:16:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xli8zxl85eGB for <cfrg@ietfa.amsl.com>; Wed, 29 Apr 2020 15:16:50 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82FB43A08B7 for <cfrg@irtf.org>; Wed, 29 Apr 2020 15:16:42 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 9A5C36212C; Wed, 29 Apr 2020 18:16:40 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 1iYjhDTsBaSy; Wed, 29 Apr 2020 18:16:29 -0400 (EDT)
Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 0A5E362111; Wed, 29 Apr 2020 18:16:29 -0400 (EDT)
To: Neil Madden <neil.e.madden@gmail.com>, CFRG <cfrg@irtf.org>
References: <AD42E3BB-8AF2-4FC9-9407-9A8D8D5130B4@gmail.com>
From: Robert Moskowitz <rgm-sec@htt-consult.com>
Message-ID: <66029e0c-e541-c934-10b6-810b12c3df74@htt-consult.com>
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: <AD42E3BB-8AF2-4FC9-9407-9A8D8D5130B4@gmail.com>
Content-Type: multipart/alternative; boundary="------------6DE035DB39F9B504540DE41C"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/-S5aF4NjFYBoDmSJKmEUqq-khFQ>
Subject: Re: [Cfrg] Multi-recipient public key authenticated encryption
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=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]: https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-03 > > Kind regards, > > Neil Madden > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg
- [Cfrg] Multi-recipient public key authenticated e… Neil Madden
- Re: [Cfrg] Multi-recipient public key authenticat… Paul Grubbs
- Re: [Cfrg] Multi-recipient public key authenticat… Dan Brown
- Re: [Cfrg] Multi-recipient public key authenticat… Neil Madden
- Re: [Cfrg] Multi-recipient public key authenticat… Dan Brown
- Re: [Cfrg] Multi-recipient public key authenticat… Neil Madden
- Re: [Cfrg] Multi-recipient public key authenticat… Dan Brown
- Re: [Cfrg] Multi-recipient public key authenticat… Neil Madden
- Re: [Cfrg] Multi-recipient public key authenticat… Paul Grubbs
- Re: [Cfrg] Multi-recipient public key authenticat… Robert Moskowitz
- Re: [Cfrg] Multi-recipient public key authenticat… Peter Gutmann
- Re: [Cfrg] Multi-recipient public key authenticat… Neil Madden
- Re: [Cfrg] Multi-recipient public key authenticat… Peter Gutmann
- Re: [Cfrg] Multi-recipient public key authenticat… Neil Madden
- Re: [Cfrg] Multi-recipient public key authenticat… Peter Gutmann
- Re: [Cfrg] Multi-recipient public key authenticat… Andreas Hülsing
- Re: [Cfrg] Multi-recipient public key authenticat… Neil Madden
- Re: [Cfrg] Multi-recipient public key authenticat… Neil Madden
- Re: [Cfrg] Multi-recipient public key authenticat… pag225
- Re: [Cfrg] Multi-recipient public key authenticat… Neil Madden
- Re: [Cfrg] Multi-recipient public key authenticat… Paul Grubbs
- Re: [Cfrg] Multi-recipient public key authenticat… Paul Grubbs
- Re: [Cfrg] Multi-recipient public key authenticat… Mihir Bellare
- Re: [Cfrg] Multi-recipient public key authenticat… Phillip Hallam-Baker
- Re: [Cfrg] Multi-recipient public key authenticat… Mike Jones
- Re: [Cfrg] Multi-recipient public key authenticat… Neil Madden
- Re: [Cfrg] Multi-recipient public key authenticat… Neil Madden
- Re: [Cfrg] Multi-recipient public key authenticat… Neil Madden