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

Mike Ounsworth <Mike.Ounsworth@entrust.com> Thu, 16 September 2021 14:31 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 4FA2B3A2B0F for <spasm@ietfa.amsl.com>; Thu, 16 Sep 2021 07:31:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.6
X-Spam-Level:
X-Spam-Status: No, score=-1.6 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, PDS_BTC_ID=0.499, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 n03Novx8U8xf for <spasm@ietfa.amsl.com>; Thu, 16 Sep 2021 07:31:15 -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 8BC3D3A2B13 for <spasm@ietf.org>; Thu, 16 Sep 2021 07:31:15 -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 18G8t5oR008028; Thu, 16 Sep 2021 09:31:13 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=entrust.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=mail1; bh=NtK2ETbfSABMIQqQAr/xyCyekchMeqjXn1Xiv161lpo=; b=FVIlt7Es3iY2q36ZyQKajg1thV+ukmngXZYQbR1q3nyEcMExlF5wOEYvXP2T0qy9RoUC yQliIqqef4pbnggGHDKkkZf2GfDV5WVkxNlhqgUZljRDT1aR3EVrmWK+ZW1uIHfGiLrH pq38FuUUAGtZwCx/ZGzX8E6gVJCCJD9DCkqGs9395V71XdHctbf2xQ/0rA/i3CNL7Vyl aBbQTnbr3ArM1UXFJ6c39KKQfgy+tsGoQhLmOQZ+14xcOoLd5MccD+JgvBx5gmwRrsEn uz0RTKo3lbBcvEZbMbno7cPEdAZTUpf6BRuRcr+QBs7sNkua2mhL8CkozeYB4n2JObFb Iw==
Received: from nam12-bn8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2175.outbound.protection.outlook.com [104.47.55.175]) by mx08-0015a003.pphosted.com with ESMTP id 3b42u7rsxt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 16 Sep 2021 09:31:12 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=R0N5FD/+RasvGUzWBlK9nI6XBHEQa7KIdeTiYp/xB1vZGRf2WEO/M35qNSGrv3O70KKzXdLQl0MoORcpvCUrfyVSYbn+dphhlr7yC4EJ3ve/ODKvlT51DM0ZaFfxHPaW30qaE96KOX52bgkXyOI36N76kwNlAxym9uJXrCX5NVFUdzW8hnmNWIJmPaf3/NHY81ONyh4dPffKq+TXl/9nTP9dHpNZPPDpAo/HeH2jgOdGMlLM7UF9JPftNzadcX+eGdHTmDVx5ns6eUwIWyemeRHVW8Y4ZwdLstDHLBctFGqxnmvIleros2C0Rw956r9KXkcn/U8RfSazLEaqbu4now==
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=NtK2ETbfSABMIQqQAr/xyCyekchMeqjXn1Xiv161lpo=; b=LvR8rTmfw3ejMvirMFRxGxt5QYNCN9oWbZQXaD5oQSXys66LfmLXZFSkotFsvvMMsGQshd1Cmj5n09kdrtoO7+IX6kwxrnfC0YMurcc/KQRng7vxlGNKlyVnOSYrX6Oz2SGSJkleAW8GLQ6mcMD9Xm7aNIEZh5hMi/RNHY3MK5/BHCFQXIDFt9khfgDJj9uRwW0no3iZZZSSY2TPAN1G6oiYw/Or75fYrkLmIzVv3Eei29DRDWu0HT9CqFMz8NdQPQ77l9UqQ7/ctJvRObcjPxISuaIkeVkZgvfmm06a/bgN4SpdtMBgL1ActdXmo174zb+9hjS/kPeE1LNArSQs6w==
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 CH0PR11MB5505.namprd11.prod.outlook.com (2603:10b6:610:d4::5) 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 14:31:09 +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 14:31:09 +0000
From: Mike Ounsworth <Mike.Ounsworth@entrust.com>
To: "Bruckert, Leonie" <Leonie.Bruckert@secunet.com>, "spasm@ietf.org" <spasm@ietf.org>
Thread-Topic: Which PQC KEMs can be used for composite encryption?
Thread-Index: AdeqG5+virMmP+tFQ5WeytN7CFzMdAAUNpvgABLwvFAAE325QA==
Date: Thu, 16 Sep 2021 14:31:09 +0000
Message-ID: <CH0PR11MB5739C371A3D63A7AE655C5129FDC9@CH0PR11MB5739.namprd11.prod.outlook.com>
References: <e281b09a816e46d9a36a388c1e5ff6fa@secunet.com> <CH0PR11MB57391CF716326E327E03D3569FDB9@CH0PR11MB5739.namprd11.prod.outlook.com> <ef10c291575f4b1287f99d2577a82c63@secunet.com>
In-Reply-To: <ef10c291575f4b1287f99d2577a82c63@secunet.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: secunet.com; dkim=none (message not signed) header.d=none;secunet.com; dmarc=none action=none header.from=entrust.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6218eee8-f8d6-40b3-d827-08d9791ea07e
x-ms-traffictypediagnostic: CH0PR11MB5505:
x-microsoft-antispam-prvs: <CH0PR11MB55056C84569E30131197C9179FDC9@CH0PR11MB5505.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: rvhzLNt1bagTP58hT+XjEuXVUwCk1LAwAartMt0GGFfuj0AA/w69cP9KaE3UEquqD886VM9L0UDkZGNT1/VYeepkEy+FtxPU3p6DeuZTWLJP2t1NXszchv0Iy3f5L1ybBOQwXtvatc2mmw3KI34GkjfQIb08k586GnskXUcET4jNuNijY0G+oIkI3Nvw4+1zoGJwUK7SQG20fk6exDLIDDTWlREwIN60M5vff4FxAei4wrxs8G3vMik+EdziLDF0SVP9XyCpQ0AG819BDxUJr8Wp9hKhjqx0u6VexROkjfvqtl/Cg83lTDQBwr5tZwRtyO3Fpzs2ui8+9klAuE+nPEp0leAZyuCOLFvwMoDkPP6FkuceyA7z1Px4D8nM7kYaK+nA4bzJxIHHbx8uffZF0vGo7HMU/9MDaFUPBuBkXL4ReAzBUyqiB26qFAa4M9f7O4wNS+XjhZttmQUrZhymgPsDvRA71AC8LllbcYTBwYrfzwRKUwARtXAiTjjJsNtQlU0Rd+qvOUuNFPQviiecrWYvRC9OFasJxxnpCalCdAnY2Xz6Ds+5RjY7pSIAFu2p4436j1wMa6ValfgqJv1QlVgxl66m6BmKzsKn7rri0CtVEpw4sQtAo8oo3gC35wQJXmTBJMLWkH5z1NC2lPJmjNX/oRNUIdT9oWctmycLuyq7+qNWmcTENG4jO/AvkXGvWHNrEbe6RyU8WO0zH+VFu5ifvOiURZrkV2D37kg6X9SWPNm9Yk0NnMaER4evqsa+O2jWU8PAC63A5B8GHRu/fmH/SBRsUKu5ErzYbYP40H4=
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:(346002)(136003)(366004)(396003)(376002)(39860400002)(52536014)(83380400001)(110136005)(66446008)(53546011)(316002)(66476007)(64756008)(66946007)(76116006)(66556008)(6506007)(86362001)(38100700002)(122000001)(966005)(2906002)(71200400001)(186003)(55016002)(478600001)(5660300002)(9686003)(7696005)(8936002)(26005)(33656002)(38070700005)(8676002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?utf-8?B?ODBIaDliWVFDazJPZFlSdVppQ01CNWcvUENIanFhNHJWSFp1RDBCdUNhRHUz?= =?utf-8?B?Y1ZQMVpuRk1URURSL1FRakJEclhSeUF5VmFTT09rSERJZGdXVTJPNE5NWkRG?= =?utf-8?B?WWFEZGFQdDBsa01DaGVuYlAxWHdZaW12MnJpWjBjRnBmUnp2T2F2VE5KNlY1?= =?utf-8?B?QzZ3RFpwVjdXUmlFOG9yR0V2bkNzMDU2RTNHZGhac3dIM3BoS3hlMDQyc1lt?= =?utf-8?B?YzhXZUIxdHdEK0NYRXBKdW9FNUdrRHJJclRicDJDUFQvUW13SkZMTlRmcm03?= =?utf-8?B?Mkl4aFlXYWJJSlc3UHlSUVRya09QbnMvZi9nQ0lhMkpKRXhoaWQ3amI5NFFl?= =?utf-8?B?TCtnd0RSUmV2VEkyRTRkbE12K1JnVVk2S212dEo5VFd1cWl6YUJyU1dOdjlV?= =?utf-8?B?ZEluSjFheEIra2FMWnBiSGhrYkIxSUEzYlA4ZlpvMGtWazNodzJSNmRwbCtQ?= =?utf-8?B?b0lNdCtjYTFZTFhFK2JESHo5anF4cGQzcVBaK3NsNHJQRENsNi96ZzBmVDQr?= =?utf-8?B?WWdtWFdxWHJmb2hCQU1INUFaVVhTU2JCUjhWNEV0ZHFpeFJnL0JMQ05YMHlO?= =?utf-8?B?YVFoWSs2K2c4M1g4Ym45RkJvKy90cFN1SHhrU3I4b2xXQmpzNStBVm1JSEFY?= =?utf-8?B?M0Zsb2xkOHN2NlNXeE9HMjZnc2doN2xlOXEzaUF6ZkRIOElZbmR2UHZPQnMy?= =?utf-8?B?R1pXdG1wQ0daOWJlZWNVMFRNRmtDcUFtOWwzNHU1bW1PU1l6RUVaa0VzWE8y?= =?utf-8?B?MnBYNjlYMmdmVmEwenRUTWRRQnNWWHFnMFlHcXFlQXlrcVd5c0RRUHIzVmxX?= =?utf-8?B?SzJ2YjljcWpVYi9kZjJIR0UvRGhGcEV1SldLaFBVbm91OGx2RThrRHI4VGxB?= =?utf-8?B?STYzSG9wbnYzb0lma1hXcEh5QThNVVRSUFE0N0Z4Q0hHVzFHNUZqZFlIY2JM?= =?utf-8?B?amhLKzQ0alFXWHZ1aStLeFNTOXdjc01RMFRGRGdKQysyekZZZU04amozNnNq?= =?utf-8?B?RFp4cHRBNjB1WHo0MzNMQlFCak05amMzdGoydVhJVUNIL2FmVHJYK1krdnhC?= =?utf-8?B?Sjd5UmYvaHZyRXZ3RUx1c05lV1hBeEVUVE9jYnFTZk5WelhEUklqWC91SzVu?= =?utf-8?B?OW1LVElieTNTSW5mazkzb0FkeHJxeSt0c05Kck95OXU0WTRGUmliczJQR1du?= =?utf-8?B?Ni9aSDUvSHIxL1RYVWxmWEZvTlVLd3NPR1FxN21SdUsrV0Q1aDdpZlhNWFNZ?= =?utf-8?B?UzhHUU5NaDZTU3BzUHZxYXV1R1QvVExnVVFaR2JtSE5aYk1jN0pha1NJWDFX?= =?utf-8?B?QTcrcHUrNCtYSHE2UzFmN0tXMEF5ZnhHbktTenRBMEpSbFlwSmkxMnhiZDc2?= =?utf-8?B?ZXBJbzR0ZWtKUjZDenlmVFlnWEt4WU1QQkxPZUdGR3krRlh2dExhU2lRanB3?= =?utf-8?B?VGhuTm0wZHpqUVVJSjZ2Q3FueXlPSTlXNVh6ZU15VEprdFRYSFQzRGtpREZO?= =?utf-8?B?bnpxZUF1UlB6bUdoNEJyUGMrWFFielQrTFNYb1BQR2JDVXcxS0R3RXlrdEZO?= =?utf-8?B?YXIwUXZrWDFUeEZxWURhVnhlaUxReGZ4TlZ0bXhwaVJlVWhZcHE5dTB6aGNO?= =?utf-8?B?bVBRQkNtZHZ6V1N0OTZVMEkxRTRNd0ZDZnh1eEw1U1NFUjJGMS9lejFNcmZz?= =?utf-8?B?b20vMWRaa0lCejFEZmxXZHd2b1RhMzBKenlyYW5KNUJUUWsxSUhKbk5FM2NQ?= =?utf-8?Q?MofDkf8Kje0iu1bR/9ncNRnS73/qnR5wTOpLRvW?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
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: 6218eee8-f8d6-40b3-d827-08d9791ea07e
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Sep 2021 14:31:09.7476 (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: 9fcO0xMyLZ31a6xXG5HxU9V5Kl0cwydqVOC3qp+mgJ08IFnDv8SzgEnbcdK0w1E4YkQW90bIAXktmN4pGi9j/BH7Nec3nrfpsHt00ZFWr28=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH0PR11MB5505
X-Proofpoint-GUID: 778sMwWzBfKjgbFtFAg4_fxYnOsNs0TP
X-Proofpoint-ORIG-GUID: 778sMwWzBfKjgbFtFAg4_fxYnOsNs0TP
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_04,2021-09-16_01,2020-04-07_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 adultscore=0 clxscore=1015 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-2109160093
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/vS5eP6Mlk5tSFkUF56QVmKjPAtw>
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 14:31:21 -0000

Thank you for the review Leonie šŸ˜Š

Maybe the wording (or variable names) of the encryption procedure could be improved for better readability. 

Here's a less formal description of the encryption procedure for mode 2; the intention is to transmit n encrypted values:


Input: CEK

# compute S1 .. Sn-1 and E1 .. En-1
for at least one encryption
  Si = CEK
  Ei = encrypt(CEK, Pi)

for each KEM (0 or more)
  Si, Ei = encaps(Pi)

En = CEK XOR S1 XOR S2 XOR ... XOR Sn-1

Output E1 ... En

We made the (maybe slightly odd) design decision that this mode requires at least one pure encryption scheme so that the inputted CEK can be directly encrypted. Not sure we love this design, but we submit it for discussion šŸ˜Š

---
Mike Ounsworth

-----Original Message-----
From: Bruckert, Leonie <Leonie.Bruckert@secunet.com> 
Sent: September 16, 2021 1:12 AM
To: Mike Ounsworth <Mike.Ounsworth@entrust.com>om>; spasm@ietf.org
Subject: [EXTERNAL] AW: 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.

______________________________________________________________________
Hi Mike,

Comments inline.

> Hi Leonie, thanks for starting this discussion.
> 
> I guess the Too Long; Didn't Read here is: Can we assume a KDF is 
> always included in a KEM encaps(), or do we need to do one explicitly 
> as part of composite-encryption?
> 
> I think (but could be wrong) that CCA security is orthogonal to 
> whether the KEM output (ie shared secret) can be used directly as a 
> symmetric key, or if it needs to be run through a KDF first. For 
> example, I could imagine a KEM that outputs an IND-CCA shared secret 
> prefixed with a fixed version byte; you can't use that directly as a 
> one-time-pad key because of the fixed version byte.

I am not an expert in KEM constructions either, but this sounds plausible.

> 
> That security consideration text is there because we've been 
> struggling to understand whether, with the KEM specifications that 
> will be standardized by NIST, the KEM would be expected to output a 
> shared secret that can be used directly as a one-time-pad (i.e. the 
> bits of the shared secret are a random key). If I'm reading your email 
> properly, you're advocating that a KEM's output should be hashed 
> together with some protocol-level contextual values before it's used?

That is not what I was trying to say. I rather observed that a KDF or hash function is incorporated in the NIST KEMs. I try to explain my thoughts in the next paragraph.

> As an example of a PQC KEM that should work, Kyber (as per the Round 3 
> submission docs) has a KDF as the last step of the CCAKEM algorithm:
> K := KDF(K||H(c))
> So, it should be ok to be used directly in our scheme.

Okay, let's take Kyber as an example, but you could easily think of another PQC KEM.
The 'K's in the formula above are actually not the same, so I added a '*' for clarification.

In
K := KDF(K* || H(c))
K is the final key that is returned by Kyber. It may be used directly for encryption. K* is a random value that is chosen by Alice. K* is encapsulated by Alice resulting in a ciphertext. This ciphertext is transmitted to Bob. Bob runs the decapsulation and gets K*. Both Alice and Bob use the KDF to derive the key K.

Now consider a composite encryption scenario where Alice wants to send a message to Bob. 
Bob owns a composite public key consisting of two component keys. Let's assume that the first component key can be used with e.g. Kyber. 

According to the draft, the content encryption key is split into two shares: CEK = S1 XOR S2. This is achieved by generating a random S1 and calculating the second share as S2 = CEK XOR S1.
While writing this, I just noticed that I overlooked the case distinction in the encryption process described in the draft. So, I think I do not have a problem here anymore. In case of KEMs the share is not randomly chosen, but output of the encapsulation (S1 =  K).

Then I am totally fine. Sorry for causing confusion. I misleadingly assumed S1 = K* which is of course nonsense. 

Regards,
Leonie

> The same should be true of SIKE KEM (Round 3 SIKE spec 1.3.11 
> Algorithm 2
> Encaps) as it also finishes by hashing everything.
> 
> The consensus at the LAMPS interim was to bring these discussions back 
> to RSA-KEM (5990). The KEM shared secret Z is not itself IID, so they 
> run it through a KDF (by itself) in Step 3 to be able to use it as a KEK.
> KEK = KDF (Z, kekLen)
> WK = Wrap (KEK, K)
> 
> 
> So we have two examples of compatible KEMs, and one that isn't 
> directly but could be made compatible. But we're not sufficiently 
> expert in KEMs to know if this applies only to some PQC KEMs, to all 
> PQC KEMs, or all KEMs present and future. Or, to your point, whether 
> this is actually how KEM outputs are intended to be used, or if you 
> need to hash them with protocol context values first. We believed, 
> from looking at the Kyber and SIKE construction that an extra KDF step 
> (and parameter) was unnecessary, but we're happy to add it if it 
> improves security or makes this mode more generally applicable to more KEM primitives.
> 
> I am eager to hear from people more expert than myself in KEM 
> constructions :)
> 
> ---
> Mike Ounsworth
> 
> -----Original Message-----
> From: Spasm <spasm-bounces@ietf.org> On Behalf Of Bruckert, Leonie
> Sent: September 15, 2021 5:23 AM
> To: spasm@ietf.org
> Subject: [EXTERNAL] [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.
> 
> __________________________________________________________
> ____________
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> Hi,
> 
> I recently looked into the composite encryption described in draft- 
> ounsworth-pq-composite-encryption, in particular option 2 (encryption 
> and KEMs).
> 
> If I understood correctly, the data encryption key is split into at 
> least two shares, each being encrypted/encapsulated under the 
> respective component public key.
> 
> I was wondering which PQC KEMs can be used with this mode. A 
> requirement mentioned in the draft is that
> 
> "all component KEMs MUST produce a shared secret whose bits are 
> independent and uniformly distributed (aka "uniformly IID"
> or "uniformly random" or "full entropy") and therefore the shared 
> secret is safe to use directly as a symmetric key."
> 
> As far as I know, the NIST candidates are IND-CCA secure KEMs where 
> the value being encapsulated is not directly used as shared secret. 
> Instead it is fed into a hash function together with some other values 
> (e.g. the public
> key) in order to receive the shared secret. Thus, I would conclude 
> that these KEMs are not qualified.
> 
> So my question is: Do we know any PQC KEM that can be used with this 
> mode?
> 
> If I use KEMs in a composite encryption mode, I certainly want them to 
> be CCA secure so I can use the public key multiple times. Otherwise it 
> won't make sense to put them in a certificate.
> 
> Please clarify if I am wrong with my thoughts.
> 
> Regards,
> Leonie
> -----BEGIN PGP SIGNATURE-----
> Comment: Using gpg4o v6.0.124.9651 - 
> https://urldefense.com/v3/__https://www.gpg4o.de/__;!!FJ-Y8qCqXTj2!IXB
> jLmZsx56eS923AqMx8DnfVF-JjqfE47JPJxm3e9u5b77DG6MGQAJq6ItjqqewGhTD$
> Charset: utf-8
> 
> iQIzBAEBCAAdFiEE3zFKr4OUJ0GHtLDCQlNDNDsJayMFAmFByYgACgkQQlNDN
> DsJ
> ayNu1w//W3mJD9LJ43KxEVv0t9etwv1Rw21ztRmb0biWskF1JJkxZIUmXBdb7
> MS9
> Sct7czMb/oNL/jrFqbiAHREwI2M5CVQ88v2YIGvA7T562amU3NBH/HbHZSwRe
> ByB
> nQlV+JmEEovHM75pasOEUGAYBVLG3smbRSNl0rQqk0hvCUPpWfuXxyVuxCY
> zaGu7
> XxvhfU0RSCE/e76xzf90WQQn1IylH8tCKrXST5+x+pxk2W2MkyNVzOqTBg7syc
> dg
> YJLLyK4aHm7emrlh6xOxSCVKVqsxKzGNV8/TRo/lvd3zhjTj6Ij5pLctBIgSHeA4
> rGSjqviKrMmFErnX3OeXgkPDNebQpxL0nrO7+vyJspzJ1C4SM2XQzvewjUSCa0
> gS
> 163eQI+ufvbEBp48BqGNcnrYPgjs+CIKvbcK4a5ETbtCT9HG+chED4v62x261YKw
> q6c6/1kEbd1hS3raaWKFEmhned2JP5WTGTu5/PARvA4hTqEaxnujBEF8qja3jz4
> Q
> NIwXSjtuOQGe+XVpNDGIYSCXDMWNSCdaDTXCuWuiWwYUvb5jad+qSpQCp
> nEe9AKB
> pQPgEV2Z0eIUB5FRBQwy27/ZWHzmL/VnJwb5MtuNg2cBNw+TBYCdaNo8KV
> 1uTeRP
> ASCIAvecw7809QAx4okUChvIBR/25qBJkGthNOLXnA9mqzINdGw=
> =Bqt8
> -----END PGP SIGNATURE-----
> 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.