[lamps] Re: [EXTERNAL] Re: Re: Changing Composite KEM from RSA-KEM to RSA-OAEP

Mike Ounsworth <Mike.Ounsworth@entrust.com> Thu, 25 July 2024 21:00 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 8417EC17C884 for <spasm@ietfa.amsl.com>; Thu, 25 Jul 2024 14:00:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.704
X-Spam-Level:
X-Spam-Status: No, score=-2.704 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=entrust.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CMgb7NDETZg for <spasm@ietfa.amsl.com>; Thu, 25 Jul 2024 14:00:05 -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 9FFFFC1519B8 for <spasm@ietf.org>; Thu, 25 Jul 2024 14:00:04 -0700 (PDT)
Received: from pps.filterd (m0242863.ppops.net [127.0.0.1]) by mx08-0015a003.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 46PIVIDP027779; Thu, 25 Jul 2024 16:00:00 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=entrust.com; h= cc:content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to; s=mail1; bh=437i9NvY9WJsSHSkGKywO84HJECf m9XMNfbrFH3kNbo=; b=lyyVfKv/T/nTnbDjIhaMxhfPeojAkIzNPbubQnPbEkFQ ++W3m0kzkLoQ8m1FzgJRWeb/UABQKj1Z59tRgq+2nSzHNc23x1mgvi0DvirrBHyR bAsOfkGfhe17MLYqtReUhcrMyCPMlewrkbztEBVjqkrq21jIFQm+HqdhXpW9mf7b yye6D4bp0zcxRupd74hddCTO8LX+KQ8qodabocI+tTZTRanDY945ZSVpcFQNGSso 0Ht7Gc1SaSfRG3G518tQ2cO6AXEC5Kup8RGCdmJHNdmTUIu5kr6x4plOKUEBxvnA 6wGaFTwN4KRv6NmczojYk0+vpiu+Urc1OqnRS1C9Zw==
Received: from nam04-dm6-obe.outbound.protection.outlook.com (mail-dm6nam04lp2041.outbound.protection.outlook.com [104.47.73.41]) by mx08-0015a003.pphosted.com (PPS) with ESMTPS id 40kc8fd6pw-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 25 Jul 2024 15:59:59 -0500 (CDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=nKKvLZKSs91PrQM3y7A6fraZTy4YOT0bZmRsNoeczgcL3jnnMp5D+hG/vo8GRW2johyb51f9FLFBcLyrrXZ1W4r+ftYh2nBEKfGm+apR3HLTBIYqizkoqnOO3dIaPzH31VNamK1ua2rk3OC0EWjBTIMxdrB17zR3/SU1GZU53RT27L5ds8MiHPC28ewPz/6Wequn15tE0KUbq/UbgiJXhyPfwFrEHLj3U+6DbOoAS823qPzmAvkHUkIR/0a+7EQaeFnTUj120GpgOwmzQGXlWe+Un2FA0WJc/7xB8ltoLN+1SRAa8wjZMwTBK7osVN0yPGudQK03rRxoCCy4z7oMHw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=/cfpdNPwnC/0Vo/flkn5+nlQt3cxTNGOFHy51Ui+SP8=; b=XVY18T6LmnrRSyyK93dzHEGSWK865G/nrRhItsoc62luk2g1d4s2qA+Hu/JumwHcdMbTE6ZfwiH4EoDziwPgf94DhqAo65fw9Ddts/RrzZsy5o91CTfw6HZmfTcq0dNJv2+ssgpqQWB/qFhO7AIeS6HDL7RYNlr6FQrPY2maA+nBBsRCl6TGBD6hFka3Cb3xqCLk8t9KKBtnjgyDoK5zdfmdLxLvH9FaUI9QsV9LkaCTNkPt68aUDdjNROBg7CHGgxQsBrWVvIdbhoKCaFffDwTxrH6TsWCm2d3vyxhOgx/Vf5pSv3cW/Lo6DiTzFstC/enzOWQFt4vcTgpTgCf0Hg==
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 CH3PR11MB7722.namprd11.prod.outlook.com (2603:10b6:610:122::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7784.19; Thu, 25 Jul 2024 20:59:45 +0000
Received: from CH0PR11MB5739.namprd11.prod.outlook.com ([fe80::b93d:b2d:3ad8:9702]) by CH0PR11MB5739.namprd11.prod.outlook.com ([fe80::b93d:b2d:3ad8:9702%4]) with mapi id 15.20.7784.020; Thu, 25 Jul 2024 20:59:45 +0000
From: Mike Ounsworth <Mike.Ounsworth@entrust.com>
To: Piotr Popis <piotr.popis@enigma.com.pl>, 'Sophie Schmieg' <sschmieg=40google.com@dmarc.ietf.org>
Thread-Topic: [lamps] Re: [EXTERNAL] Re: Re: Changing Composite KEM from RSA-KEM to RSA-OAEP
Thread-Index: AQHa3bBGrdOD57sai0K7Z45PwWMgT7IGIIKAgADyrYCAANRgIA==
Date: Thu, 25 Jul 2024 20:59:44 +0000
Message-ID: <CH0PR11MB5739DE44C8ED5B924A526D149FAB2@CH0PR11MB5739.namprd11.prod.outlook.com>
References: <CH0PR11MB57393D49F0B0C8F9B43C15CE9FDA2@CH0PR11MB5739.namprd11.prod.outlook.com> <LO2P123MB705163CAA1CD0408C0D5B813BCA22@LO2P123MB7051.GBRP123.PROD.OUTLOOK.COM> <66966a18.050a0220.bbcf3.afeaSMTPIN_ADDED_BROKEN@mx.google.com> <CAEEbLAZLh9eN2a086jNteibZ67Ti4KNnuYjOeFqQAxw+d7+OUw@mail.gmail.com> <CH0PR11MB57394BCA6A0511EA02E4DF3D9FA22@CH0PR11MB5739.namprd11.prod.outlook.com> <CAEEbLAaKXp-YxPOOSE9HERpcNYCuPSg_ebkS1tkvjrG9ZkHMHQ@mail.gmail.com> <CH0PR11MB5739A89137FF081318A783939FA92@CH0PR11MB5739.namprd11.prod.outlook.com> <7d4f01daddb0$2d1dc800$87595800$@enigma.com.pl> <CAEEbLAZNF=8RVkX42-HrLYMTtQPPq96cwa9zuru7sHh0KF45Ew@mail.gmail.com> <7de701dade67$483b8930$d8b29b90$@enigma.com.pl>
In-Reply-To: <7de701dade67$483b8930$d8b29b90$@enigma.com.pl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: CH0PR11MB5739:EE_|CH3PR11MB7722:EE_
x-ms-office365-filtering-correlation-id: db5197cd-7e20-4988-1780-08dcacecb644
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|4022899009|376014|38070700018;
x-microsoft-antispam-message-info: 21+moVHGxmfdSStahmmX+TXtpwhr4FxC3VoZSuQkhdJ2IeQEu/vkmWD5pVwAYAtW/JodBYDK3natw+AES1Yh2XxiYLYVikyfRczbgR1fRDo4wViNqP87/oiaAIsGVVyxfr6fjvH7CnA14PoeVi/IagYv8DMVX8PZq4+5bq+2g8CUxRvkznANo0UuB+hmlnYbp/EvLO5hnz+2lkGlObcYD9EBwMlbW39vryE0xy9oLMlSZA1bK4Leh+h4dbgG4f4ZGcOB8/xRYJG6OHEt6VyZQ9ygNT2am93jCzqDFYzMBYmoO4w/F2uBvcrqokdsD76GF4FBmMdP695tPO8v3O412tyQjo1Ua+6vs1ySKEJx13rqL218KiaCBHMwoduWqf3EKwKZVmPLGSycRjxlm83D4x5su6vk5el8W1/mZ30ha/U6w5P9BL0ega8UCzpacEAGbmP6odDMEBHCbvAfxOw0+8wDUkEQ4e4sKgMkR8W8pk3F+Nd72B3D3R4y4pkzXmavSPnPfLMDsm6krjOJh0MKTwgrTS5nCHXvhhiJxR1V1ve8CtDGDimNl5V6ICPGEihMiBAwZSFedErnDDZOJ+Hm+BmgWM6+r/mxd7hL5cWGQYk4I7y41F6ZcpCLubJjW5r16mckERtV7Hh02PsNLVuqbKs94X1U2o5y9ezHzjLUWyp2+HVb2gXkqo1LsskLcZ6PWAyFrdjQFfkyOsuyUT5DC7XrAmAqSqbZBK5BSQsCRw+3NMi9uWeX8w6hJNhyG+95waIXuCADWqrXvWbyWKy6vrMx8V1J4fIcCC2++Hg2pBUxIXx2cM0bkQYxXa1oVf1LqDG/uHuGkVdtO+ernrdKR7orOnSaNOB3qZgpAgkg4DgfH77qW2m9l/JwMOELSx/xdgrC9+R4FiFq2oPBCFpy3H3ZddtUtbKnoOwRXHTA/x9LeDqgvv2xYX0poPuUkAUrP5bCzDoNHY/kISLuBVOOixNcpEMTYm3/sfOHvq+GT3I0iU+JbOCaWTo0GRh83TLxAwIVOvbEBm2dwfpDJl0PItFcpkKH+BK0u0AqrB0rNUm1gvvLAoWixD0v5qgt/xVCrfO1UHaCc1uNTKYo3jCcLzv7uwxBh4EaVhAYsOQhxG4FOZkzTDdXxjui9nxPNoAQLRhoUXx9UD91SDvtLqU0wPQV3Uc5UXwkqbYyksIm8YBodNEQIpVgKwJy8AP6zgtGgLeM1UuAYu5FU1LGKYxi9WDjJHyWepUxtgbjv/CBe27lrCFgpYJ6KUj506keCvJAXySeU0Ak1p9zDApve+Jh71XvmPksxT5RuFDqjJFfLDR/8x1t88wVYh8QcjOuB6xOu4zKIxrCMLB2UoRDt/gm2muoVV9CCVI07Q74/bAc3Lo=
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:(13230040)(366016)(1800799024)(4022899009)(376014)(38070700018);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: CsEU1ZiRV/nqf3Ftf4rzTBQgkqTszzIuNHubT9NUwBLLOxJBFHH0jh+14nU+l+4vHQmcIe+Ved/cuAWecKNB7e3pMzTSRy38i0O0ZDvX+atMhEzvKpI6lj0/t8NDjmdITCkLfiHGK/oy9qoZB8cCxxHQj1Bznetb09E6Z2nnnWvbRocxTu++NLdOHmaoZuE0ahJRWTJ2vID9CFkL0OukE2UpXU7b8pNER8PNC5CKb1QqjeF3a2RTyWuL/QmgWVaLge3mhemhaeALE+7yDgdaH7d+AJpCEZwp1dAdrnP4EH4I9KqgB3GxH63fZ6ZYWBCL7cz+llA18vNO0JuxURfJty1AnwOXE3OQKk18sP5raVSEn+lmbTjsEt8cKtOXE3COSYUSPy/yM2Bx3WXbREA/Y45AaI4jRxCdHRRg4I+MjQtOWGztwO/IygRJIu/w9u+J1nw4uPfoV6V+O9BdhCXhGVJo+KCZURrzg5sllWRQ4Gka1mwQAfwLxxv/tUZI+qobifQIsrYf16eH6xMtRr7ZcWa/uJJyftUAkZsg6/+ShPiA/USpDNkPpEKuLfgYhjvKxHLyigL5XsjBCEcsQXfqre1BvvrZl0wB2cBr1sQSANwbQkC2G3kG6Icm/bXzNvbAXp8nr26A+llBUJdc+4cRmFa3/jYoUasFNW06fWGkUkUM3ulALh/a13H0q2H3EqCIJgPNYykB02CHujqEVcb9sRrlcBDYFPwlCKPCQnA2mSrfhayIfEUOzNv5X3LrctYRz55qXXMbwPWCqhHzymDVSCiTiaF601zcmcVI/a9Wq8aV9ncykqf3k1GJhF6of9/somNHCHDohCvkkswvTYR6Mq28BbjI9ZOXPHFzDBRGXMyxAVLqq8OB5L2Zi6zJITFekKQgmDr79HEpeXL5zpUCnxY088XLJZF16icLNnBXjZCThglcOdRv6O8npOWUuLDamkfnvPffemSzxUDxHv63zYGn7dpJ9anaXe57C/gmqJ3mVQxrhKdEoQPB1QAIvoHLsEObRcP+lDffMeUpY6aUuwrVQtx4F7VDhA+lPxkDZJ66GvEONds16cmCkIyoSPZ/esRQXMQyGN8lSCbUnz0p57AU8NN7pC+MgE6SPFbeAS9db5LBoRe4JweuBYNV+HnlfA0nU6OBp+goZDDsW+26Q7KoDsWBNKk+uqUWjMWsM0SKGWUz9Vb5xOigRq65L+QtPMk2b7kaiduDjAYZthhF8fAXwODDt/2ohn8sgTaO9/zRjKGvYXPQ9F3ZaY2WK4SJd8Lw3PwqVFDW/mrRPZh21tsXOZVcSxmltuWPFNLDiFk3ERZgZo8gu/vMImlsYpz5nS3ou5XtfMnq/NKil48ln4Je9kTmIX4SqcAqt3TtEqHzgWupw7vFE4BUpf2P0Krbq5JLhKgrchVjew8XufqZHNT/CM2jnpGhOPhNiQBRXvGbvh1+Pvv4znhAXto7NRPApK3ysGIOQ4f3RSTPLY9R8LIe9d5M2LSA8yG7iRm3EGpWY2twlxhhMnox/0kFe4lCBfybSY2GTQ8YLqImvi/QPezK7xTUQur5MPu9M2dyt71PF2gKva/RwH9ipLsdsFR8
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="2.16.840.1.101.3.4.2.1"; boundary="----=_NextPart_000_01C7_01DADEAB.A9FAC9D0"
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: db5197cd-7e20-4988-1780-08dcacecb644
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jul 2024 20:59:44.9446 (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: TUQ+4ud9/t4YEONpmEHk6ogqAyui1nLCanR9CileskmSMtlomp3ndDbH08WMMNwVUEfrkpt5y48dg+zMkgUMlkH+bKfUVrcBJMv2wZZnF2E=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR11MB7722
X-Proofpoint-GUID: cmMS0s0xzwWUbqtJeADJFbVn1LIZJFS9
X-Proofpoint-ORIG-GUID: cmMS0s0xzwWUbqtJeADJFbVn1LIZJFS9
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.680,FMLib:17.12.28.16 definitions=2024-07-25_21,2024-07-25_03,2024-05-17_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 impostorscore=0 adultscore=0 suspectscore=0 lowpriorityscore=0 clxscore=1015 phishscore=0 mlxscore=0 spamscore=0 mlxlogscore=999 priorityscore=1501 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.21.0-2407110000 definitions=main-2407250143
Message-ID-Hash: US5HTUWN2G754XN65BBQMXHW2J4MYS6Q
X-Message-ID-Hash: US5HTUWN2G754XN65BBQMXHW2J4MYS6Q
X-MailFrom: Mike.Ounsworth@entrust.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-spasm.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: 'LAMPS' <spasm@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [lamps] Re: [EXTERNAL] Re: Re: Changing Composite KEM from RSA-KEM to RSA-OAEP
List-Id: This is the mail list for the LAMPS Working Group <spasm.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/e48IlhrEDtSuZ5V0BVmQTjuDHeg>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Owner: <mailto:spasm-owner@ietf.org>
List-Post: <mailto:spasm@ietf.org>
List-Subscribe: <mailto:spasm-join@ietf.org>
List-Unsubscribe: <mailto:spasm-leave@ietf.org>

Hi Piotr and Sophie,

 

(reducing the direct audience back to active participants)

> 1b) Do we really need to include the RSA key length in the OID specification?

This has come up a few times, and I can’t find any definitive discussion either on the mailing list or in LAMPS meeting minutes, so I’ll start a new discussion thread.

 

 

Thank you for your editorial comments. I have captured these in github for consideration when I have some free time.

https://github.com/lamps-wg/draft-composite-kem/issues/46

 

 

As to reducing the algorithm list, thank you both for the concrete suggestions. I have captured that here for consideration for the next version of the draft.

https://github.com/lamps-wg/draft-composite-kem/issues/47

The other consideration here is aligning with OpenPGP, and particularly the combinations suggested by Quynh Dang in his OpenPGP slides.

https://datatracker.ietf.org/meeting/120/materials/slides-120-openpgp-pqc-with-nist-and-brainpool-curves

---

Mike Ounsworth

 

From: Piotr Popis <piotr.popis@enigma.com.pl> 
Sent: Thursday, July 25, 2024 2:50 AM
To: 'Sophie Schmieg' <sschmieg=40google.com@dmarc.ietf.org>
Cc: Mike Ounsworth <Mike.Ounsworth@entrust.com>; 'Russ Housley' <housley@vigilsec.com>; 'Tim Hollebeek' <tim.hollebeek@digicert.com>; 'Wang Guilin' <Wang.Guilin@huawei.com>; 'Peter C' <Peter.C@ncsc.gov.uk>; 'Douglas Stebila' <dstebila@uwaterloo.ca>; John Gray <John.Gray@entrust.com>; 'Max Pala' <M.Pala@cablelabs.com>; 'Klaußner, Jan' <Jan.Klaussner@bdr.de>; 'Deirdre Connolly' <durumcrustulum@gmail.com>; 'b...' <bas@cloudflare.com>; 'LAMPS' <spasm@ietf.org>; 'Aron Wussler' <aron@wussler.it>
Subject: RE: [lamps] Re: [EXTERNAL] Re: Re: Changing Composite KEM from RSA-KEM to RSA-OAEP

 

Hi Sophie and All Considering KEM algorithms OIDs my detailed proposal is as follows: +===================+============+=========+===============+========+ | Composite KEM |OID |First |Second |KDF | | | |Algorithm|Algorithm | | +===================+============+=========+===============+========+



Hi Sophie and All

Considering KEM algorithms OIDs my detailed proposal is as follows:

   +===================+============+=========+===============+========+

   | Composite KEM     |OID         |First    |Second         |KDF     |

   |                   |            |Algorithm|Algorithm      |        |

   +===================+============+=========+===============+========+

   | id-MLKEM512-ECDH  |<CompKEM>.1 |MLKEM512 |ECDH-P256      |SHA3-256|

   | -P256             |            |         |               |        |

   +-------------------+------------+---------+---------------+--------+

   | id-MLKEM512-      |<CompKEM>.2 |MLKEM512 |ECDH-          |SHA3-256|

   | ECDH-             |            |         |brainpoolp256r1|        |

   | brainpoolP256r1   |            |         |               |        |

   +-------------------+------------+---------+---------------+--------+

   | id-               |<CompKEM>.3 |MLKEM512 |X25519         |SHA3-256|

   | MLKEM512-X25519   |            |         |               |        |

   +-------------------+------------+---------+---------------+--------+

   | id-               |<CompKEM>.4 |MLKEM512 |RSA-OAEP 2048  |SHA3-256|

   | MLKEM512-RSA      |            |         |RSA-OAEP 3072  |        |

   |                   |            |         |RSA-OAEP 4096  |        |

   +-------------------+------------+---------+---------------+--------+

   | id-MLKEM768-ECDH  |<CompKEM>.5 |MLKEM768 |ECDH-P384      |SHA3-384|

   | -P384             |            |         |               |        |

   +-------------------+------------+---------+---------------+--------+

   | id-MLKEM768-      |<CompKEM>.6 |MLKEM768 |ECDH-          |SHA3-384|

   | ECDH-             |            |         |brainpoolp384r1|        |

   | brainpoolP384r1   |            |         |               |        |

   +-------------------+------------+---------+---------------+--------+

   | id-               |<CompKEM>.7 |MLKEM768 |X448           |SHA3-384|

   | MLKEM768-X448     |            |         |               |        |

   +-------------------+------------+---------+---------------+--------+

   | id-MLKEM1024-ECDH |<CompKEM>.8 |MLKEM1024|ECDH-P521      |SHA3-512|

   | -P521             |            |         |               |        |

   +-------------------+------------+---------+---------------+--------+

   | id-MLKEM1024-     |<CompKEM>.9 |MLKEM1024|ECDH-          |SHA3-512|

   | ECDH-             |            |         |brainpoolP512r1|        |

   | brainpoolP512r1   |            |         |               |        |

   +-------------------+------------+---------+---------------+--------+

 

                   Table 1: Composite KEM key types

 

   +===================================+==========+====================+

   | Composite KEM OID                 | KDF      | Key Encryption     |

   |                                   |          | Alg                |

   +===================================+==========+====================+

   | id-MLKEM512-ECDH-P256             | SHA3-256 | id-aes128-Wrap     |

   +-----------------------------------+----------+--------------------+

   | id-MLKEM512-ECDH-brainpoolP256r1  | SHA3-256 | id-aes128-Wrap     |

   +-----------------------------------+----------+--------------------+

   | id-MLKEM512-X25519                | SHA3-256 | id-aes128-Wrap     |

   +-----------------------------------+----------+--------------------+

   | id-MLKEM512-RSA                   | SHA3-256 | id-aes128-Wrap     |

   +-----------------------------------+----------+--------------------+

   | id-MLKEM768-ECDH-P384             | SHA3-384 | id-aes256-Wrap     |

   +-----------------------------------+----------+--------------------+

   | id-MLKEM768-ECDH-brainpoolP384r1  | SHA3-384 | id-aes256-Wrap     |

   +-----------------------------------+----------+--------------------+

   | id-MLKEM768-X448                  | SHA3-384 | id-aes256-Wrap     |

   +-----------------------------------+----------+--------------------+

   | id-MLKEM1024-ECDH-P521            | SHA3-512 | id-aes256-Wrap     |

   +-----------------------------------+----------+--------------------+

   | id-MLKEM1024-ECDH-brainpoolP512r1 | SHA3-512 | id-aes256-Wrap     |

   +-----------------------------------+----------+--------------------+

   

              Table 4: REQUIRED pairings for CMS KDF and WRAP

Simply answer to Sophie: The above compositions meet the assumption that the PQ algorithm and the traditional algorithm

have the same security level, except for RSA2048, which is widely used today.

 

The first sentence of Section 6.1:

> A CMS implementation that supports a composite KEM algorithm MUST

>  support at least the following underlying components:

This sentence appears to be unfinished, or means that all compositions from

Table 4 must be implemented. 

My proposal is to leave both tables 1 and 4 in the document (and change other tables in an appropriate way).

I.e. 9 OIDs, but at the same time add at the beginning of section 6.1 a clarification on what subset of the composition

is minimally required. For example:

 

6.1.  Underlying Components

A CMS implementation that supports a composite KEM algorithm MUST

support at least the following underlying components:

id-MLKEM512-ECDH-P256

id-MLKEM512-RSA (RSA 2048 and RSA 3072)

id-MLKEM1024-ECDH-P521

 

As I mentioned in the previous email, I do not have strong arguments for such a limit to 3 OIDs. However, I suggest taking into account the following circumstances:

1. NIST elliptic curves (P256, P384 and P521) and Brainpool (P256, P384 and P512) are permitted by ETSI TS 119 312 ("ALGO", current version 1.4.3 (2023-08)) and by SOG-IS Crypto Evaluation Scheme Agreed Cryptographic Mechanisms (current version 1.3 (2023-02)).

2. ETSI and SOG-IS do not list X25519 and X448.

3. NIST Curves have much better performance over Brainpool.

--------------

Piotr Popis

 

From: Sophie Schmieg <sschmieg=40google.com@dmarc.ietf.org <mailto:sschmieg=40google.com@dmarc.ietf.org> > 
Sent: Wednesday, July 24, 2024 7:22 PM
To: Piotr Popis <piotr.popis@enigma.com.pl <mailto:piotr.popis@enigma.com.pl> >
Cc: Mike Ounsworth <Mike.Ounsworth@entrust.com <mailto:Mike.Ounsworth@entrust.com> >; Russ Housley <housley@vigilsec.com <mailto:housley@vigilsec.com> >; Tim Hollebeek <tim.hollebeek@digicert.com <mailto:tim.hollebeek@digicert.com> >; Wang Guilin <Wang.Guilin@huawei.com <mailto:Wang.Guilin@huawei.com> >; Peter C <Peter.C@ncsc.gov.uk <mailto:Peter.C@ncsc.gov.uk> >; Douglas Stebila <dstebila@uwaterloo.ca <mailto:dstebila@uwaterloo.ca> >; John Gray <John.Gray@entrust.com <mailto:John.Gray@entrust.com> >; Max Pala <M.Pala@cablelabs.com <mailto:M.Pala@cablelabs.com> >; Klaußner, Jan <Jan.Klaussner@bdr.de <mailto:Jan.Klaussner@bdr.de> >; Deirdre Connolly <durumcrustulum@gmail.com <mailto:durumcrustulum@gmail.com> >; b... <bas@cloudflare.com <mailto:bas@cloudflare.com> >; LAMPS <spasm@ietf.org <mailto:spasm@ietf.org> >; Aron Wussler <aron@wussler.it <mailto:aron@wussler.it> >
Subject: Re: [lamps] Re: [EXTERNAL] Re: Re: Changing Composite KEM from RSA-KEM to RSA-OAEP

 

Does the request explicitly also include the Kyber512 variants? I do not see much reason to have Kyber512 available at all.

The issue with having this many different KEMs is that it will lead to incompatibilities between different solutions, and additional complexity for no clear reason, especially when it comes to the PQ side of the coin (legacy crypto unfortunately already comes with this complexity). So why not limit us to Kyber768 for all solutions that do not require CNSA2 compliance, and use Kyber1024 (ideally unhybridized, as recommended by CNSA2) for the cases where we do need CNSA2 compliance?

 

On Wed, Jul 24, 2024 at 3:00 AM Piotr Popis <piotr.popis=40enigma.com.pl@dmarc.ietf.org <mailto:40enigma.com.pl@dmarc.ietf.org> > wrote:

HI All

1. Limiting the number of KEM algorithm

a) I suport limiting the number of KEM algorithm OIDs, but I don't have a strong argument for choosing them. From my perspective, currently in common use would be MLKEM512 with: ECDH-P256 and RSA-2048 and - for more secure applications - MLKEM1024 with ECDH-P521. However, I recommend that PQ and the traditional algorithm be at the same level of security. It means that MLKEM768 be combined with classical algorithms using a 384-bit elliptic curve, and MLKEM1024 with a 512-bit elliptic curve.

b) Do we really need to include the RSA key length in the OID specification?

