[lamps] Re: [EXTERNAL] Re: Re: Changing Composite KEM from RSA-KEM to RSA-OAEP
"Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com> Fri, 26 July 2024 18:26 UTC
Return-Path: <sfluhrer@cisco.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 6341BC1519A9 for <spasm@ietfa.amsl.com>; Fri, 26 Jul 2024 11:26:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.639
X-Spam-Level:
X-Spam-Status: No, score=-9.639 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.148, DKIMWL_WL_MED=-0.001, 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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b="eHI0mbA/"; dkim=pass (1024-bit key) header.d=cisco.com header.b="lvoTzniX"
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 oATOMFBFhh7S for <spasm@ietfa.amsl.com>; Fri, 26 Jul 2024 11:26:51 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (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 59B48C15199D for <spasm@ietf.org>; Fri, 26 Jul 2024 11:26:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.com; i=@cisco.com; l=283790; q=dns/txt; s=iport; t=1722018411; x=1723228011; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=NoIvUtbmXNA9L1JbpLa5x73q+hBEwhgMyaj/psEqWE0=; b=eHI0mbA/yMuuPdBZGja/OXtt/U8ZwfqozcKLaNGBgWDWh2nCiCsSw4HH Dwv2KSIXiZpkgdcNTj61VWnI4hS8h7W6hW6qx66xZl0tfefkP04UsSSYb OXQEP9QiMP91MBWoj/LH4pwbyYK2KUmv3hbHHno3Mn7nRBrJEBqwi5I38 c=;
X-CSE-ConnectionGUID: 9Aw8F6sURKKV/aIZ0cgcWg==
X-CSE-MsgGUID: 9TvreQ48S+mi9cXubISAsw==
X-IPAS-Result: A0DzAQAO6qNmmI9dJa3OWXQGAQEBAQMCAwEBAQEBAQEOAwIBBxoBAQICOAVJjSY6hE+CZbAv4BSXMYODfhkP
IronPort-PHdr: A9a23:aGskfBQFCMI2sXaXi/Lod7c5c9pso47LVj580XJvo6hFfqLm+IztI wmCo/5sl1TOG47c7qEMh+nXtvX4UHcbqdaasX8EeYBRTRJNl8gMngIhDcLEQU32JfLndWo7S exJVURu+DewNk09JQ==
IronPort-Data: A9a23:EoSEwatVTEk+vBwq35ZdjIXr/OfnVFxeMUV32f8akzHdYApBsoF/q tZmKWyGaPuPamKgKtp1Pojl/EsFvMWDm4MyQAJtq3thRi8UgMeUXt7xwmUckM+xwmwvaGo9s q3yv/GZdJhcokf0/0rrb/646yEhiMlkf5KkYMbcICd9WAR4fykojBNnioYRj5Vh6TSDK1vlV eja/YuHaTdJ5xYuajhIs/3Z9ks11BjPkGpwUmIWNKgjUGD2zxH5PLpHTYmtIn3xRJVjH+LSb 47r0LGj82rFyAwmA9Wjn6yTWhVirmn6ZFXmZtJ+AsBOszAazsAA+v9T2Mk0NS+7vw60c+VZk 72hg3AfpTABZcUgkMxFO/VR/roX0aduoNcrKlDn2SCfItGvn3bEm51T4E8K0YIwq89oUU8Q7 sEiCxMzKRmitbq9z7mERbw57igjBJGD0II3oHpsy3TSCuwrBM+FSKTR7tge1zA17ixMNa+BP IxCNnw+N1KZP0Yn1lQ/UPrSmM+ziH3icydVsnqepLE85C7YywkZPL3FaoGOJ4XXHJkN9qqej jP64X70O01KD5+ayGuOwm+mp9TmhjyuDer+E5Xjq6Y12wfMroAJMzUNTVKgpNG4h1KwHdVFJ CQpFjEGt6M+8gmgScPwGkL+q3+ftRlaUN1VewEn1O2T4vv9/Fa3WHM5dB1iVpsvlf1uTjMh6 VDcyrsFGgdTmLGSTHuc8JKdojWzJTUZIAc+icksE1dtDz7L/t1bs/7fcuuPBpJZmTEcJN0d6 yqBoC57jLIJgItUka665lvAxTmro/AlrzLZBC2JAApJDSsgOOZJgrBED3CAtp6sy67CFTG8U IAswZT20Qz3JcjleNaxaOsMBqq1wP2OLSfRh1Vid7F4qG70qyP8JtgIvmsmTKuMDiriUWK1C KM0kV4BjKK/wFPwNsebnqroUZ1zlvm6fTgbfq2MM4MeCnSOSON31HozPRHLhT+FfLkEmqAkM pDTate3EXsfEuxmyjHwL9rxIpd1rh3SMVj7HMihpzz+iOL2TCfMGd8tbgDUBshnt/zsnekg2 4sFXyd8408BALSWj+i+2dN7EG3m2lBgXcGm8pQPJrPdSuekcUl4Y8LsLXoaU9UNt4xel/zD+ Te2XUow9bY1rSSvxdmiApy7VI7SYA==
IronPort-HdrOrdr: A9a23:GzfmxaO+Rjsc78BcT47255DYdb4zR+YMi2TDiHoBKiC9I/b5qy nxppUmPEfP+UcssREb9expOMG7MArhHO1OkPks1NaZLUbbUQ6TXeNfBOTZskDd8kHFh4lgPO JbAtZD4b7LfBZHZKTBkXWF+r8bqbHtntHM9IPjJjVWPH5Xgspbnn9E43OgYzdLrX59dOEE/f Snl6x6jgvlU046Ku68AX4IVfXCodrkqLLKCCRtOzcXrCO1oXeN8rDVLzi0ty1yb9pI+9gf2F mAtza8yrSosvm9xBOZ/XTU9Y5qlNzozcYGLNCQi+AOQw+cyjqAVcBEYfmvrTo1qOag5BIBi9 /XuSotOMx19jf4Yny1mx3wwAPtuQxeqEMKiGXow0cLk/aJAA7SOPAxwr6xtSGprXbIiesMlZ 6jGVjp7qa/QymwxBgVrOK4JC2C3nDE00bK19RjzkC2leAlGeVsRUt1xjIPLL4QWC3984wpC+ 9oEYXV4+tXa0qTazTDsnBo28HEZAV4Iv6qeDlLhiWu6UkcoFlpi08DgMAPlHYJ85wwD5FC+u TfK6xt0LVDVNUfY65xDPoIBZLfMB2AfTvcdGaJZVj3HqAOPHzA75bx/bUu/emvPJgF1oE7lp jNWE5R8WQyZ0XtA8uT24AjyGGBfEytGTD2js1O7ZlwvbPxALLtLC2YUVgr19Ctpv0Oa/erEs pb+KgmdcMLAVGebrqhhTeOLqW6AUNuJPEohg==
X-Talos-CUID: 9a23:Hlx/T24aSMSy082kstsspWcLSu57aUDn71TuZEaZOz5iR7aqRgrF
X-Talos-MUID: 9a23:/EERIQ6LQH78XDHGmVYxrkTlxow537q0BXlRwa5FvsjVPhxtMRampS+oF9o=
X-IronPort-Anti-Spam-Filtered: true
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-9.cisco.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Jul 2024 18:26:50 +0000
Received: from rcdn-opgw-5.cisco.com (rcdn-opgw-5.cisco.com [72.163.7.169]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 46QIQob1010152 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <spasm@ietf.org>; Fri, 26 Jul 2024 18:26:50 GMT
X-CSE-ConnectionGUID: 8myoFoiZSBKC9I6+Q08sDQ==
X-CSE-MsgGUID: lnTfED7TSeSihtADwSwMDw==
Authentication-Results: rcdn-opgw-5.cisco.com; dkim=pass (signature verified) header.i=@cisco.com
X-IronPort-AV: E=Sophos;i="6.09,239,1716249600"; d="scan'208,217";a="14310389"
Received: from mail-mw2nam12lp2048.outbound.protection.outlook.com (HELO NAM12-MW2-obe.outbound.protection.outlook.com) ([104.47.66.48]) by rcdn-opgw-5.cisco.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Jul 2024 18:26:49 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=nyuUAY/IO6Rukh2wPzwbbr6VBTgqmDRcWub9a3K/QNu8NpefAcdwL47wZzHJS2Ct3al6eMZqh5xEjW6TaU4dyFk1b5fQL9o16mGUK45Z1v6z9E9JVzu2OKXazPDZbWtWMe0HcyMbQ2Ncv7HB13HFyQN7tEQPG6Gl2rKQZoFIxuuEDWvzS+IMwd555OqrzxNoBmJT3Gpb1pZEhk6fF2ttIpswE22lVoRRndJuMI2Yc89vk1gI4zAkgmJ5jclDvcjA9bP5PDCO7GGwbDEKY6GCbs99XdEw4g+tpjITez0RZt75O56geJSUx9p1CWcNeoeD/DHqOCGK9w+eDJZbyRThDQ==
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=NoIvUtbmXNA9L1JbpLa5x73q+hBEwhgMyaj/psEqWE0=; b=IYQqnlPEEbhFK+dWbTwZDcx/bpNL4V8vCfUrPo/u5rReQX37LvlRpEcYiFS1+PwDNKedg5hyNBwLAt4num7YHkmNXFc/LD7HriMq0YPWDxuCxHG4jsUvlQVO/axHs2eSsnQ2Zl05mivJ9Y0LgBfyTLXZR3wwxEW1Zb/gEuqgvH84ECdwONimwy6OQQl1N1d1eZDR8R2xzL1uT5yW+GtG04rcfo+R5k/XqRdoP/wFW0716+T9pJIb5hIMRxrDML4cRxqYOPRGJXZQ+di7MbsfWglIfiq+4xTxbTe7XsjNPhe2OwJol5XX9MhKXnuQWXv44NnPy8fsz62xhp8gouYizQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NoIvUtbmXNA9L1JbpLa5x73q+hBEwhgMyaj/psEqWE0=; b=lvoTzniXrR5eFB0uo48f0GtQS21eCWadRDnDL0nZejELhBBHHFdEjv6vP9/CxIUkEi5CfYXpeXyqWfAOraJtgd8G1zVTgeuEIT35Mw3W6zoEvBuU/VDBhNB6qbU9q7jPD/ltLTJjyXhxUelTJACXE94Vq8k17eAk8MzcMm3iOEY=
Received: from CH0PR11MB5444.namprd11.prod.outlook.com (2603:10b6:610:d3::13) by SA0PR11MB4686.namprd11.prod.outlook.com (2603:10b6:806:97::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7784.31; Fri, 26 Jul 2024 18:26:46 +0000
Received: from CH0PR11MB5444.namprd11.prod.outlook.com ([fe80::5f89:ba81:ff70:bace]) by CH0PR11MB5444.namprd11.prod.outlook.com ([fe80::5f89:ba81:ff70:bace%6]) with mapi id 15.20.7784.020; Fri, 26 Jul 2024 18:26:46 +0000
From: "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>
To: Sophie Schmieg <sschmieg=40google.com@dmarc.ietf.org>, Piotr Popis <piotr.popis=40enigma.com.pl@dmarc.ietf.org>
Thread-Topic: [lamps] Re: [EXTERNAL] Re: Re: Changing Composite KEM from RSA-KEM to RSA-OAEP
Thread-Index: AQHa18Xzsp6qtCvm/kK+sWoJGvPVirH59Z0AgAqVQQCAASXugIAAe4uAgADyrICAANyXAIAABVEAgAClFYCAAKtOAIAAD40g
Date: Fri, 26 Jul 2024 18:26:45 +0000
Message-ID: <CH0PR11MB54442EC1C6046FB5C55CDEA8C1B42@CH0PR11MB5444.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> <CH0PR11MB5739DE44C8ED5B924A526D149FAB2@CH0PR11MB5739.namprd11.prod.outlook.com> <SN7PR14MB64926D4A086D3B87BDAAF10F83AB2@SN7PR14MB6492.namprd14.prod.outlook.com> <006901dadf2a$c6a19670$53e4c350$@enigma.com.pl> <CAEEbLAbNH4jXAy9N2mUmPmzLH8NzCXmiZ_qkEObmxoBN14oFKA@mail.gmail.com>
In-Reply-To: <CAEEbLAbNH4jXAy9N2mUmPmzLH8NzCXmiZ_qkEObmxoBN14oFKA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: CH0PR11MB5444:EE_|SA0PR11MB4686:EE_
x-ms-office365-filtering-correlation-id: bd27ebaf-44af-4d00-9d61-08dcada0819a
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|4022899009|1800799024|376014|38070700018;
x-microsoft-antispam-message-info: r/75AZ+A+xUbvRcRq2W7wZ37ULbbq6srTD8AjUbHDosbPX9CbahrYq/n7k9iZyYhiteMi3/ICpUL9x8FnmcfxDffKPUY2px0lBs/mHajncWL9VMudb+1Nh9XEP0DcnAnJP+fhmU+XtYfFQc+gbgGZJb+kFF/RyOkpDnOlePmrt7Nw3ncZ4yZZsIs+G6jQaOPPQ5/Q7VtEtQOzMOlo29OwXqj8OBwx2gNOwULMDxugF7T+pOkPR9Dw0QfzQWzRnCBnZQzQqFx7TFLy6HvY4p/AjGEmWMHLMa64PBH9m7bWu7beKU9K5fyO4Ff78dCsUzm3dl6NLWpS1kPkeebRiCd/APZ7LrKgdDFOvdSM96X3AyRu39VG1Wobh4QFUsdG+RXbqufumdCgA/PSAmUjK8brgFKU+ywVLqXg6NKbR7A7T2G6p/NE35o4STc+wYsSBHmjCR1Ta6K04wN4GBvdon2Xhek6nGizynzdNwkTbWJkCVPNMvxK5c4bYgYhgmtHkaAFYBIdRJqBLETB7Ds3H7pGGMd7VwA2kyeoKlfA7OCnn7D7tM+8uYD9X3O+zMahe6ehA+RyPz+/vhBjlGv55B7EPnCrUkFtPVu9TURrc4gGuISKuaQX/xHUj+ySXKPbylMckNmLiGUqwrEbCXm2O/fVTJS/cus9COZpssePvavhP/qHUCGQ1QfmR7mxLBZ8bK/ozYmfdvSw0Li41jzP+v8WpywBwF1qKws77ZYfOGXdLyCV4gvaagNh1NIqH/xqR0dognX74d+G/2Cv6uX/IL4/rVvZq23tgGZHnGHUUZa6HmcqxsWqEgdBnLXihUcAtIe2ruxulCrT59+9WgNdAu0NFtqiYo2S2lwVCs2nXanhHyuN9YHhYuSX11Xu40JXiRHCQe0+ZxuVOvDrfpdh+NMP9mC2lITubxM2DqadTYxlI4vc/Jsg5OMTBuJj4CdU0XRKiB9ON8gj+Hcc/bb2bdoON7bDRwTu/4adD4ytL0yr5K28QE0TVqyFz2U3qU6zyb2pv9AxzSyYHr/nOqr7cbZbtGotwemj+6UH/gk6FezqdVMMzfVuzyGycHRy1S1ZMcIKAtQgZaYysdjGv75iJVa38RssG9FROpwvMmwzhdeyeWVIRgvY5l+qywjIG+XUg/tTFbYPueCIrz63bm3INbKWDESHTmF+Ipl5M0fC2JNEZRkB6/ElvKaACbNZILKJkh1vCIhgHdoBCkmbiejk2Jxv1myhGFhtsZOCyla/8lzCOZNmGvD+oISGbmWdiNmfeQIfkLkm6DqxEweVfPD6N1+5BefISjhv09fpAzAyi2UZt4sUdzulSVIXQp465AlkbjNMZqrmKKnEadT/OiRASCGDdooH+z/XV43ChcZO7h5d20=
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH0PR11MB5444.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(4022899009)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 0Rp5Zx7LOcWVSwfvH/1saYwU0rA6qtBphM2zZnSK3Nol+Hr6q07zXyxqSYnC7FrxBUQaOSehCIu2PKqEOwIpzw03IwvMgzET5vfrzaM7WLfVeNYtbQVYHZjWKSsykRXOP2Qa4kI9suqBKDoOsPbSd44eP33FoMmUsJRkdYXarRmh/WAPcquX3UiJmas7eBcK6XBvna+oCm2eXF5QAuwHQSPsPSR6nOHbTK7g6gagdlR6djRrtls1v4iIG7XBfSOpxbZtwVYMMYervsVyq01QorY1gq42S/HIDRJKLwVceOeVBs8LAG6Jvk2Xx6gUBMO9QQorO8wMPyHylpjSSICh7wM7sBIH0p38bAlIkRBpxLHGdu3SYmSOgTbaFiuDSGeJEgOZ1Waf0p8zH5vUsJUmCLeXjnsBcLzb4FywSfTy8Rfu+fIK1GSMukdC+IKssAb0pKq12rh6xxVOwbHFRbmxkc8pfU10u493R84k2i43LAMacx9Xrgz9VEIJ80L6VYCA7eCqk9FFxbJcIpFObr4hvfD/FJpxkmkDEVx93Ub+kZah+I5AIbtppZpp34rwQul2g9z7nGcd7GGurYnBRMd31VEfH+37PSIkCfne6Vtpm1RPgjISu5ECExqUxd2Zkk6W3uYJJZzUbeanAqpsK65XdNhh35Vm1OSLxyqzXv6EWMZ6sbxqZy8tc4Y7Nqyeey6z9C6g6BHzEEoKb0EE8NMBFTQJBpTQV4ekeBCXNSmnYL33M6YaQIu1TfEMvLckv1k7w5zyEGAPmrYSXK4K3DqLxuvHAnDQ1PSpwSFt9X9rpgv7L4NyxuILMt3B6j/ycoUH9k8TRdmaMXA1w4r2SonFe5nzTcg3Eip09XstuSZQJJWw8kCWlazBtCVGz+ZjEaN3PqjY0Hnh53Wh5jvy5cijCPgcmp/JYAQvikiP9NwoMGW7Cut6LsVpW+ELM/yThRd+NyZRljWqjrxW4o3m67DVq4Fte2gXcGMxIjCdzBQivbfOd5dqO1eQWopqR1w7LAHSdMJLb5Xab209WcCtUbZsJJ1mNIkUoxKNsfCXPMfY4cd+CD1a9wcLNyrILlj4cK8ndkw7XxoG6WoVDsy2aYCirTFWaXQMKz5us134sdAhQskW9ZpCx8yb36OyqyFP6ehU+bNAATQbbRPzSmWpMRtXbnGJdPmEmTk6JkPuXIuAfcu3JjdrrQd4mnQbZXOG5zx8GhJv3rJk+UlF977A1breajPRLVIyLApAQl3WuBMlRU6LAd8aQNq2ucmRjryuf56hQlvBMQ6lp3V2P1/eRLNe8hcNzx4D6T/LO1BWpRVPLxT9lAsbw5le2zwipGBsQ9MZz1jtVDB13Q0U98dWywj1jOR+sLVBw/VZmNiLK6ov051eI8A5xq8f52ZZD2U10b8V8HON/6OTIk2Y/S/4I2LEf1ZcwnMcSbu0nkQa8KcIkY3dcY4hM95Xo/+OsE3gymtxvmqnaxhSy7T/ZOqlBhiLxcIZDrvXsGg5l8O8VgxGsMpv1nWut5GBrVFt+N5SvKTQ8m05OW+lhHxe7PP4+M9e5H/5IgZ0l4i3Jgv3j75arwYdXxIJibU9KKAziFMmPia3K985Fbtq2yQ8dscQ60hjTRLO5SVTmxU68CyHovqKczs=
Content-Type: multipart/alternative; boundary="_000_CH0PR11MB54442EC1C6046FB5C55CDEA8C1B42CH0PR11MB5444namp_"
MIME-Version: 1.0
X-OriginatorOrg: cisco.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CH0PR11MB5444.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: bd27ebaf-44af-4d00-9d61-08dcada0819a
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2024 18:26:46.0194 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Ba0YYkZQkziKaVBY5Vf2IWj5/OWSXaovjjvguzfLOghlmGdyXp2sQEnCoAt4om2QEOfu5GXvNXp2mAyifVrN+Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR11MB4686
X-Outbound-SMTP-Client: 72.163.7.169, rcdn-opgw-5.cisco.com
X-Outbound-Node: rcdn-core-7.cisco.com
Message-ID-Hash: GVD5XS6I6OC24MT24DYI226AOW33G2CB
X-Message-ID-Hash: GVD5XS6I6OC24MT24DYI226AOW33G2CB
X-MailFrom: sfluhrer@cisco.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: Tim Hollebeek <tim.hollebeek@digicert.com>, Mike Ounsworth <Mike.Ounsworth@entrust.com>, 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/T56KOXY-lWHoS9dk-OX53PFFN04>
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>
+1 Thank you, Sophie. I was going to write an email expressing these thoughts (but you worded them better than I could). How I would express it: if we believe that RSA-2048 is secure from classical computing (and we know that it’s not secure from quantum computing), then RSA-3072 or RSA-4096 is not any better. Given that the we’re inserting the classical part (RSA, ECDSA, EdDSA) and the postquantum part (ML-DSA) to address different attacks and vulnerabilities, there is no reason why “security matching” should be mandated. The RSA public key implicitly includes the key size, hence I do not see the reason why a specific combination should explicitly mandate, say, RSA-3072. From: Sophie Schmieg <sschmieg=40google.com@dmarc.ietf.org> Sent: Friday, July 26, 2024 1:23 PM To: Piotr Popis <piotr.popis=40enigma.com.pl@dmarc.ietf.org> Cc: Tim Hollebeek <tim.hollebeek@digicert.com>; Mike Ounsworth <Mike.Ounsworth@entrust.com>; LAMPS <spasm@ietf.org> Subject: [lamps] Re: [EXTERNAL] Re: Re: Changing Composite KEM from RSA-KEM to RSA-OAEP We should specify the full key whenever we specify a key, so having the RSA key size in the OID is a good idea, and leaving it out would lead to underspecified keys. I do not think we should mindlessly match security levels. You already make an exception for RSA-2048 (for a good reason), showing that we have different motivations for the security level in classic and PQC parts. We can expand on these further: For the classical part, having well established implementations is the key motivator. I'm relatively certain that RSA-2048, -3072, -4096, ECDH/ECDSA-P256, -P384, -P521, X25519, X448, etc are going to be broken with only months between them, by a quantum computer scaling up the last few powers of 2. So from a security perspective, all of these algorithms have the same security level leaving compliance and implementation adoption as the main motivator for this side of the hybrid. On the PQC part on the other hand, the main threats are complete breakage (as in polynomial attacks, where the current security level doesn't really matter at all) and improvements in the exponential attacks, moving the security level, but not the asymptotic behavior of the attack. For the first type of attack, the defense in a hybrid is having the classic part in there at all, and hoping that the attack is discovered early enough to mitigate the worst of the vulnerability. The more interesting from a hybrid standardization perspective is the second type of attacks. Lattice schemes in particular have some likelihood of minor improvements in lattice reduction algorithms, shaving off the odd bit here or there. From that perspective ML-KEM512 is at risk of falling below 128 bits of security by the time a quantum computer arrives, while ML-KEM768 has plenty of breathing room to not be at risk from these types of attacks. To summarize: From a security perspective, X25519-ML-KEM768 (aka X-Wing) addresses the security risks most comprehensively and should be used as the goto hybrid for situations when no other constraints apply. (This assumes that no adversaries with access to Dyson Swarms emerge, and 128 bit of security remaining secure for the foreseeable future) For compliance, the most important considerations are on the classic side of the hybrid, with the only PQC compliance requirements going beyond the security analysis above being CNSA's wish for ML-KEM1024. But CNSA2 also prefers non-hybrid solutions, so I'm not sure whether we should hybridize with ML-KEM1024 at all. For ML-KEM512, there currently seems to be no compliance forcing its adoption over ML-KEM768, with only some performance considerations having slight preferences, but in my opinion the security considerations weigh heavier here, and we should find other ways to alleviate the performance issues. On Fri, Jul 26, 2024 at 12:10 AM Piotr Popis <piotr.popis=40enigma.com.pl@dmarc.ietf.org<mailto:40enigma.com.pl@dmarc.ietf.org>> wrote: Hi Tim and All The sender of the message must know the recipient's certificate (or at least its public key). In an X.509 certificate with an RSA public key, the subjectPublicKeyInfo - subjectPublicKey field has the following syntax: RSAPublicKey ::= SEQUENCE { modulus INTEGER, -- n publicExponent INTEGER } -- e That is, the length of the RSA algorithm key is contained in the "subjectPublicKey" field. It should be added that for the ECC algorithm it is different - the type of curve is encoded in the “parameters” field of the AlgorithmIdentifier sequence. Our general rule: into each composite KEM algorithms parameters field in the AlgorithmIdentifier sequence must be empty. So considering above, in the case of ECC we must specify the curve type in the OID, but this does not apply to RSA. Although in the case of RSA-OAEP RFC 4055 defined the RSAES-OAEP-params sequence, which is generally placed in the parameters field of the AlgorithmIdentifier sequence (see Section 4.1 of RFC 4055), in our standard it is specified in Section 5.2, so we don’t’ need parameters as well. --------- Piotr Popis From: Tim Hollebeek <tim.hollebeek=40digicert.com@dmarc.ietf.org<mailto:40digicert.com@dmarc.ietf.org>> Sent: Thursday, July 25, 2024 11:19 PM To: Mike Ounsworth <Mike.Ounsworth=40entrust.com@dmarc.ietf.org<mailto:40entrust.com@dmarc.ietf.org>>; Piotr Popis <piotr.popis@enigma.com.pl<mailto:piotr.popis@enigma.com.pl>>; 'Sophie Schmieg' <sschmieg=40google.com@dmarc.ietf.org<mailto:40google.com@dmarc.ietf.org>> Cc: 'LAMPS' <spasm@ietf.org<mailto:spasm@ietf.org>> Subject: [lamps] Re: [EXTERNAL] Re: Re: Changing Composite KEM from RSA-KEM to RSA-OAEP If you don’t get the RSA key size from the OID, where do you get it from? We want fully specified options with no parameters. -Tim From: Mike Ounsworth <Mike.Ounsworth=40entrust.com@dmarc.ietf.org<mailto:Mike.Ounsworth=40entrust.com@dmarc.ietf.org>> Sent: Thursday, July 25, 2024 2:00 PM To: Piotr Popis <piotr.popis@enigma.com.pl<mailto:piotr.popis@enigma.com.pl>>; 'Sophie Schmieg' <sschmieg=40google.com@dmarc.ietf.org<mailto:sschmieg=40google.com@dmarc.ietf.org>> Cc: 'LAMPS' <spasm@ietf.org<mailto:spasm@ietf.org>> Subject: [lamps] Re: [EXTERNAL] Re: Re: Changing Composite KEM from RSA-KEM to RSA-OAEP 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<mailto:piotr.popis@enigma.com.pl>> Sent: Thursday, July 25, 2024 2:50 AM To: 'Sophie Schmieg' <sschmieg=40google.com@dmarc.ietf.org<mailto:sschmieg=40google.com@dmarc.ietf.org>> 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 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://github.com/lamps-wg/draft-composite-kem/issues/38<https://urldefense.com/v3/__https:/github.com/lamps-wg/draft-composite-kem/issues/38__;!!FJ-Y8qCqXTj2!ZofDXZdCn3JkPrRpmxFESh-FAov2866O2WFFt7ekijmYiiRxITpqYi5s0-AzF_3l0ruI36vZ21rEkqYUAJUyusfBa1yI$> 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://github.com/lamps-wg/draft-composite-kem/issues/37<https://urldefense.com/v3/__https:/github.com/lamps-wg/draft-composite-kem/issues/37__;!!FJ-Y8qCqXTj2!ZofDXZdCn3JkPrRpmxFESh-FAov2866O2WFFt7ekijmYiiRxITpqYi5s0-AzF_3l0ruI36vZ21rEkqYUAJUyulNYtViQ$> 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. @Russ Housley<mailto:housley@vigilsec.com>, @Tim Hollebeek<mailto:tim.hollebeek@digicert.com> 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 <sschmieg=40google.com@dmarc.ietf.org<mailto:sschmieg=40google.com@dmarc.ietf.org>> Sent: Tuesday, July 16, 2024 5:51 PM To: Mike Ounsworth <Mike.Ounsworth@entrust.com<mailto:Mike.Ounsworth@entrust.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>>; Russ Housley <housley@vigilsec.com<mailto:housley@vigilsec.com>>; 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: [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=40entrust.com@dmarc.ietf.org<mailto: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://github.com/lamps-wg/draft-composite-sigs/issues/25<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-kem/issues/38<https://urldefense.com/v3/__https:/github.com/lamps-wg/draft-composite-kem/issues/38__;!!FJ-Y8qCqXTj2!fCKoT58oe9AVfJ3cTt3zcR_Frw3eAl1zKnS4IRCd6DothBDUajkGdLFTwBqMuR-4mK-bzAtiEcsmgsS8cUy9VxL_CFFwrmhmy_vV$> > 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=40google.com@dmarc.ietf.org<mailto:40google.com@dmarc.ietf.org>> Sent: Tuesday, July 16, 2024 12:47 PM To: Wang Guilin <Wang.Guilin@huawei.com<mailto:Wang.Guilin@huawei.com>> Cc: Peter C <Peter.C@ncsc.gov.uk<mailto:Peter.C@ncsc.gov.uk>>; Mike Ounsworth <Mike.Ounsworth@entrust.com<mailto:Mike.Ounsworth@entrust.com>>; Douglas Stebila <dstebila@uwaterloo.ca<mailto:dstebila@uwaterloo.ca>>; Russ Housley <housley@vigilsec.com<mailto:housley@vigilsec.com>>; 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>>; Wang Guilin <Wang.Guilin@huawei.com<mailto: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=40huawei.com@dmarc.ietf.org<mailto: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://cic.iacr.org/p/1/1/21<https://urldefense.com/v3/__https:/cic.iacr.org/p/1/1/21__;!!FJ-Y8qCqXTj2!dFPHZkISK9FnToNL5VKkjPl0ZCZK_y1VGm5Ls-jqnCuxjdGPcLUnetVKPyjSBD0DHumnbj-o12-bZJ_RRBy_nkQynK2XhRpsAQlS$> Cheers, Guilin ________________________________ From:Peter C <Peter.C=40ncsc.gov.uk@dmarc.ietf.org<mailto:Peter.C=40ncsc.gov.uk@dmarc.ietf.org>> To:Mike Ounsworth <Mike.Ounsworth=40entrust.com@dmarc.ietf.org<mailto:Mike.Ounsworth=40entrust.com@dmarc.ietf.org>>;Douglas Stebila <dstebila@uwaterloo.ca<mailto:dstebila@uwaterloo.ca>>;Russ Housley <housley@vigilsec.com<mailto:housley@vigilsec.com>>;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>> Cc:'LAMPS' <spasm@ietf.org<mailto:spasm@ietf.org>>;Aron Wussler <aron@wussler.it<mailto: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=40entrust.com@dmarc.ietf.org<mailto:40entrust.com@dmarc.ietf.org>> Sent: Monday, July 8, 2024 10:27 PM To: Douglas Stebila <dstebila@uwaterloo.ca<mailto:dstebila@uwaterloo.ca>>; Russ Housley <housley@vigilsec.com<mailto:housley@vigilsec.com>>; 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...@cloudflare.com<mailto:b...@cloudflare.com> <bas@cloudflare.com<mailto:bas@cloudflare.com>> Cc: 'LAMPS' <spasm@ietf.org<mailto:spasm@ietf.org>>; Aron Wussler <aron@wussler.it<mailto: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://github.com/lamps-wg/draft-composite-kem/pull/32<https://urldefense.com/v3/__https:/github.com/lamps-wg/draft-composite-kem/pull/32__;!!FJ-Y8qCqXTj2!dFPHZkISK9FnToNL5VKkjPl0ZCZK_y1VGm5Ls-jqnCuxjdGPcLUnetVKPyjSBD0DHumnbj-o12-bZJ_RRBy_nkQynK2XhVubwC69$> 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 -- spasm@ietf.org<mailto:spasm@ietf.org> To unsubscribe send an email to spasm-leave@ietf.org<mailto:spasm-leave@ietf.org> -- Sophie Schmieg | Information Security Engineer | ISE Crypto | sschmieg@google.com<mailto:sschmieg@google.com> -- Sophie Schmieg | Information Security Engineer | ISE Crypto | sschmieg@google.com<mailto:sschmieg@google.com> -- Sophie Schmieg | Information Security Engineer | ISE Crypto | sschmieg@google.com<mailto:sschmieg@google.com> -- Sophie Schmieg | Information Security Engineer | ISE Crypto | sschmieg@google.com<mailto:sschmieg@google.com>
- [lamps] Changing Composite KEM from RSA-KEM to RS… Mike Ounsworth
- [lamps] Re: Changing Composite KEM from RSA-KEM t… Russ Housley
- [lamps] Re: [EXTERNAL] Re: Changing Composite KEM… Mike Ounsworth
- [lamps] Re: Changing Composite KEM from RSA-KEM t… Sophie Schmieg
- [lamps] Re: Changing Composite KEM from RSA-KEM t… Ilari Liusvaara
- [lamps] Re: [EXTERNAL] Re: Re: Changing Composite… Piotr Popis
- [lamps] Re: [EXTERNAL] Re: Re: Changing Composite… Sophie Schmieg
- [lamps] Re: [EXTERNAL] Re: Re: Changing Composite… Scott Fluhrer (sfluhrer)
- [lamps] Re: [EXTERNAL] Re: Changing Composite KEM… Mike Ounsworth
- [lamps] Re: Changing Composite KEM from RSA-KEM t… Peter C
- [lamps] Re: Changing Composite KEM from RSA-KEM t… Wang Guilin
- [lamps] Re: [EXTERNAL] Re: Re: Changing Composite… Mike Ounsworth
- [lamps] Re: [EXTERNAL] Re: Re: Changing Composite… Sophie Schmieg
- [lamps] Re: [EXTERNAL] Re: Re: Changing Composite… Mike Ounsworth
- [lamps] Re: [EXTERNAL] Re: Re: Changing Composite… Falko Strenzke
- [lamps] Re: [EXTERNAL] Re: Re: Changing Composite… Piotr Popis
- [lamps] Re: [EXTERNAL] Re: Re: Changing Composite… Sophie Schmieg
- [lamps] Re: [EXTERNAL] Re: Re: Changing Composite… Mike Ounsworth
- [lamps] Re: [EXTERNAL] Re: Re: Changing Composite… Tim Hollebeek
- [lamps] Re: [EXTERNAL] Re: Re: Changing Composite… Piotr Popis
- [lamps] Re: [EXTERNAL] Re: Re: Changing Composite… Phillip Hallam-Baker
- [lamps] Re: [EXTERNAL] Re: Re: Changing Composite… Piotr Popis
- [lamps] Re: [EXTERNAL] Changing Composite KEM fro… Mike Ounsworth
- [lamps] Re: [EXTERNAL] Re: Re: Changing Composite… Dang, Quynh H. (Fed)
- [lamps] Re: [EXTERNAL] Re: Re: Changing Composite… John Mattsson
- [lamps] Re: [EXTERNAL] Re: Re: Changing Composite… Mike Ounsworth
- [lamps] Re: [EXTERNAL] Changing Composite KEM fro… Hubert Kario