Re: [lamps] Which PQC KEMs can be used for composite encryption?

Mike Ounsworth <Mike.Ounsworth@entrust.com> Thu, 16 September 2021 21:01 UTC

Return-Path: <Mike.Ounsworth@entrust.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 020A93A0876; Thu, 16 Sep 2021 14:01:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, 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=entrust.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 kI3vXjeNzdGg; Thu, 16 Sep 2021 14:01:24 -0700 (PDT)
Received: from mx08-0015a003.pphosted.com (mx08-0015a003.pphosted.com [185.183.30.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 89A113A0878; Thu, 16 Sep 2021 14:01:16 -0700 (PDT)
Received: from pps.filterd (m0242863.ppops.net [127.0.0.1]) by mx08-0015a003.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 18GFdDQS008524; Thu, 16 Sep 2021 16:01:14 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=entrust.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=mail1; bh=RUnV9RB3TQY1mCvIVW5IeRjlSlVkCFbV+HiFR/JPcnQ=; b=S/icrh8fbKggr+rL108M9wi0ads+A/QAlGu6jesgo3Kb1zNbob0rrnh8+GoxxFlkJ/E9 Zf/b4XRUuu6I1aL9mo73f+dqsiCmrx3lwVsZFzddcg6Gb586QIBSP07O5C6CMobDNETi 6W+4joB3BFpYXFKuQrY4GeC70Z0Z5i6rrk2LDevS1AQik5zi+g3wDn1+ijntm3v6xxIK FL9BeHJgdTRo4bAruCMzS1pp4Zx7EPByoV8x3zKU3jS28ATSt8PC4MdrPA+ZyRBuYDks EHBobuAnva23RmgiuBif1nsAa2UXgk+EOz0YJ48DHmbzQmYigLPqT6xRo3SBWuebHc3G mQ==
Received: from nam11-dm6-obe.outbound.protection.outlook.com (mail-dm6nam11lp2175.outbound.protection.outlook.com [104.47.57.175]) by mx08-0015a003.pphosted.com with ESMTP id 3b42u7ssah-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 16 Sep 2021 16:01:13 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GBNluaG4TNU6dvfnUsGLeV/w4iMq4CGhWu0KPUESp2gFnzS9BgGUvCTAyzmd5H+xxlr6Tr5M0atwwd4enRxnVthx2s2oL+z2jNQSySBmOUJo9ziRl5xqhPPbioG818M7lam3SQnGjahMpIdgjBp9JmqAKFIrBAxkPZq1pELAaSAdG1rA2Fao/PviiDoLcxYIQCMk2EuR2dE0MHatIeyNy68RlkIQfxZDPCj9+avZ4+wZB/nc9KtYTc28tRsJYBG5ZmqHT+9r5vxGr2PFlx7nyKSkSILEQiELjlIM4IEsa3ezD+H0jVCSCsXPXosQfc7HlZFJ0AY4r69blzQlnhPJ6A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RUnV9RB3TQY1mCvIVW5IeRjlSlVkCFbV+HiFR/JPcnQ=; b=cQoU4BF7LbbygBnxUhuTSjBcuC/a0vyWE6Y4oB+RTWvikFYjAMYZa9lVOl3AalP5tNECexxv9OXhSdJ7jG7PG1tNyn4HEJVBTG4poqtZGd/PvDB+lCMVfF6sM9Uck0bleF8/M2puabXijTp81aakBec0sMg4+vXAg4LR0dGKyMl0ORkaHj0uawXSvF196OLHlCUNGosnJp0JkqCvF4lZJLiMZBbcV52MbapRQlmEiFU+IxU0IgOWtGoh4CiCs05kaXcFDW6hlYwu2CrIaO+lRZ7+YZluzPi67VzrjLI9hMNbKt3HxWeRm0/H+4WGkNZXUHnyZ7L24ULPN8HcEt/tQQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=entrust.com; dmarc=pass action=none header.from=entrust.com; dkim=pass header.d=entrust.com; arc=none
Received: from CH0PR11MB5739.namprd11.prod.outlook.com (2603:10b6:610:100::20) by CH2PR11MB4485.namprd11.prod.outlook.com (2603:10b6:610:46::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4523.14; Thu, 16 Sep 2021 21:01:10 +0000
Received: from CH0PR11MB5739.namprd11.prod.outlook.com ([fe80::bcf2:571f:eb41:1737]) by CH0PR11MB5739.namprd11.prod.outlook.com ([fe80::bcf2:571f:eb41:1737%2]) with mapi id 15.20.4523.016; Thu, 16 Sep 2021 21:01:10 +0000
From: Mike Ounsworth <Mike.Ounsworth@entrust.com>
To: "Scott Fluhrer (sfluhrer)" <sfluhrer=40cisco.com@dmarc.ietf.org>, Ilari Liusvaara <ilariliusvaara@welho.com>, "Bruckert, Leonie" <Leonie.Bruckert@secunet.com>
CC: "spasm@ietf.org" <spasm@ietf.org>
Thread-Topic: [lamps] Which PQC KEMs can be used for composite encryption?
Thread-Index: AQHXqwL3463NCh8h3Um1K3U97SzuUKumubxA
Date: Thu, 16 Sep 2021 21:01:10 +0000
Message-ID: <CH0PR11MB57396E062999898D5CDC0B3B9FDC9@CH0PR11MB5739.namprd11.prod.outlook.com>
References: <e281b09a816e46d9a36a388c1e5ff6fa@secunet.com> <YUJBEi0mupUbcyvA@LK-Perkele-VII2.locald> <BL3PR11MB56822BD25C6CD932BC13CB14C1DC9@BL3PR11MB5682.namprd11.prod.outlook.com>
In-Reply-To: <BL3PR11MB56822BD25C6CD932BC13CB14C1DC9@BL3PR11MB5682.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none; dmarc.ietf.org; dmarc=none action=none header.from=entrust.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d3c1ccee-6963-44e0-d6b0-08d979551c9e
x-ms-traffictypediagnostic: CH2PR11MB4485:
x-microsoft-antispam-prvs: <CH2PR11MB44854D4AA4057AC330C2F0B49FDC9@CH2PR11MB4485.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: wzMzU9X+A/X89WeCfonI+WRjd+ov8IJGdx42/2IQ4fbA/zJfvvtn3SQysNlCqIzTxpNFA+zyS0BmlR50wiWOU+XbTKlIn7qklCIHRma+rQqeeIQIM95+KARDaKkPBD9WZX2vMU+lvLDxYlxiRoVJGmfwicDFKoJkA3MR7Ra6TqBPIhx1sipd9yhiX/SasE/a2YNZ3dfMNYhIVnwz9LikTx+i96SJKFJbfnJcmx/7lvf93xOyuBgD3HZKK+YHwlO6c5KYhujB5EASv43gRkWJLx0cFRHhYajzAFoEyS4Z6jPHpxpD9tyfy2IIzqhl3c/aMuK9Ah9KR7vOV5WRUEo36VZgeyWhJZVQeekulOsFSt7Fsh86PFFODhjKSjNlRJeESeK3929QVlAcinyjdty+Vhz2Hnrum5o9xIml8zhM5mE0thDJI3U6ba4SzMkTyVl7aQQJ3KjYCZ9iX6bStvoX7zGXCrLJVTrOneMW7d5S+QVgu9u7Edvv2NwUybA1G9X5QVT1T/pXWaYp9z4Q6DhIIxzu69YZ7/nnQbsfScwozt+qRq/qV3Xc/vUB0/kKW83NtsEf1imHmkP4kznO0Zi9UzTCXKfbdsqWIeWPA41KhPNcaKdacUj0fwEyQnekhcKe0ubyvIHumqAEKfq2Vw0ZLoK2EVJ+SvRd525fCEr15xifZRiuRLZIzAekfHUxMedrSZqUqzv2DUjn8jfjecny0tKze57pvPaGu1bcTE/ah++ml2tjE/PpT67uZkbGcuaXJrjHLrJQM4893RcU0uz+2of/V2RIKJKUWTtJRgQaeUE=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH0PR11MB5739.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(396003)(376002)(346002)(39860400002)(136003)(9686003)(55016002)(71200400001)(316002)(110136005)(122000001)(52536014)(53546011)(83380400001)(4326008)(7696005)(86362001)(5660300002)(478600001)(38070700005)(966005)(76116006)(66476007)(66556008)(66446008)(66946007)(64756008)(8676002)(26005)(186003)(33656002)(38100700002)(6506007)(8936002)(2906002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?KRLxw5D9YcdQl/ZxlR9Gh9xSRXyS/0x+Q3AGoM1dgyGDD9d8m8ZU4kScHi+r?= =?us-ascii?Q?p4QoZRaOj3OKsiErjVzVZSLEm0RjY9WijW2A+CtLiTa0wKqS/b4LaXx3+GBy?= =?us-ascii?Q?udqfZ9Ksr5PUA0YC8Z79XAT6KYo6OlUezP/R7BbtZNzKQIikyp8QgOgLJVi2?= =?us-ascii?Q?Ny20webpvPwRKJvLlDgG8law0MPdSOaARtP6A1UA/gWhD83KqXkpEChmGwta?= =?us-ascii?Q?Kac+TerxUOeXppX5Od9dJ4HcD/5TPXqwDu1/DlVdKoVjW+EUeay+UcXBKnrE?= =?us-ascii?Q?sSEGxPgX4ja96NGjDVOTGGSAL9UaN2IXWez+mlnh7ifNZexw07stJpgo1BTL?= =?us-ascii?Q?gQ9vk1tG8Y39ncBrTrK2gQ7QJ7FQziFCxutptBxtjPVy/qRqjU6iemHB3BNk?= =?us-ascii?Q?FZpqdl4ZdMgzOrbhTkK6NPAfLWRETL1vWk0/YcKAZhmtKtL/8HhfSQiFhNF8?= =?us-ascii?Q?7R1uGmkJPNzDiZM/g9ou0qmL/amRm8hrFaO3hpr+MzBw0e/ukfrHqAXA3Id6?= =?us-ascii?Q?4o1/ttog41GSMNbDy4HC17AzVeV1HVYp9cJPNABa24nyb45d7ls8Qv+DRjix?= =?us-ascii?Q?RCTNQ9L2OT467elc8Vfd3JbHlGQrSSeV1P4S568QwkL5xdtkeadnLJUk/ohA?= =?us-ascii?Q?NFYdv3t8dQUJMmY+pcja0KV15kOhKBf9SYt9sSnJdBLcpLWsYDYgOSLP6/xP?= =?us-ascii?Q?MwGEcckI6TDv4WH+3ZH2E2LRox/pVo+hzGSZsqCI2ndy3HrXJzk6CJ7Wp6M6?= =?us-ascii?Q?HLq6jZ8WyIu8kOOKoYUjqAsHsbOMLn7Xp6ojRF1T6jb2cEdaIaaAbxTC3kSg?= =?us-ascii?Q?kgLrAxCCU6gLByuz9P7rk75KgBFNk93hgXXlFqMj/1NcIW/FOQ+gJSuNeL1D?= =?us-ascii?Q?g3Y1CtHM2YTL28i3tst4Z5au+gQc5DDka2E6l25Nzofnl5i3dqj3l4J+YtAL?= =?us-ascii?Q?TBDcY82a7qFJJAU7jToefIwXs3ccArMo5bk1yr3O9s3neGJY8cktP4vQCuSp?= =?us-ascii?Q?P640ulAFqPsqH2Iv5QIgs6IUJhPtTPCsBXo0xw1icIkZRvhyVO9ujcipyh7u?= =?us-ascii?Q?7vHHgpO9laSqIXuT3JcF7+3U8ytSCgiHtZAtISKu/O0KpbJvx8G8I7J0Zhif?= =?us-ascii?Q?rqX9GQF8rPRvGioCp/+KjXEpBYHN5rsSiAtzmmkbqWb0ChdqKOvS2+UKTUXi?= =?us-ascii?Q?aPrrYd1uU2kTkGNbKi1EufPh9H6nIAa0GlKrbqpc6eIq9+PqOwiPa8aVaH29?= =?us-ascii?Q?Fs1Pz1LitjeGQThMdoa2nUXep4wDTHXB2zdyCVHBISFlz+EmrGxCbXTdcLPv?= =?us-ascii?Q?TwQ=3D?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: entrust.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CH0PR11MB5739.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d3c1ccee-6963-44e0-d6b0-08d979551c9e
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Sep 2021 21:01:10.7176 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f46cf439-27ef-4acf-a800-15072bb7ddc1
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: /r5xb9QDBQX/H6iihYY2kEEaZ/DoWkwJqwiO2vVdUQPvq6v6A+yoOYVXhFpS9+3z6l/8R9BuHBbKQ1Jm40VmCGdpuUMtyNSWq4aHfyPs4Hc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR11MB4485
X-Proofpoint-GUID: NTkZBnOSjOCmSsgU8Y80mb9ryn8lmcg5
X-Proofpoint-ORIG-GUID: NTkZBnOSjOCmSsgU8Y80mb9ryn8lmcg5
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.391,FMLib:17.0.607.475 definitions=2021-09-16_06,2021-09-16_01,2020-04-07_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 adultscore=0 clxscore=1011 mlxscore=0 phishscore=0 lowpriorityscore=0 suspectscore=0 impostorscore=0 bulkscore=0 malwarescore=0 mlxlogscore=999 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109030001 definitions=main-2109160121
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/B6_h_i05tF7F9ZM-eWbKl2rGECs>
Subject: Re: [lamps] Which PQC KEMs can be used for composite encryption?
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Sep 2021 21:01:29 -0000

Hi Scott,

Just to take a step back here for context; to start this discussion, we submitted three different composite key establishment modes:
1. Only encryptions
2. One or more encryptions + zero or more KEMs
3. Any combination of encryptions, KEMs, KeyExs. This mode runs everything through a KDF as per SP 800-56Cr2.

The differences between 2 and 3 is that Mode 2:
* Allows you to input a pre-existing CEK rather than have one derived, and
* Does not need to specify a KDF in composite-encryption params.

If you're suggesting to engineer out both of these benefits, then maybe it's better to just use mode 3? :)



Consider the CMS use-case where you have a message. You envelope it with AES. Now you have an AES key that you need to encrypt a copy of for each of the recipients. Modes 1 and 2 are intended to implement CMS KeyTransRecipientInfo using only the asymmetric primitives in the recipient's composite public key, and XOR, and an RNG. No KDF needed; no block / stream cipher needed. Can add them if necessary, but let's make sure they're necessary.

Mode 3 does not implement KeyTransRecipientInfo because the CEK falls out of doing all the separate key establishments and hashing them all together.

There was good debate at the interim about what interfaces a PQ CMS actually needs to implement .. KeyTransRecipientInfo? KeyAgreeRecipientInfo? Or should we define a new KEMRecipientInfo and just implement that, in which case we could shorten this draft down to only Mode 3.
If we decide to implement Mode 3 as a KeyTransRecipientInfo or KeyAgreeRecipientInfo, then we would need to include a block / stream cipher inside the composite-encryption primitive. If we define a new KEMRecipientInfo then we could decide to include that block / stream cipher at the CMS layer.
Let's start by deciding what interfaces we're trying to implement.



PS. From Kris and Marku's messages it sounds like the "KEM MUST produce IID shared secret" is fulfilled by all PQC KEMs and not actually a problem in practice. If we're bashing at the restrictions on Mode 2, I would like to bash at the requirement to have at least one encryption, and engineer a way to make it work with only KEMs.

---
Mike Ounsworth

-----Original Message-----
From: Spasm <spasm-bounces@ietf.org> On Behalf Of Scott Fluhrer (sfluhrer)
Sent: September 16, 2021 8:58 AM
To: Ilari Liusvaara <ilariliusvaara@welho.com>om>; Bruckert, Leonie <Leonie.Bruckert@secunet.com>
Cc: spasm@ietf.org
Subject: [EXTERNAL] Re: [lamps] Which PQC KEMs can be used for composite encryption?

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.

______________________________________________________________________
> So my question is: Do we know any PQC KEM that can be used with this
> mode?

I think we agree that we want something that can be used with any reasonable encryption or KEM primitive (even ones that haven't been invented yet), hence the requirement that this draft places on KEMs is too restrictive (even ignoring the valid points that Leonie brings up).

One obvious modification we could place on the draft is to send the output of any KEMs through a KDF.  Actually, sending everything through a KEM would mean that, even if only public key encryption algorithms are used, neither side could set the CEK to an arbitrary value.  The implicit API in the Generation Procedure doesn't support that (it assumes the CEK comes from the caller, that is, someone selects the value) - would it be an issue to change that?

Of course, the problem with specifying a KEM (apart from the added complexity) is that both sides need to agree on it.  One approach would be to have the public key contain a list of KDFs that the decryptor supports, and have the ciphertext include the KDF that the encryptor used.

Would this be a reasonable (if somewhat radical) change to the draft?

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!OB1peWGTjZaKFG0egYfcDknGBu2DIY1jRjK6AapXVE6XyM0urCN6I0a9AdeW3kTHPlPyBqiHyg$
Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.