Keeping in mind the general rule that into each composite KEM algorithms parameters field in the AlgorithmIdentifier sequence must be empty, in the case of ECC we must specify the curve type in the OID. Whereas in the case of the RSA algorithm, the key length results from the size of the subjectPublicKey field; not from the algorithm/parameters field. Therefore it should be considered whether

it would be better to change the entries in table 1 regarding RSA leaving only the OID pointing to the RSA algorithm without specifying the key length. This length will be dictated by the certificate of the message recipient.

2. Notes on the document "Composite KEM" version 4 (order of appearance)

a) Section 2.3.1

> (…) it produces a composite public key pk as per Section 3.2 and a composite

>   secret key sk is per Section 3.3.

it produces a composite public key pk as per Section 3.2 and a composite

secret key sk as per Section 3.3.

 

b) Section 2.3.2

> DHKEM.Encaps(pkR):

RSA-OAEP.Encaps(pkR):

 

> DHKEM.Decap(skR, enc):

RSA-OAEP.Decap(skR, enc):

 

c) Section 3.1

> pk-MLKEM512-ECDH-P256 PUBLIC-KEY ::=

>     pk-CompositeKEM {

>       id-MLKEM512-ECDH-P256,

>        OCTET STRING, ECPoint }

pk-MLKEM512-ECDH-P256 PUBLIC-KEY ::=

     pk-CompositeKEM {

       id-MLKEM512-ECDH-P256,

       BIT STRING, ECPoint }

 

