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

Dan Brown <danibrown@blackberry.com> Mon, 27 April 2020 15:19 UTC

Return-Path: <danibrown@blackberry.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 AB4CB3A0C94 for <cfrg@ietfa.amsl.com>; Mon, 27 Apr 2020 08:19:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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=blackberry.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 WOcZ5yAbd8uh for <cfrg@ietfa.amsl.com>; Mon, 27 Apr 2020 08:19:46 -0700 (PDT)
Received: from smtp-pg11.blackberry.com (smtp-pg11.blackberry.com [68.171.242.227]) (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 947213A0C5F for <cfrg@irtf.org>; Mon, 27 Apr 2020 08:19:45 -0700 (PDT)
Received: from pps.filterd (mhs401ykf.rim.net [127.0.0.1]) by mhs401ykf.rim.net (8.16.0.27/8.16.0.27) with SMTP id 03RFIXxA134981; Mon, 27 Apr 2020 11:19:44 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blackberry.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=corp19; bh=hBSZ/0HChQ88m00GnHPVFoQnJ8k5h4RLCbai3ao/eMo=; b=TQsJNfYHXV1hEwcLfSOy5k168jmEW4QmvOdSJS2M20Kcl7EdtfvarWRTpoXwrm0QNMnC F+fN55iMqJDU2Typ4g/f8WmxjHEWPAwYlgWJ4fWeoaoYR9G9xuoTcGKyIekKxidit3mW EqX7D6O4ySh4yy/h+n3D6DbYvvW1VMHVoRcW/vAz1Bq5qdGsIdD+Klup7vDLHe0g1/jZ XUYYfH+VRxmZsJjgkAaluiGhMpDQpR9JmdedtcE4OmSzVEfMfNo0NKRQhAkCL1jb6giM dxXGRH46wESZun7HolsEP0GeW8hwFFtB/A1yLAHhYBiuQgsBlo9jZGv7pBFhuC1fqyuV qA==
Received: from xch210cnc.rim.net (xch210cnc.rim.net [10.3.27.115]) by mhs401ykf.rim.net with ESMTP id 30mgf5v341-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 27 Apr 2020 11:19:43 -0400
Received: from XCH210YKF.rim.net (10.2.27.110) by XCH210CNC.rim.net (10.3.27.115) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 27 Apr 2020 11:19:43 -0400
Received: from XCH210YKF.rim.net ([fe80::81ca:ad34:fc3:5ce8]) by XCH210YKF.rim.net ([fe80::81ca:ad34:fc3:5ce8%5]) with mapi id 15.01.1913.007; Mon, 27 Apr 2020 11:19:43 -0400
From: Dan Brown <danibrown@blackberry.com>
To: Neil Madden <neil.e.madden@gmail.com>, CFRG <cfrg@irtf.org>
Thread-Topic: [Cfrg] Multi-recipient public key authenticated encryption
Thread-Index: AQHWHJ3sAo0Oxh6TOE2cxrrC/lIO9KiNEqtA
Date: Mon, 27 Apr 2020 15:19:43 +0000
Message-ID: <429061fff35b4c3a910c948360ddd552@blackberry.com>
References: <AD42E3BB-8AF2-4FC9-9407-9A8D8D5130B4@gmail.com>
In-Reply-To: <AD42E3BB-8AF2-4FC9-9407-9A8D8D5130B4@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [100.64.97.99]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_01C9_01D61C85.B7E3DC40"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-27_11:2020-04-27, 2020-04-27 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/-r5mlf8R1aFf03TiRwWNkHwOjiQ>
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:19:51 -0000

Hi Neil,

I too have encountered this interesting and well-known (perhaps not widely-known) problem.

See https://eprint.iacr.org/2005/056.pdf. (Section 5).

See https://tools.ietf.org/html/rfc3278#section-4.1.2 the very short “note”.

 

I forget the details of the various claimed past solutions, but will try to remember, maybe in a couple weeks.  Meanwhile, since the problem is fresh in your mind, and you might try to make sense the couple of old suggestions above, though I expect your knowledge has already advance past this old stuff.   

 

Best regards,

 

Dan

 

From: Cfrg <cfrg-bounces@irtf.org> On Behalf Of Neil Madden
Sent: Monday, April 27, 2020 10:12 AM
To: CFRG <cfrg@irtf.org>
Subject: [Cfrg] Multi-recipient public key authenticated encryption

 

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://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dmadden-2Djose-2Decdh-2D1pu-2D03&d=DwMFaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=mf6j6fOClApRsArWE9wqI1rEGUVkfxZ0aXWmn35nK_c&m=pABr2aBl1c_ofW8vypgq6rz4tGVZWkxu0IU_RSNb_L4&s=E_agQvNgeBlLsyPF6xyJ1TFQLBAJsGTY1FJf7EK3iqs&e=> 

 

Kind regards,

 

Neil Madden

----------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.