Re: [Cfrg] Multi-recipient public key authenticated encryption
Paul Grubbs <pag225@cornell.edu> Mon, 27 April 2020 15:10 UTC
Return-Path: <pag225@cornell.edu>
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 40F193A0C6B for <cfrg@ietfa.amsl.com>; Mon, 27 Apr 2020 08:10:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cornell.edu
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 UdgGvD9yNcDR for <cfrg@ietfa.amsl.com>; Mon, 27 Apr 2020 08:10:41 -0700 (PDT)
Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FBFF3A0C5F for <cfrg@irtf.org>; Mon, 27 Apr 2020 08:10:40 -0700 (PDT)
Received: by mail-qk1-x735.google.com with SMTP id b188so16718001qkd.9 for <cfrg@irtf.org>; Mon, 27 Apr 2020 08:10:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cornell.edu; s=g.20171207; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2n6WRgCOj0csW7Sd4x8aFv5DBY0VtMGIiUrefrtlhxc=; b=G2xJAs8xfSss4/GQs15/2x3Oo7Zp3wJ2XN4w6hklV9kCSVIcJS6AUEJIfaIpgORuYi ATZfL+dgFCigSEweIPTWZUYcz3J90u3HvvRsuU828EpZfzjj4pI4Rbvb2PpXcwk9UqRG gZiWT84cTGirbaxzvhVIjvKRNADTYEGABdOMUp1O+0VWnw/WWdB+uQfzWfMU+x5x7spU gAF3OAGOkBUh+HQUncYoEBh8NFrxLQZ9QoUeM7olB+aNtk5MTfNlMTLB8/T7ldf8qOvS WA55CKsCli2EX/dkRsLubyeJV/6WRQWydX08FhbZ+cMoW+hMdJIxJan05Ugtn+9Z6P7f Qsxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2n6WRgCOj0csW7Sd4x8aFv5DBY0VtMGIiUrefrtlhxc=; b=NUpp+gwFcUdQA2tZQiJ9gjQ+/VfHlTCVbZQEwjY12PQAtsL7D7hXrMc9f3MHDxrTda ELOVOY50G5Znjn/HN1iCxe8Fh6UJEGfVp3rkG+CW8sPkZxU/2Ae6ysxZEdeRQIGuFv49 XXyGUOWU4XMsq2dP7yJIsSUcLoYrAVnf+e8YSBwSAJRgiL7yMG0jt4y/wGPKFgQ8APyx 9DkFsMI9EHtmDA+uynUCPpPZ5K3JViqluJgCcVP9EXpSwQ5oUDTMgVRQkTyr7dV9+Ukz 5uRb7Yg0jxysnSsEKb3FSYN9OS8Lx4ERxYS1bN+u7p2cAfmrF+NCqpqyGrwakFAiiWGA 21Rg==
X-Gm-Message-State: AGi0PuZT/uVf7lt0deJGKO7b/NuvtckyEVRLNggXGNALX5YXn/i18DeN 4nFHXwJkVgEYTYxWS/0N2OMW7cGdUpVH8eJpK0C08BWL
X-Google-Smtp-Source: APiQypKDIEoeJNYPKL64042+6kApoK83MtcXZZ4k7MrRmcMAK2/nlu5X78xKIBqCHu4zQipKM/EBdjE0S0Gwha/aj4E=
X-Received: by 2002:a37:9cce:: with SMTP id f197mr21220714qke.35.1588000237887; Mon, 27 Apr 2020 08:10:37 -0700 (PDT)
MIME-Version: 1.0
References: <AD42E3BB-8AF2-4FC9-9407-9A8D8D5130B4@gmail.com>
In-Reply-To: <AD42E3BB-8AF2-4FC9-9407-9A8D8D5130B4@gmail.com>
From: Paul Grubbs <pag225@cornell.edu>
Date: Mon, 27 Apr 2020 11:10:27 -0400
Message-ID: <CAKDPBw_CDUpwtPTbvxW9xSb3Yhgv=RNoAsOwyaZJRBNVvaHg1A@mail.gmail.com>
To: Neil Madden <neil.e.madden@gmail.com>
Cc: CFRG <cfrg@irtf.org>
Content-Type: multipart/alternative; boundary="00000000000015385205a4471e44"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/dozlhvLRhmm1diGil8ThUr4siO0>
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: Mon, 27 Apr 2020 15:10:44 -0000
This sounds like a really interesting question, but I'm having trouble understanding your proposed scheme - can you give a bit more detail? I also don't quite understand the threat model. Are you trying to prevent a malicious receiver from "forging" a new payload that looks like it came from the sender? On Mon, Apr 27, 2020 at 10:12 AM Neil Madden <neil.e.madden@gmail.com> 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