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

Neil Madden <neil.e.madden@gmail.com> Mon, 18 May 2020 10:36 UTC

Return-Path: <neil.e.madden@gmail.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 647383A0A9B
for <cfrg@ietfa.amsl.com>; Mon, 18 May 2020 03:36:37 -0700 (PDT)

X-Virus-Scanned: amavisd-new at amsl.com

X-Spam-Flag: NO

X-Spam-Score: -0.196

X-Spam-Level:

X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5
tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,
DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.001,
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=gmail.com

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 lZgQ4RIwsnSp for <cfrg@ietfa.amsl.com>;
Mon, 18 May 2020 03:36:34 -0700 (PDT)

Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com
[IPv6:2a00:1450:4864:20::432])
(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 59E8C3A0A98
for <cfrg@irtf.org>; Mon, 18 May 2020 03:36:34 -0700 (PDT)

Received: by mail-wr1-x432.google.com with SMTP id y3so11254769wrt.1
for <cfrg@irtf.org>; Mon, 18 May 2020 03:36:34 -0700 (PDT)

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=from:message-id:mime-version:subject:date:in-reply-to:cc:to
:references; bh=P9qw9X4HN+GSNlXCWqrCpzzFBjRJb/euL7MApZAtw+o=;
b=Rn99ByWeaAmgk2YYQnFNHWviEDKhY0L7fl6OvwJUkwyL2EmqXhLv8wqT3/TIaw8PTm
LgaXer4CGCNYxhOBAKZTdwjxHdcNudBZaAN0U1oURIMFUlj5uCbSQxpBu/yXIjWWwitq
6Bey3gJHIYD+5MsTDbGWKvOEEzNlcHy2KTgi58ZnAy1eDH7INqGgrM731Yz7up53qd4k
TDw6TwnNFPCZX9hOwp9+rgKoJYvHTabw/VRPEGh5x5LIHUtPclr8MMb853WU90IjzeLg
WdM8VYk/fWmGbzCV9Pe9d9Pj9N+p3q/yPU0lnIaVhWEb4UwmLaGPMmInZ6zW2n0oLFxi
8pdQ==

X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:message-id:mime-version:subject:date
:in-reply-to:cc:to:references;
bh=P9qw9X4HN+GSNlXCWqrCpzzFBjRJb/euL7MApZAtw+o=;
b=SuRiFI2njPazWQ8m9vxuRNBPxuVPRDEJkVIz43jFiFCGjUt5IOTllMSGxwiSR3s1kf
jms4ZtRb0GmkoGOmRjUWSvUN0J7kexTDh9FaseSbJ2T1vYo9awXkew+2Cr1VLWR/vLV9
E6jCAZC8xYsXS/EuyTvA9tpj5VIvTg4w+qaVu9EyAcz2RbD9ZuKP974ucY+Z8x0onwRI
JGlqEPcqroeGUXzsDomQLZKKP7cICaZhESB2lfk2gS3oRUgOJNZDZk4gCKou1DUUjMT8
GuZewidsj2Zr5hP1ow5vPorpNtcesrBOtZ13NEdBxywEM1PrM+boxDeR2jLDFLslq4Ta
tUmw==

X-Gm-Message-State: AOAM532FhSK6BocPnIQ+uv/DisPXoBfhXLlvIyvXHwCThPGo8vf+9DfS
/kO8flT5p1RxhVtQOKZl6BCsqu+z

X-Google-Smtp-Source: ABdhPJyAHW0V9EpKjL0gadwxOkOJsWhU+te8q1+Ped/VOJM/ItA5wDP07p8Gb6PKsclAAEBFOpoGsw==

X-Received: by 2002:a5d:4b0a:: with SMTP id v10mr17932933wrq.33.1589798192691;
Mon, 18 May 2020 03:36:32 -0700 (PDT)

Received: from [10.0.0.2] (181.58.93.209.dyn.plus.net. [209.93.58.181])
by smtp.gmail.com with ESMTPSA id 88sm15417362wrq.77.2020.05.18.03.36.30
(version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
Mon, 18 May 2020 03:36:31 -0700 (PDT)

From: Neil Madden <neil.e.madden@gmail.com>

Message-Id: <79C8ED84-E92E-44FE-BA27-1F5B7135CE4D@gmail.com>

Content-Type: multipart/alternative;
boundary="Apple-Mail=_146717BF-8DDE-4FCE-B91B-914158620D80"

Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))