d) Section 3.2

> A composite key MUST contain two component public keys.  The order 

> of the component keys is determined by the definition of the corresponding

> algorithm identifier as defined in section Section 5.

A composite key MUST contain two component public keys as SEQUENCE of

two bit strings.  The order of the component keys is determined by the

definition of the corresponding algorithm identifier as defined in 

Section 5.

 

e) Section 3.3

> CompositeKEMPrivateKey ::= SEQUENCE SIZE (2) OF OneAsymmetricKey

> 

>   Each element is a OneAsymmetricKey` [RFC5958] object for a component

>   private key.

> 

>   The parameters field MUST be absent.

> 

>   The order of the component keys is the same as the order defined in

>  Section 3.2 for the components of CompositeKEMPublicKey.

> 

>   When a CompositePrivateKey is conveyed inside a OneAsymmetricKey

>   structure (version 1 of which is also known as PrivateKeyInfo)

>  [RFC5958], the privateKeyAlgorithm field SHALL be set to the

>  corresponding composite algorithm identifier defined according to

>   Section 5, the privateKey field

>   SHALL contain the CompositeKEMPrivateKey, and the publicKey field MUST

>   NOT be present. Associated public key material MAY be present in the

>   CompositeKEMPrivateKey.

 

CompositeKEMPrivateKey ::= SEQUENCE SIZE (2) OF OCTET STRING

 

   Each element is a OneAsymmetricKey` [RFC5958] object for a component

   private key (privateKey field).

 

   The order of the component keys is the same as the order defined in

   Section 3.2 for the components of CompositeKEMPublicKey.

 

   When a CompositeKEMPrivateKey is conveyed inside a OneAsymmetricKey

   structure (version 1 of which is also known as PrivateKeyInfo)

   [RFC5958], the privateKeyAlgorithm field SHALL be set to the

   corresponding composite algorithm identifier defined according to

   Section 5 (the parameters field MUST be absent), the privateKey field

   SHALL contain the CompositeKEMPrivateKey, and the publicKey field MUST

   NOT be present. Associated public key material MAY be present in the

   OneAsymmetricKey structure containing CompositeKEMPrivateKey and in

   that case version is 2.

 

