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

Kris Kwiatkowski <kris@amongbytes.com> Thu, 16 September 2021 13:21 UTC

Return-Path: <kris@amongbytes.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 DF2F33A28D2 for <spasm@ietfa.amsl.com>; Thu, 16 Sep 2021 06:21:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 kvnKiFcNHUgX for <spasm@ietfa.amsl.com>; Thu, 16 Sep 2021 06:21:51 -0700 (PDT)
Received: from 10.mo174.mail-out.ovh.net (10.mo174.mail-out.ovh.net [46.105.58.75]) (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 7D3C83A28D0 for <spasm@ietf.org>; Thu, 16 Sep 2021 06:21:50 -0700 (PDT)
Received: from mxplan8.mail.ovh.net (unknown [10.109.138.142]) by mo174.mail-out.ovh.net (Postfix) with ESMTPS id 23592F98B79E for <spasm@ietf.org>; Thu, 16 Sep 2021 15:21:48 +0200 (CEST)
Received: from amongbytes.com (37.59.142.96) by mxplan8.mail.ovh.net (172.16.2.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2308.14; Thu, 16 Sep 2021 15:21:47 +0200
Authentication-Results: garm.ovh; auth=pass (GARM-96R0019daff162-485d-4066-9684-974a732044e4, 298457C0552448DA8EA8ABFC058394546CA5FFA2) smtp.auth=kris@amongbytes.com
X-OVh-ClientIp: 90.251.255.1
To: <spasm@ietf.org>
References: <e281b09a816e46d9a36a388c1e5ff6fa@secunet.com> <CH0PR11MB57391CF716326E327E03D3569FDB9@CH0PR11MB5739.namprd11.prod.outlook.com>
From: Kris Kwiatkowski <kris@amongbytes.com>
Message-ID: <7e78727c-1ee4-9779-3990-0406ac37c522@amongbytes.com>
Date: Thu, 16 Sep 2021 14:21:47 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <CH0PR11MB57391CF716326E327E03D3569FDB9@CH0PR11MB5739.namprd11.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------250E321EC7DC912D7629E750"
Content-Language: en-US
X-Ovh-Tracer-GUID: 102e62a3-b88b-4982-b75e-ebe60789f019
X-Ovh-Tracer-Id: 4966063015135985431
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvtddrudehgedgheelucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucenucfjughrpefuvfhfhffkffgfgggjtgesrgdtreertdefjeenucfhrhhomhepmfhrihhsucfmfihirghtkhhofihskhhiuceokhhrihhssegrmhhonhhgsgihthgvshdrtghomheqnecuggftrfgrthhtvghrnhepkeetuddvjeejgefhgeehieegvefftdekfeeiueetgfffgeeihfduveejjeffgfffnecukfhppedtrddtrddtrddtpdefjedrheelrddugedvrdelieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdqohhuthdphhgvlhhopehmgihplhgrnhekrdhmrghilhdrohhvhhdrnhgvthdpihhnvghtpedtrddtrddtrddtpdhmrghilhhfrhhomhepkhhrihhssegrmhhonhhgsgihthgvshdrtghomhdprhgtphhtthhopehsphgrshhmsehivghtfhdrohhrgh
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/Fs6am3PdjPijGdIsqG4mhtf_Zwk>
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 13:21:56 -0000

On 9/15/21 9:02 PM, Mike Ounsworth wrote:
> 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.

The authors of "Separate Your Domains: NIST PQC KEMs, Oracle Cloning and 
Read-Only Indifferentiability" (Bellare, Davis, Gunther, EUROCRYPT 2020) looked
at the construction of NIST PQC KEMs. An orthogonal, but still contribution in
that paper is a "generic" framework to "unify and visualize" variations between KEM
constructions submitted to NIST PQC.
In the chapter 2.2, the "Algorithm KE_4" shows that output of a shared secret (K)
is constructed by calling random oracle H_4 and assigning it's output to K. Based
on that,  I would assume, that for all Round3 NIST PQC KEMs all bits of shared secret
are chosen uniformly.

> I am eager to hear from people more expert than myself in KEM constructions :)
Not an expert either.

BR,
Kris