Date: Mon, 18 May 2020 11:36:30 +0100

In-Reply-To: <CACEhwkQjurUG9mXbB7JyhJS+_WUO=VXo3w4DNenMrLt+aJanJQ@mail.gmail.com>

Cc: CFRG <cfrg@irtf.org>

To: Mihir Bellare <mihir@eng.ucsd.edu>

References: <AD42E3BB-8AF2-4FC9-9407-9A8D8D5130B4@gmail.com>
<CACEhwkQjurUG9mXbB7JyhJS+_WUO=VXo3w4DNenMrLt+aJanJQ@mail.gmail.com>

X-Mailer: Apple Mail (2.3608.80.23.2.2)

Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/6dQiyrTyyCd0wFBRV-7nn4c5fns>

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, 18 May 2020 10:36:37 -0000

Apologies for the delay in replying. I am still digesting the paper you suggested. It is very interesting and informative, thank you. I think the notions in section 3 do capture a lot of what I’m aiming for, but I have a question about the meaning of “non-repudiation”. On page 10 in the paragraph on “Capturing outsider authenticity” you write, regarding insider security: "This, in particular, implies that SC assures non-repudiation, meaning that the sender cannot deny the validity of a ciphertext it sent to a recipient (since the knowledge of the recipient’s secret key does not help to produce a forgery).” To my mind, that term (non-repudiation) is strongly linked with 3rd-party verifiability - that is, if Bob receives a message from Alice she not only can’t deny to Bob that she sent that message, but she also can’t deny it to any other 3rd party. For example, this is the definition of non-repudiation given in [1] (section 13.7.5.2): "Suppose Alice encrypts a message m to Bob and obtains the ciphertext c. The question is, does c, together with Bob’s secret key, provide Bob with enough evidence to convince a third party that Alice actually sent the message m to Bob? We call this property non-repudiation." In the scheme I proposed, each recipient is assured of the authenticity of a (K, T) pair where K is an ephemeral secret key used to encrypt and authenticate the message contents, and T is the (compactly committing) MAC tag for that message. Assuming that K is chosen fresh for each message, then each recipient is assured that the message came from the original sender and that no other recipient is able to produce a different message and claim it came from that sender, even though they have access to K. But crucially, no recipient can prove to any 3rd party (who is not in the recipient list) that Alice really did send this message. Within the group of recipients something like non-repudiation does hold - Alice has provided a commitment to each of them of the contents of the message in the form of the MAC tag. So if Alice sends a message to Bob and Charlie, then Bob can prove to Charlie that Alice sent him the message, but he cannot prove the same to Doris (who wasn’t in the original recipients). Does your definition of signcryption insider security imply Boneh & Shoup’s definition of non-repudiation, and so 3rd-party verifiability? Or would the scheme that I’ve sketched also meet this goal? [1]: https://toc.cryptobook.us <https://toc.cryptobook.us/> (Boneh and Shoup, A Graduate Course in Applied Cryptography) Kind regards, Neil > On 8 May 2020, at 21:48, Mihir Bellare <mihir@eng.ucsd.edu> wrote: > > Public-key authenticated encryption is, I think, what in the literature is called Signcryption. > While early formulations were single recipient, a multi-recipient formulation is given in Section 3 of https://eprint.iacr.org/2020/224 <https://eprint.iacr.org/2020/224> > This defines security goals of privacy, authenticity, and one that combines them, in two forms, insider and outsider, depending on whether or not the adversary is a key holder. > It sounds from what you say that what you want may be insider security. > The above paper does not give schemes of the form you give. My question is that, perhaps, do the definitions capture what you want to target? > > Mihir > > > > On Mon, Apr 27, 2020 at 7:12 AM Neil Madden <neil.e.madden@gmail.com <mailto: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 <https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-03> > > Kind regards, > > Neil Madden > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org <mailto:Cfrg@irtf.org> > https://www.irtf.org/mailman/listinfo/cfrg <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