f) Section 4.2

> 4.2.  CompositeCiphertextValue

> 

>   The compositeCipherTextValue is a concatenation of the

>   ciphertexts of the underlying component algorithms.  It is represented

>   in ASN.1 as follows:

 

4.2.  CompositeCipherTextValue

 

   The compositeCipherTextValue is a sequence of the

   ciphertexts of the underlying component algorithms.  It is represented

   in ASN.1 as follows:

 

g) Section 4.3

> KEK <- Combiner(tradSS, mlkemSS, tradCT, tradPK, domSep) =

>      KDF(counter || tradSS || mlkemSS || tradCT || tradPK ||

>          domSep, outputBits)

> 

>                Figure 1: Generic KEM combiner construction

> 

>   where:

> 

>   *  KDF(message, outputBits) represents a hash function suitable to

>      the chosen KEMs according to {tab-kem-combiners}.

> 

>   *  counter SHALL be the fixed 32-bit value 0x00000001 which is placed

>      here solely for the purposes of compliance with [SP.800-56Cr2].

> 

>   *  tradSS is the shared secret from the traditional component

>      (elliptic curve or RSA).

> 

>   *  mlkemSS is the shared secret from the ML-KEM componont.

> 

>   *  tradCT is the ciphertext from the traditional component (elliptic

>      curve or RSA).

> 

>   *  tradPK is the public key of the traditional component (elliptic

>      curve or RSA).

>   *  domSep SHALL be the DER encoded value of the object identifier of

>      the composite KEM algorithm as listed in Section 5.1.

> 

>   *  || represents concatenation.

> 

> Each registered composite KEM algorithm must specify the choice of

>   KDF, demSep, and outputBits to be used.

KEK <- Combiner(tradSS, mlkemSS, tradCT, tradPK, domSep) =

 

   SHA3(counter || tradSS || mlkemSS || tradCT || tradPK || domSep)

         ([SP.800-56Cr2] Section 4.1 Option 1 (when KDF is SHA3))

 

                Figure 1: Generic KEM combiner construction

 

   where:

 

   *  counter SHALL be the fixed 32-bit value 0x00000001 which is placed

      here solely for the purposes of compliance with [SP.800-56Cr2].

 

   *  tradSS is the shared secret from the traditional component (ECDH or RSA).

 

   *  mlkemSS is the shared secret from the ML-KEM component.

 

   *  tradCT is the ciphertext from the traditional component (ECDH or RSA).

      Note: In the case of ECDH, this is the sender's ephemeral public key.

 

   *  tradPK is the recipient's public key of the traditional component (ECDH or RSA).

 

   *  domSep SHALL be the DER encoded value of the object identifier of

      the composite KEM algorithm as listed in Section 5.1.

 

   *  || represents concatenation.

 

   Each registered composite KEM algorithm (see {tab-kem-combiners}) must

   specify the choice of KDF (ie. type of SHA3 function) and domSep

   to be used.

Comment:

1. The use of the counter parameter is probably redundant - see Falko Strenzke email from 2024/07/24

2. Removing outputBits is related to replacing KMAC with SHA3.

 

h) Section 4.4

> This construction is specifically designed to conform with

>   Section 4.1 Option 1 (when KDF is SHA3) or Option 3 (when KDF is

>   KMAC) in the following way:

> 

>   In both cases we match exactly the construction using the allowed

>   "hybrid" shared secret of the form Z' = Z || T to yield the

>   construction

This construction is specifically designed to conform with [SP.800-

56Cr2] Section 4.1 Option 1 (when KDF is SHA3). In any cases we match exactly the

construction using the allowed "hybrid" shared secret of the form

   Z' = Z || T (see Section 2 of the [SP.800-56Cr2]) to yield the construction:

 

(…)

The last sentence starting with: “In the case that KDF is KMAC,…”

should be removed.

 

------

Piotr Popis

 

From: Mike Ounsworth <Mike.Ounsworth=40entrust.com@dmarc.ietf.org <mailto:40entrust.com@dmarc.ietf.org> > 
Sent: Tuesday, July 23, 2024 6:27 PM
To: Sophie Schmieg <sschmieg=40google.com@dmarc.ietf.org <mailto:40google.com@dmarc.ietf.org> >; Russ Housley <housley@vigilsec.com <mailto:housley@vigilsec.com> >; Tim Hollebeek <tim.hollebeek@digicert.com <mailto:tim.hollebeek@digicert.com> >
Cc: Wang Guilin <Wang.Guilin@huawei.com <mailto:Wang.Guilin@huawei.com> >; Peter C <Peter.C@ncsc.gov.uk <mailto:Peter.C@ncsc.gov.uk> >; Douglas Stebila <dstebila@uwaterloo.ca <mailto:dstebila@uwaterloo.ca> >; John Gray <John.Gray@entrust.com <mailto:John.Gray@entrust.com> >; Max Pala <M.Pala@cablelabs.com <mailto:M.Pala@cablelabs.com> >; Klaußner, Jan <Jan.Klaussner@bdr.de <mailto:Jan.Klaussner@bdr.de> >; Deirdre Connolly <durumcrustulum@gmail.com <mailto:durumcrustulum@gmail.com> >; b... <bas@cloudflare.com <mailto:bas@cloudflare.com> >; LAMPS <spasm@ietf.org <mailto:spasm@ietf.org> >; Aron Wussler <aron@wussler.it <mailto:aron@wussler.it> >
Subject: [lamps] Re: [EXTERNAL] Re: Re: Changing Composite KEM from RSA-KEM to RSA-OAEP

 

Hi Sophie.

 

I have a github ticket open to re-add the warning about key re-use (where did that text go??). I will definitely ping you to review it before merging.

 <https://urldefense.com/v3/__https:/github.com/lamps-wg/draft-composite-kem/issues/38__;!!FJ-Y8qCqXTj2!ZofDXZdCn3JkPrRpmxFESh-FAov2866O2WFFt7ekijmYiiRxITpqYi5s0-AzF_3l0ruI36vZ21rEkqYUAJUyusfBa1yI$> https://github.com/lamps-wg/draft-composite-kem/issues/38

 

 

I would love to reduce the size of the list, but everything that’s on there is by request, so we can’t remove anything without upsetting someone.

 

Currently there is no RSA-4096 in the document, but we have recently been requested to add it. Discussion is here:

 <https://urldefense.com/v3/__https:/github.com/lamps-wg/draft-composite-kem/issues/37__;!!FJ-Y8qCqXTj2!ZofDXZdCn3JkPrRpmxFESh-FAov2866O2WFFt7ekijmYiiRxITpqYi5s0-AzF_3l0ruI36vZ21rEkqYUAJUyulNYtViQ$> https://github.com/lamps-wg/draft-composite-kem/issues/37

 

RE: X-Wing: in the latest version of the draft, the combiner is “X-Wing inspired”, but we can’t directly use X-Wing here for a couple of reasons:

1. It won’t pass FIPS certification under SP 800-56Cr2; you need to have the stupid fixed value `counter=0x00000001` at the beginning.

2. We have intentionally chosen to use PKI-specific domain separators (DER of algID OID) instead of the spaceship ASCII art.

 

 

Doing the security proofs are beyond my current skill and available time. I would gladly accept a co-author.

 

 

You’ll love this, but at LAMPS later this week, we will propose doubling the size of the list so that each combination has an OID with Combiner-KDF=SHA3 and Combiner-KDF=HMAC-SHA2 because several people (including Joe Salaway and Deb Cooley) have pointed out that not all crypto libraries will have access to SHA3 at the layer that is doing the combiner.  <mailto:housley@vigilsec.com> @Russ Housley,  <mailto:tim.hollebeek@digicert.com> @Tim Hollebeek if the goal is to reduce the size of the list, I will need your help to figure out a fair process for deciding which ones to remove.

 

---

Mike Ounsworth

 

From: Sophie Schmieg < <mailto:sschmieg=40google.com@dmarc.ietf.org> sschmieg=40google.com@dmarc.ietf.org> 
Sent: Tuesday, July 16, 2024 5:51 PM
To: Mike Ounsworth < <mailto:Mike.Ounsworth@entrust.com> Mike.Ounsworth@entrust.com>
Cc: Wang Guilin < <mailto:Wang.Guilin@huawei.com> Wang.Guilin@huawei.com>; Peter C < <mailto:Peter.C@ncsc.gov.uk> Peter.C@ncsc.gov.uk>; Douglas Stebila < <mailto:dstebila@uwaterloo.ca> dstebila@uwaterloo.ca>; Russ Housley < <mailto:housley@vigilsec.com> housley@vigilsec.com>; John Gray < <mailto:John.Gray@entrust.com> John.Gray@entrust.com>; Max Pala < <mailto:M.Pala@cablelabs.com> M.Pala@cablelabs.com>; Klaußner, Jan < <mailto:Jan.Klaussner@bdr.de> Jan.Klaussner@bdr.de>; Deirdre Connolly < <mailto:durumcrustulum@gmail.com> durumcrustulum@gmail.com>; b... < <mailto:bas@cloudflare.com> bas@cloudflare.com>; LAMPS < <mailto:spasm@ietf.org> spasm@ietf.org>; Aron Wussler < <mailto:aron@wussler.it> aron@wussler.it>
Subject: Re: [EXTERNAL] Re: [lamps] Re: Changing Composite KEM from RSA-KEM to RSA-OAEP

 

Fair, the hardware/certification cycle can be annoyingly long. My main concern is reuse of key material, why there would still be a temptation to do so, having it clearly spelled out that the key has to be fresh would alleviate my main security 

 

Fair, the hardware/certification cycle can be annoyingly long. My main concern is reuse of key material, why there would still be a temptation to do so, having it clearly spelled out that the key has to be fresh would alleviate my main security concern with this approach to hybridization.

 

My main other concern is more of an operational nature of exploding the number of algorithms, we could address that by somewhat aggressively limiting the number of OIDs. In particular, do we need to full spread of key sizes, or would RSA-2048-ML-KEM768 and RSA-4096-ML-KEM1024 not suffice on the RSA side (with arguably even RSA-4096-ML-KEM1024 being a bit of a strange pick, given the security level of RSA-4096 being so far below ML-KEM1024, and only making sense due to certain government agencies preferring ML-KEM1024 over 768). Basically, my preference would be to lose all ML-KEM512 variations, have a combination at 128 bit classical security level with ML-KEM768, for each algorithm in RSA, ECIES, X-ECIES (with a potential exception of RSA-2048 and its annoyingly below 128 bit security), and a compliance mode for cases where a larger key size is required by the compliance regimen (even though not providing any tangible security gain, especially not for the classical part), combined with ML-KEM1024. In particular, that would remove X448 and likely also the larger brainpool curves due to lack of demand for those combinations. The compliance mode could also just offer unhybridized ML-KEM1024, given the stated preference of the afore-not-mentioned government agency.

 

All in all my suggested list, if RSA has to be included, would be

*	RSA-2048-ML-KEM768 possibly replaced by RSA-3072-ML-KEM768 if we want to strictly have at least 128 bit classical security.
*	P256-ML-KEM768
*	X25519-ML-KEM768 aka X-Wing (using X-Wing's picks for hash function and combiner, including the little ASCII art spaceship)
*	ML-KEM1024 aka CNSA mode (not a hybrid, just listed for completeness sake)

I could see the additional need for these modes, if there is a compliance regimen calling specifically for them:

*	RSA-4096-ML-KEM1024 aka RSA compliance mode
*	P384-ML-KEM1024 aka ECIES compliance mode
*	Brainpool256-ML-KEM768 aka BSI mode, if I correctly kept up with their preferences

Each of these 3-6 options should have its own security proof (with the various ECDH options likely being able to reuse the same proof). Ideally each option should have a clear reasoning where the demand for it is coming from, for the specific combination of both classic algorithm, as well as classic and PQ key size, attempting to consolidate as much as possible to avoid a pick and choose scenario of a combinatorial explosion.

 

On Tue, Jul 16, 2024 at 2:19 PM Mike Ounsworth <Mike.Ounsworth= <mailto:40entrust.com@dmarc.ietf.org> 40entrust.com@dmarc.ietf.org> wrote:

Hi Peter, Guilin, and Sophie.

 

I am pleased that this draft is attracting this kind of discussion and analysis. That is the goal! Actually doing the proof is out of my skillset, but there is an opportunity for a publication here.

 

 

To Sophie’s points:

 

> Is the key generation of this combiner properly combined, i.e. are the RSA-OAEP and ML-KEM key created simultaneously and only ever used in a combined fashion?

 

Yes. To the extent that we can enforce this from within an I-D, we have attempted to do so. We fully agree that taking existing CA or end entity keys and re-certifying them inside a composite key is BAD and completely unravels the security properties of the composite. In particular, I agree that a decryption oracle that will accept only the classical part is bad.

 

… although I can’t easily find that text in the current draft. Am I going crazy? Did we remove it somehow in all the churn? Ok, github issues to add it back:

 <https://urldefense.com/v3/__https:/github.com/lamps-wg/draft-composite-sigs/issues/25__;!!FJ-Y8qCqXTj2!fCKoT58oe9AVfJ3cTt3zcR_Frw3eAl1zKnS4IRCd6DothBDUajkGdLFTwBqMuR-4mK-bzAtiEcsmgsS8cUy9VxL_CFFwrjuSAIYi$> https://github.com/lamps-wg/draft-composite-sigs/issues/25

 <https://urldefense.com/v3/__https:/github.com/lamps-wg/draft-composite-kem/issues/38__;!!FJ-Y8qCqXTj2!fCKoT58oe9AVfJ3cTt3zcR_Frw3eAl1zKnS4IRCd6DothBDUajkGdLFTwBqMuR-4mK-bzAtiEcsmgsS8cUy9VxL_CFFwrmhmy_vV$> https://github.com/lamps-wg/draft-composite-kem/issues/38

 

 

 

> it is not clear to me why to use RSA instead of ECIES. Since we need to add support for ML-KEM anyways, having to add support for elliptic curves would not be a blocker.

 

I would agree with that sentence if “Dev/QA time” + “FIPS time” + “CC time” was on the order of “months” and not on the order of “0.5 decades”, which is closer to the case.

One of the large attractors for using composites is that you can deploy your not-yet-FIPS/CC-certified ML-KEM in hybrid with your already-FIPS/CC-certified ECC/RSA and claim that the whole thing is certified (certainly that’s possible with FIPS, your mileage may vary with CC).

 

Entrust has customers who have never implemented Elliptic Curve, and since RSA-PSS and RSA-OAEP are still FIPS-approved, there is nothing inherently wrong with that (PKCS#1v1.5, different story I understand the IETF not wanting to endorse hybrids of that). Those same customers have extremely long QA cycles (sometimes up to 4 years of pre-production soak time), which cannot begin until FIPS / CC certification of all their hardware and software components is complete. So if we write the standards in such a way that they have to write new code on both sides of the hybrid, then we are forcing them to sit in FIPS / CC queue for … what, 2 years? 2026? 2027? … before they can begin their 4 years of ecosystem-wide testing. Then they cannot _begin_ deploying ML-KEM in production until somewhere around 2030. The point of these hybrids is to short-cut that and help them get ML-KEM into production faster by allowing them to leverage their already-battle-hardened-and-certified RSA code.

 

PS. I am trying very very hard to get these customers to come forward publicly on the IETF mailing list. I hope that will happen soon.

 

---

Mike Ounsworth

 

From: Sophie Schmieg <sschmieg= <mailto:40google.com@dmarc.ietf.org> 40google.com@dmarc.ietf.org> 
Sent: Tuesday, July 16, 2024 12:47 PM
To: Wang Guilin < <mailto:Wang.Guilin@huawei.com> Wang.Guilin@huawei.com>
Cc: Peter C < <mailto:Peter.C@ncsc.gov.uk> Peter.C@ncsc.gov.uk>; Mike Ounsworth < <mailto:Mike.Ounsworth@entrust.com> Mike.Ounsworth@entrust.com>; Douglas Stebila < <mailto:dstebila@uwaterloo.ca> dstebila@uwaterloo.ca>; Russ Housley < <mailto:housley@vigilsec.com> housley@vigilsec.com>; John Gray < <mailto:John.Gray@entrust.com> John.Gray@entrust.com>; Max Pala < <mailto:M.Pala@cablelabs.com> M.Pala@cablelabs.com>; Klaußner, Jan < <mailto:Jan.Klaussner@bdr.de> Jan.Klaussner@bdr.de>; Deirdre Connolly < <mailto:durumcrustulum@gmail.com> durumcrustulum@gmail.com>; b... < <mailto:bas@cloudflare.com> bas@cloudflare.com>; LAMPS < <mailto:spasm@ietf.org> spasm@ietf.org>; Aron Wussler < <mailto:aron@wussler.it> aron@wussler.it>; Wang Guilin < <mailto:Wang.Guilin@huawei.com> Wang.Guilin@huawei.com>
Subject: [EXTERNAL] Re: [lamps] Re: Changing Composite KEM from RSA-KEM to RSA-OAEP

 

Is the key generation of this combiner properly combined, i. e. are the RSA-OAEP and ML-KEM key created simultaneously and only ever used in a combined fashion? If not, it is not clear to me that any proof would actually still work, since it 

Is the key generation of this combiner properly combined, i.e. are the RSA-OAEP and ML-KEM key created simultaneously and only ever used in a combined fashion? If not, it is not clear to me that any proof would actually still work, since it violates the preconditions/oracle setup, as in addition to the combined decapsulation oracle, you would have to have a classical (and potentially a PQ only) oracle as well. Naively, if RSA-OAEP is turned into a KEM via "select k random, c := RSA-OAEP(P, k), return k, c", a X-Wing style combiner, assuming the PQ part is classically broken, would be broken with a query to the classical oracle over the classical ciphertext. Now you could redefine the classical oracle to not accept the classical part of the challenge ciphertext, but you would diverge pretty far from the standard IND-CCA setting for the analysis. Note that the same is not true for a classical EC-KEM vs. X-Wing setting, as the EC-KEM oracle would return a hash of the shared point without the PQ shared secret hashed in, i.e. has a natural form of domain separation that RSA-OAEP (and RSA-KEM for that matter, if the shared secret is used instead of the random value) are lacking. This concern also holds if a ML-KEM only oracle is exposed and ECDH is considered broken, but that scenario has less real world implications, as ML-KEM only keys do not really exist, and hopefully by then we would be able to convince people that one key should only serve one purpose, and not deal with the desire to reuse legacy keys, or add some domain separation that would invalidate the attack.

If the idea is that the RSA key is created at the same time as the ML-KEM key, and only ever used in a hybrid fashion, then it is not clear to me why to use RSA instead of ECIES. Since we need to add support for ML-KEM anyways, having to add support for elliptic curves would not be a blocker.

 

Long story short: Please make sure that legacy keys are rotated to hybrid keys, and not reused as part of a hybrid key, or security proofs will collapse left and right.

 

On Tue, Jul 16, 2024 at 5:39 AM Wang Guilin <Wang.Guilin= <mailto:40huawei.com@dmarc.ietf.org> 40huawei.com@dmarc.ietf.org> wrote:

Hi, Mike and Peter, 


Just had a discussion with my colleagues today about X-Wing, the formal published version [1].

 

If I understand correctly, the draft (draft-ietf-lamps-pq-composite-kem-04) is planning to use similar structure of X-Wing via replacing X25519 by RSA-OAEP. Namely, the resulting hybrid KEM is RSA-OAEP+ML-KEM. So the property C2PRI (ciphertext second pre-image resistance) does hold for ML-KEM already ([1] shows that). So, the real issue seems if RSA-OAEP can be replace X25519 in the sense of Theorem 1 [1]. For this part, I agree with Peter. 

 

[1] X-Wing: The Hybrid KEM You've Been Looking For.   <https://urldefense.com/v3/__https:/cic.iacr.org/p/1/1/21__;!!FJ-Y8qCqXTj2!dFPHZkISK9FnToNL5VKkjPl0ZCZK_y1VGm5Ls-jqnCuxjdGPcLUnetVKPyjSBD0DHumnbj-o12-bZJ_RRBy_nkQynK2XhRpsAQlS$> https://cic.iacr.org/p/1/1/21

 

Cheers, 

 

Guilin


  _____  


 

From:Peter C < <mailto:Peter.C=40ncsc.gov.uk@dmarc.ietf.org> Peter.C=40ncsc.gov.uk@dmarc.ietf.org>

To:Mike Ounsworth < <mailto:Mike.Ounsworth=40entrust.com@dmarc.ietf.org> Mike.Ounsworth=40entrust.com@dmarc.ietf.org>;Douglas Stebila < <mailto:dstebila@uwaterloo.ca> dstebila@uwaterloo.ca>;Russ Housley < <mailto:housley@vigilsec.com> housley@vigilsec.com>;John Gray < <mailto:John.Gray@entrust.com> John.Gray@entrust.com>;Max Pala < <mailto:M.Pala@cablelabs.com> M.Pala@cablelabs.com>;Klaußner, Jan < <mailto:Jan.Klaussner@bdr.de> Jan.Klaussner@bdr.de>;Deirdre Connolly < <mailto:durumcrustulum@gmail.com> durumcrustulum@gmail.com>;b... < <mailto:bas@cloudflare.com> bas@cloudflare.com>

Cc:'LAMPS' < <mailto:spasm@ietf.org> spasm@ietf.org>;Aron Wussler < <mailto:aron@wussler.it> aron@wussler.it>

Date:2024-07-16 18:32:37

Subject:[lamps] Re: Changing Composite KEM from RSA-KEM to RSA-OAEP

 

Mike,

 

I have not been following the recent composite KEM discussions so I missed the rationale for the switch to an X-Wing style combiner, but I think it might cause you a couple of problems.

 

Firstly, you can’t reuse the X-Wing proof with RSA-OAEP.  The X-Wing proof relies on there being a separation between the IND-CPA and OW-CPA security of ECDH-as-a-KEM – this is the Strong Diffie-Hellman Assumption.  I believe the IND-CCA2 security proof for RSA-OAEP limits any separation in that case – consider an adversary who makes no calls to the decapsulation oracle.  This doesn’t mean that the construction won’t work with RSA-OAEP, just that you need a new proof.

 

Secondly, X-Wing fundamentally relies on ML-KEM remaining ciphertext second pre-image resistant.  This means that it cannot mitigate ML-KEM implementation vulnerabilities.  If decapsulation fails to perform the ciphertext check properly, for example, then it’s trivial to find ML-KEM second pre-images and break the IND-CCA2 security of X-Wing.  This isn’t an issue if your goal is only to mitigate algorithmic vulnerabilities, but you need to be explicit about that.  At the very least, you need to reconsider “we also cannot immediately place complete trust in post-quantum replacements until they have undergone extensive scrutiny and real-world testing to uncover and rectify potential implementation flaws” in the introduction.

 

Peter

 

From: Mike Ounsworth <Mike.Ounsworth= <mailto:40entrust.com@dmarc.ietf.org> 40entrust.com@dmarc.ietf.org> 
Sent: Monday, July 8, 2024 10:27 PM
To: Douglas Stebila < <mailto:dstebila@uwaterloo.ca> dstebila@uwaterloo.ca>; Russ Housley < <mailto:housley@vigilsec.com> housley@vigilsec.com>; John Gray < <mailto:John.Gray@entrust.com> John.Gray@entrust.com>; Max Pala < <mailto:M.Pala@cablelabs.com> M.Pala@cablelabs.com>; Klaußner, Jan < <mailto:Jan.Klaussner@bdr.de> Jan.Klaussner@bdr.de>; Deirdre Connolly < <mailto:durumcrustulum@gmail.com> durumcrustulum@gmail.com>;  <mailto:b...@cloudflare.com> b...@cloudflare.com < <mailto:bas@cloudflare.com> bas@cloudflare.com>
Cc: 'LAMPS' < <mailto:spasm@ietf.org> spasm@ietf.org>; Aron Wussler < <mailto:aron@wussler.it> aron@wussler.it>
Subject: [lamps] Changing Composite KEM from RSA-KEM to RSA-OAEP

 

Hi all,

 

Based on discussion on-list, I have changed the RSA combinations from RSA-KEM [RFC5990] to  RSA-OAEP [RFC3560]. I am not confident that I have made this change properly, so I would like review of the RSA parts of draft-ietf-lamps-pq-composite-kem-04.

 

The pull request for just the RSA-KEM -> RSA-OAEP change can be found here:

*	 <https://urldefense.com/v3/__https:/github.com/lamps-wg/draft-composite-kem/pull/32__;!!FJ-Y8qCqXTj2!dFPHZkISK9FnToNL5VKkjPl0ZCZK_y1VGm5Ls-jqnCuxjdGPcLUnetVKPyjSBD0DHumnbj-o12-bZJ_RRBy_nkQynK2XhVubwC69$> https://github.com/lamps-wg/draft-composite-kem/pull/32

 

Note that in parallel, I also changed the construction to more closely match X-Wing. The combiner is now:

 

SHA3-*(counter || tradSS || mlkemSS || tradCT || tradPK ||  domSep)

 

So since the RSA CT and PK will now be bound, some of the CCR issues that were being discussed on the github are now moot?

 

Anyway, review welcome.

Thanks.

 

---
Mike Ounsworth
Software Security Architect, Entrust

 

_______________________________________________
Spasm mailing list --  <mailto:spasm@ietf.org> spasm@ietf.org
To unsubscribe send an email to  <mailto:spasm-leave@ietf.org> spasm-leave@ietf.org




 

-- 


Sophie Schmieg | Information Security Engineer | ISE Crypto |  <mailto:sschmieg@google.com> sschmieg@google.com

 




 

-- 


Sophie Schmieg | Information Security Engineer | ISE Crypto |  <mailto:sschmieg@google.com> sschmieg@google.com

 




 

-- 


Sophie Schmieg | Information Security Engineer | ISE Crypto | sschmieg@google.com <mailto:sschmieg@google.com>