Re: [lamps] [EXTERNAL] Re: Multiple drafts with PQ algorithm key encodings that are not compatible.
Tomas Gustavsson <Tomas.Gustavsson@keyfactor.com> Fri, 30 September 2022 06:27 UTC
Return-Path: <Tomas.Gustavsson@keyfactor.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 C171DC1526E4; Thu, 29 Sep 2022 23:27:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.807
X-Spam-Level:
X-Spam-Status: No, score=-1.807 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=keyfactorinc.onmicrosoft.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 D5H5rOjP73z9; Thu, 29 Sep 2022 23:27:32 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130093.outbound.protection.outlook.com [40.107.13.93]) (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 64833C14CE24; Thu, 29 Sep 2022 23:27:31 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nUlL5NmYkMAZdTnqLBxtRrlPKifHcEHzSdGxQN230/1OiO58WZhi8bL4m/7DzUKEajZ636pNPgOpBCON+THGUfuoj5aJJPtgmEbQRQSZiNa3tspzxkeIZIhRMl62aAkOy1rEwXgKv/XpD9K0shrSMx1Nvq1woCRhJyYIKqtpB8wgKCsuh4HAfSAUDLssEN0NyRf9zRoKkJe6McQQmiW5IHztJOw8A9p/3kQtiG3vGTIqvAEq/E23X0FgIkTacB6Wcgr/5wgX5GVhQsawAcYnLneMPM/xpr9TLaTlyKUU9y+UDuH1tBoTO0Cr7aWz11IphvkU9NNNjVAeVRtzeMPx+w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+8AAb4M5DKasQCtfdI80S1pntVdLS+p0qhMyNcxBTro=; b=KE8Dq2SgZgjlnujZ75c/yk2J2h4lel4KcpijJaiEWBHYIM8t8RXx0ZUYY+TVenK9LckBogHwzByhwYDjtJ/y4ccF1LFC9JIbsLT3WBMsqILow1cBgLsI1Sm2qOM+FSnzR62u0v2t1mGGeU+n0rQDIbLPxFh5+2fqALi8jbO0M+2eb7fAI9hUf+/ejmAIkIE1dVIqVsmlgKbpizaAF9gfUeH+tIA4JKb/4kUWTgTURikOMNhG1SAgUUL5Rdh8nfY0f35XzgPkf4Z1Pbw7388Wr9wtXAklAvA1uadSkaXgbZHCbHz0TTWAK796DBB6tHJ3tmknXI8rA4y/gd6S9nN9aw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=keyfactor.com; dmarc=pass action=none header.from=keyfactor.com; dkim=pass header.d=keyfactor.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=KeyfactorInc.onmicrosoft.com; s=selector1-KeyfactorInc-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+8AAb4M5DKasQCtfdI80S1pntVdLS+p0qhMyNcxBTro=; b=Zb5PtJcTKQuie6CH8A63yPfTz+9eQv6RYlGBnty44lQq2kQdziHCksiHnQOhpBnxbYHdXVu0CQWpS16fbXapWGgPcA5GVgEHGnsZY8+DOMwPwrqx0zCzhy87lSdgCiNZSpB6JEKHkeOxu15OzP4EPUjRlDJk2sfJZzOBOkUOC+w=
Received: from DU0PR03MB8696.eurprd03.prod.outlook.com (2603:10a6:10:3ef::5) by VI1PR03MB6479.eurprd03.prod.outlook.com (2603:10a6:800:192::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5676.23; Fri, 30 Sep 2022 06:27:24 +0000
Received: from DU0PR03MB8696.eurprd03.prod.outlook.com ([fe80::5058:8832:239d:d194]) by DU0PR03MB8696.eurprd03.prod.outlook.com ([fe80::5058:8832:239d:d194%8]) with mapi id 15.20.5676.023; Fri, 30 Sep 2022 06:27:24 +0000
From: Tomas Gustavsson <Tomas.Gustavsson@keyfactor.com>
To: John Gray <John.Gray=40entrust.com@dmarc.ietf.org>, "Markku-Juhani O. Saarinen" <mjos@pqshield.com>
CC: "pqc@ietf.org" <pqc@ietf.org>, "spasm@ietf.org" <spasm@ietf.org>, "cfrg@ietf.org" <cfrg@ietf.org>, "Massimo, Jake" <jakemas@amazon.com>, "Panos Kampanakis (pkampana)" <pkampana@cisco.com>, Sean Turner <sean@sn3rd.com>, "bas@westerbaan.name" <bas@westerbaan.name>, "cvvrede@gmail.com" <cvvrede@gmail.com>, "sid@zurich.ibm.com" <sid@zurich.ibm.com>, "bhe@zurich.ibm.com" <bhe@zurich.ibm.com>, "tvi@zurich.ibm.com" <tvi@zurich.ibm.com>, "osb@zurich.ibm.com" <osb@zurich.ibm.com>, "dieter.bong@utimaco.com" <dieter.bong@utimaco.com>, "joppe.bos@nxp.com" <joppe.bos@nxp.com>
Thread-Topic: [lamps] [EXTERNAL] Re: Multiple drafts with PQ algorithm key encodings that are not compatible.
Thread-Index: AQHY1DUYgRISwnr8bU+Tl+2ZL2Q8Aq33gdPB
Date: Fri, 30 Sep 2022 06:27:24 +0000
Message-ID: <DU0PR03MB8696CE791DDD4D5F0BF3C91486569@DU0PR03MB8696.eurprd03.prod.outlook.com>
References: <DM6PR11MB25852643FB14014E92A5CFE1EA549@DM6PR11MB2585.namprd11.prod.outlook.com> <CAPwdP4M74afMngjdus_y6SHkuK4cJ_i3GgsQwzF2+sC10kRKdg@mail.gmail.com> <DM6PR11MB25859271A2128A635E90A9C7EA579@DM6PR11MB2585.namprd11.prod.outlook.com>
In-Reply-To: <DM6PR11MB25859271A2128A635E90A9C7EA579@DM6PR11MB2585.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=keyfactor.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DU0PR03MB8696:EE_|VI1PR03MB6479:EE_
x-ms-office365-filtering-correlation-id: b738d920-e03e-4850-425e-08daa2acd680
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: TUy8HUs01Qe1mBGOK71vDGQAH2rH9l34AxN8fl3Jqe1O0VW2OTaHiRmxeUmkHfMjnDAlmTPtM2Aperi1va3aBbyltY6Azzeol5ToUIhiiIAXpFxYB6v3qHJH06XfDi7m7AFUlQ4RL1GIOZnP+zdL1EMUW/9V+h3EHapLWbkmwA5xz976PGeuY8rym0Rf8WDu4ODQ+UMHhL7iVWGqv55IPi2z9Sdi6Ef8avqWSxQb6ce8pMs21hY+z96XehsZVm4Y986gQvk+FxTZEYgwp3reFxOfxU67SPyAbySf2hN74vHwxC456zokioGgjcZi/YWjUq9+uveh51Ld+3dLGIrz3/g3Aj+Pzgzl5EyzZ57sUg/HAnpv26ahIJeroZCW6AxQZLJgP9To9QWaB0bUgFqIZ8G+4Ud9+cFIHvBxP2s3iqLY+2EthbGJEink0iSIILVI0E6+wYecynktdALh02Dnji/HM7En8bG2Op/zpk63fjjh2I9FPDpVyvbVsBzOYIqgQMYKR3pmphlJXgE5vb7Xbg9Bycv2PuPFm5haHlYLb6Zsoom8A5LOfLJP4SPNjakRHTcjDc/sVGzfB2oEcXieuoEZOgJ+yEua9bxdteoROpp6bFVd56LVpNvZSwLGRy0tiU9+FUlCWdOzSJ6+0sUtM7qStE4TE7k0rV7jqwWSOww+9+gofZ+XCtPW/zpjJrE8oSxK83zS5//6NFe/ErKuqoeftm+gqOJ67s3ELRl8sulHWnIH5Jtbw7+qea3gH2Kh79wXGyvh2TFiRFpCvhDoDoNlu+ET5Cbx8A9q6CtmyJ4=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DU0PR03MB8696.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230022)(4636009)(346002)(39840400004)(136003)(366004)(396003)(376002)(451199015)(33656002)(71200400001)(38070700005)(19627235002)(478600001)(166002)(966005)(2906002)(54906003)(110136005)(316002)(52536014)(86362001)(5660300002)(38100700002)(8936002)(26005)(7416002)(55016003)(122000001)(83380400001)(41300700001)(186003)(19627405001)(53546011)(64756008)(9686003)(6506007)(7696005)(66446008)(91956017)(66476007)(76116006)(66946007)(66556008)(8676002)(4326008); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: wmJ324FEnCdOd121kF6verXCNJEAzmhCLz756kwqveyTF5EVYPo9A/FiJ0LBZb0zgiSQYz+ttcXbbCqaev8NigbjSbbLrcLleyaR+pNMokDHOZwLE22uvtjJcreOGQyp4Nue/HkD2S4X9eh8cW/uXN5KTwouctyg4VAaj4w11pWrvHcuz2eY0Dp3IBGtmAQnDMIKoJ3T6q4l2iVEM5SRs9Ih9xwNHSarPkJ2HeIudbFV00jhyKu53MZplMYj4+9qQ0cIIKN38WxCcGt6sBE09pfLakJNLIqOqELHN2WmScYOG/NpJZpcVHKqFXy5WXUyuu3/k9QVcZpqawLG0SbENxpAk2WkWDpAWcet2A7KigY1u9kto6IJimCmFlrhYG5HiBRDiqfaiCersZiEiGP364xdcPTVfeWkcUjfDFHXRlDeoEpiVIDKO9BsS15AFVD4WHEXkRNLkZAw3dKi0NiJ0wMcKQ7bKFUu7EZuSSxK8CGHdAK5TRi+BpsRdwF3PLRwHBxIAIBuYA0BtMKp05yVihe7Y3FzuToCOGt+TzYkNJT6eXJyEHfo62NY7jDjtyoyPsqaL+LuFwLehV3RaSSgOAhYJreTBN9sTgwj4PKR1wMv6KNZqtjvpNXaBMbgS0fzjkKe0ECHaaaXu6HGuWeFCSAjOalnPfAVtV5jsKhthed6VGB9E2SeLfyu8j6TYNHZKqzeoYfUBYFatYHv77uwzi5AQBG3G3+M36G/gPeVU+R/bVE9IZutghQH0iDsPJXhd2RgQl/giU7DwHnRWHY3uGiIyo6xIJ1wEYGje9gY27GFNp4lDHAOG3D9ViDZvilJ4V6HmfSYad6FHawwqEBbpWex/e1wxrC9ig9Ekdr0VbBpuh0dBBJXcgVAtOag2EngT3BxCf7BU3D0bzwNkkrldhBfHmQrF8grzJzo97gpnJOU0yZOa0mTRDkm0D09t7d++dv7j0lQKjNIocOXv4eZe3Qmy1eB4hsFBRSO3fXVY2fpR7c9ilmAXTyONcsknNE0ne5vwrVkUvBruF9Mx2SYgpJCfVWii/T4da6z4ZFRkyzcYEeJROd9q3rokSnhRHtJlGt7Ke1mu03p3CRB46eE6M+L0OzoB2uH0hxGPipLN1TWeuf3Z89WZH/rJClKQwj6eSu2SKupvGw/n4nsa5raVn0IyZS9R4F5u8TC92jz1+4Pb8ESNpLXzuUHUltF9DhrISdts8FFjxS9z/78buzJTLA1yHjHpGTJ22oxIF2rJSS+BHJ/bhdG0I8nmi3SA4o8hpZb3c8iCZjCUeXIpnDLKpAH3v3VyaPZICMZYkBTGVU4QzE0ZTbmhMp+qR33YXzOrbCbnMbZykE8WRjPnpDRHBvXwpuW5y40RwAknEX8vg3O0AN0i8l8whLX9GjBdH/fBVUPpngli4KDRebvPPuDV5bGXXTaQGCV7PvUpKmkNvn/1Fq9CtQFWVQD56+cmQZkTUPu7tqg1c/O432vHq0dLvvptrO5aiSOvz0mdA8yGpaB94qge5InrdUoUogJcNRuHWthtHw4tVdpeRB2tGiXL7g3sSE/uWlBiUJnwpjWtC88236LegIFlpSpkiH8Y8dK
Content-Type: multipart/alternative; boundary="_000_DU0PR03MB8696CE791DDD4D5F0BF3C91486569DU0PR03MB8696eurp_"
MIME-Version: 1.0
X-OriginatorOrg: keyfactor.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DU0PR03MB8696.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b738d920-e03e-4850-425e-08daa2acd680
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Sep 2022 06:27:24.2526 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: c9ed4b45-9f70-418a-aa58-f04c80848ca9
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 4M2m8fSWm6r2AaL0dpCxyl830dbhIN3Re/6uXquMSzgsX9hudyJ5fAD2tUmQpE4mrLDDbHdvI4R5cJ7WYFRcYmwyXj5EYrkVro6PujWUWUs=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB6479
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/81iLyTZz4SmSz76kLcwv9WTPHcs>
X-Mailman-Approved-At: Fri, 30 Sep 2022 06:31:19 -0700
Subject: Re: [lamps] [EXTERNAL] Re: Multiple drafts with PQ algorithm key encodings that are not compatible.
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Sep 2022 06:27:36 -0000
We do in one place use the private key to get the public key, recently also implemented in software for Falcon, getPublic() from the private key. This is not an architectural thing though, just a convenience function to not have to transfer/store both the private and public key. We can easily use a separate object for the public key for some algorithms. If you transfer/store the private key, not having to send the public key as well saves a lot of bytes. Cheers, Tomas ________________________________ From: Spasm <spasm-bounces@ietf.org> on behalf of John Gray <John.Gray=40entrust.com@dmarc.ietf.org> Sent: Thursday, September 29, 2022 8:30 PM To: Markku-Juhani O. Saarinen <mjos@pqshield.com> Cc: pqc@ietf.org <pqc@ietf.org>; spasm@ietf.org <spasm@ietf.org>; cfrg@ietf.org <cfrg@ietf.org>; Massimo, Jake <jakemas@amazon.com>; Panos Kampanakis (pkampana) <pkampana@cisco.com>; Sean Turner <sean@sn3rd.com>; bas@westerbaan.name <bas@westerbaan.name>; cvvrede@gmail.com <cvvrede@gmail.com>; sid@zurich.ibm.com <sid@zurich.ibm.com>; bhe@zurich.ibm.com <bhe@zurich.ibm.com>; tvi@zurich.ibm.com <tvi@zurich.ibm.com>; osb@zurich.ibm.com <osb@zurich.ibm.com>; dieter.bong@utimaco.com <dieter.bong@utimaco.com>; joppe.bos@nxp.com <joppe.bos@nxp.com> Subject: Re: [lamps] [EXTERNAL] Re: Multiple drafts with PQ algorithm key encodings that are not compatible. CAUTION: External Sender - Be cautious when clicking links or opening attachments. Please email InfoSec@keyfactor.com with any questions. Thanks for this information Markku, I agree with what you are saying. Our first implementation of the public keys for Dilithium was simply an OCTET_STRING as that seems like the most straightforward approach. However, when we tried to be compatible with other specifications (like openSSL, OQS), we found a BIT STRING encoding, (which did happen to save 4 bytes)... So we made a change to accommodate that nuance. However, since then and looking at other specs and trying to collaborate with others, we also found the exploded versions of the keys as you mention, so that is what mitigated my questions. Thanks for referring us back to the actual Dilithium specification again! I hope that is the starting point of all the encoding representations. In regards to the private key encoding, I am in favor of keeping it as compact as possible. Our implementations don’t rely on being able to obtain the public key from a private key, but I guess if there are implementations that depends on this for historical reasons, it will be more difficult for them to drop in the newer signature algorithms as it might upset their implementation architectures. If that is a case that does need mitigation, then I am not opposed to inclusion of a small seed value that can be used to regenerate the public key (which looks possible in most PQ sig algorithms except Falcon). Perhaps that is a good candidate for a tagged optional value for private key encodings? In https://www.rfc-editor.org/rfc/rfc5208<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc5208&data=05%7C01%7Ctomas.gustavsson%40keyfactor.com%7C0d805ec7bb6b48f7093208daa24bf9e1%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C638000745511632841%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=pnmynQF46iXLwNs6wG894zWLsuMlWzxxzgaLla8LNW8%3D&reserved=0> PrivateKeyInfo doesn’t accommodate a public key, but the later spec https://www.rfc-editor.org/rfc/rfc5958<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc5958&data=05%7C01%7Ctomas.gustavsson%40keyfactor.com%7C0d805ec7bb6b48f7093208daa24bf9e1%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C638000745511632841%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=x%2B3a1MPd0g50fl1BA1v8NBpbV7uWuqDwMgUi0g6cbYE%3D&reserved=0> changed PrivateKeyInfo to be a OneAsymmetricKey which added and optional tagged publickey, so it is *mostly* backwards compatible if the public key is not there (and your 5208 ASN.1 parser isn’t rigid in allowing unknown implicit tags…). However, since private asymmetric keys aren’t transmitted over the wire as much as public keys, maybe two options (full encoding or compressed/seed format) could be useful for different use-cases… There are the obvious use-cases of server generated asymmetric keys in key management protocols (CMP, CMS, PKCS#12) which require asymmetric private key encryption and transmission. However, I recall issues in the past with EC key formats, so hopefully some lessons have been learned since then. Thanks for this great discussion, John Gray Entrust From: Markku-Juhani O. Saarinen <mjos@pqshield.com> Sent: Thursday, September 29, 2022 1:26 PM To: John Gray <John.Gray@entrust.com> Cc: pqc@ietf.org; spasm@ietf.org; cfrg@ietf.org; Massimo, Jake <jakemas@amazon.com>; Panos Kampanakis (pkampana) <pkampana@cisco.com>; Sean Turner <sean@sn3rd.com>; bas@westerbaan.name; cvvrede@gmail.com; sid@zurich.ibm.com; bhe@zurich.ibm.com; tvi@zurich.ibm.com; osb@zurich.ibm.com; dieter.bong@utimaco.com; joppe.bos@nxp.com Subject: [EXTERNAL] Re: [lamps] Multiple drafts with PQ algorithm key encodings that are not compatible. WARNING: This email originated outside of Entrust. DO NOT CLICK links or attachments unless you trust the sender and know the content is safe. ________________________________ On Thu, Sep 29, 2022 at 2:51 PM John Gray <John.Gray=40entrust.com@dmarc.ietf.org<mailto:40entrust.com@dmarc.ietf.org>> wrote: We are doing some interoperability testing with different vendors using the new Dilithium, Falcon and SPHINCS+ algorithms. We have come across at least two drafts which are trying to specify the ASN.1 encoding formats for these algorithms. However, the encoding formats are not compatible with each other. I imagine the authors of these drafts should get together and come up with a common format (I have copied them on this email). This means we must choose one or the other, or even worse, support multiple formats (which can lead to bugs). Initially I started more than a year ago using my own encoding format for internal prototyping, but now need to interoperate with others outside of our organization, so a common format is definitely needed at this point. ?? Indeed it is remarkable that various people have been trying to create "exploded" ASN.1 encodings for Dilithium keys, none of which are compatible with each other, or the actual Dilithium specification, reference implementation, and the test vectors. Section 5.4 of the specification defines it as a concatenated byte sequence, or as a 32-byte seed value. For ASN.1 these can be naturally expressed as a simple OCTET STRING. https://pq-crystals.org/dilithium/data/dilithium-specification-round3-20210208.pdf<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fpq-crystals.org%2Fdilithium%2Fdata%2Fdilithium-specification-round3-20210208.pdf__%3B!!FJ-Y8qCqXTj2!fTiMY5BETVkwFJRmHwVhbOWjnlC8kRSBDfYIDsY0npeD5m5x8ND5iec1AXNsT1Xuh1EEprR69FoTb5I%24&data=05%7C01%7Ctomas.gustavsson%40keyfactor.com%7C0d805ec7bb6b48f7093208daa24bf9e1%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C638000745511632841%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=b%2FXvB%2Fx6vFgyWtrGU8Qr%2BOudUJZq6vTI7katADso%2FKc%3D&reserved=0> "Secret key. The secret key contains ρ, K , tr, s1 , s2 and t0 and is also stored as the concatenation of the bit-packed representation of these quantities in the given order. Consequently, a secret key requires 32 + 32 + 32 + 32((k + `) · dlog(2η + 1)e + 13k) bytes. As mentioned previously, the signer also has the option of simply storing the 32-byte value ζ and then simply re-deriving all the other elements of the secret key." The public key is similarly defined. There is no practical advantage of exploding it into individual components -- repacking would always be needed for both signing and signature verification. Best Regards, - markku Dr. Markku-Juhani O. Saarinen Staff Cryptography Architect PQShield Ltd M: +44 0 7548 620723 E: mjos@pqshield.com<mailto:mjos@pqshield.com> W: www.pqshield.com<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2Fwww.pqshield.com%2F__%3B!!FJ-Y8qCqXTj2!fTiMY5BETVkwFJRmHwVhbOWjnlC8kRSBDfYIDsY0npeD5m5x8ND5iec1AXNsT1Xuh1EEprR6XzGKIH0%24&data=05%7C01%7Ctomas.gustavsson%40keyfactor.com%7C0d805ec7bb6b48f7093208daa24bf9e1%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C638000745511632841%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=NPClAux6i5QayZsmXUQ9zVbgZPAl%2FwuuViGLpC%2BdZ%2Bg%3D&reserved=0> We fully realize the OID values will be changing once official OIDs are registered, (changing those are trivial), but the ASN.1 formats of the public and private keys is kind of important as well… ?? For example: The LAMPS group has a specification of Dilithium public keys in this draft: https://datatracker.ietf.org/doc/draft-massimo-lamps-pq-sig-certificates/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-massimo-lamps-pq-sig-certificates%2F__%3B!!FJ-Y8qCqXTj2!fTiMY5BETVkwFJRmHwVhbOWjnlC8kRSBDfYIDsY0npeD5m5x8ND5iec1AXNsT1Xuh1EEprR6F7rP21s%24&data=05%7C01%7Ctomas.gustavsson%40keyfactor.com%7C0d805ec7bb6b48f7093208daa24bf9e1%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C638000745511632841%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2FGASTGNuNmuPrxth%2BQjrYnOY7MikaSA0afjX66eD9U4%3D&reserved=0> the public key format is this: The Dilithium public key MUST be encoded using the ASN.1 type DilithiumPublicKey: DilithiumPublicKey ::= OCTET STRING The private key format is this: DilithiumPrivateKey ::= SEQUENCE { rho BIT STRING, - nonce/seed K BIT STRING, - key/seed tr BIT STRING, - PRF bytes (CRH in spec.) s1 BIT STRING, - vector l s2 BIT STRING, - vector k t0 BIT STRING, - encoded vector PublicKey IMPLICIT DilithiumPublicKey OPTIONAL } In this draft: https://datatracker.ietf.org/doc/draft-uni-qsckeys/01/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-uni-qsckeys%2F01%2F__%3B!!FJ-Y8qCqXTj2!fTiMY5BETVkwFJRmHwVhbOWjnlC8kRSBDfYIDsY0npeD5m5x8ND5iec1AXNsT1Xuh1EEprR6wY7A4oI%24&data=05%7C01%7Ctomas.gustavsson%40keyfactor.com%7C0d805ec7bb6b48f7093208daa24bf9e1%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C638000745511632841%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=TQ6kKjzZ8ivD0rvLvyA2wln%2BKShw6FZEFw5cn9mpIyc%3D&reserved=0> Dilithium keys have this encoding: DilithiumPublicKey ::= SEQUENCE { rho OCTET STRING, t1 OCTET STRING } DilithiumPrivateKey ::= SEQUENCE { version INTEGER {v0(0)} -- version (round 3) nonce BIT STRING, -- rho key BIT STRING, -- key/seed/D tr BIT STRING, -- PRF bytes (CRH in spec) s1 BIT STRING, -- vector(L) s2 BIT STRING, -- vector(K) t0 BIT STRING, publicKey [0] IMPLICIT DilithiumPublicKey OPTIONAL -- see next section } The draft-uni-qsckeys does not cover SPHINCS+, it does cover Falcon, but I don’t know of another draft that specifies Falcon. There are also encodings for Kyber mentioned in two documents that I see. There is an early https://datatracker.ietf.org/doc/draft-ietf-lamps-kyber-certificates/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-lamps-kyber-certificates%2F__%3B!!FJ-Y8qCqXTj2!fTiMY5BETVkwFJRmHwVhbOWjnlC8kRSBDfYIDsY0npeD5m5x8ND5iec1AXNsT1Xuh1EEprR6H6KKj9U%24&data=05%7C01%7Ctomas.gustavsson%40keyfactor.com%7C0d805ec7bb6b48f7093208daa24bf9e1%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C638000745511789084%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=2GcwxX29sq7RLxUGon8nC0qKVa3Y26FC0pqMJpQGiHc%3D&reserved=0> draft which mentions it is up to the document defining Kyber to give more details. In the draft-uni-qsckeys draft it is more specific. https://datatracker.ietf.org/doc/draft-uni-qsckeys/01/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-uni-qsckeys%2F01%2F__%3B!!FJ-Y8qCqXTj2!fTiMY5BETVkwFJRmHwVhbOWjnlC8kRSBDfYIDsY0npeD5m5x8ND5iec1AXNsT1Xuh1EEprR6wY7A4oI%24&data=05%7C01%7Ctomas.gustavsson%40keyfactor.com%7C0d805ec7bb6b48f7093208daa24bf9e1%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C638000745511789084%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ve3aIgFgfz3t%2Fjgi0q9CqqSdZWPi1UlzaYKAHVFg3vM%3D&reserved=0> KyberPrivateKey ::= SEQUENCE { version INTEGER {v0(0)} -- version (round 3) s OCTET STRING, -- sample s publicKey [0] IMPLICIT KyberPublicKey OPTIONAL, -- see next section hpk OCTET STRING -- H(pk) nonce OCTET STRING, -- z } Partial public key encoding: KyberPrivateKey ::= SEQUENCE { version INTEGER {v0(0)} -- version (round 3) s OCTET STRING, -- EMPTY publicKey [0] IMPLICIT KyberPublicKey OPTIONAL, -- see next section hpk OCTET STRING -- EMPTY nonce OCTET STRING, -- d } Full public key encoding: KyberPublicKey ::= SEQUENCE { t OCTET STRING, rho OCTET STRING } Is https://datatracker.ietf.org/doc/draft-uni-qsckeys/01/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-uni-qsckeys%2F01%2F__%3B!!FJ-Y8qCqXTj2!fTiMY5BETVkwFJRmHwVhbOWjnlC8kRSBDfYIDsY0npeD5m5x8ND5iec1AXNsT1Xuh1EEprR6wY7A4oI%24&data=05%7C01%7Ctomas.gustavsson%40keyfactor.com%7C0d805ec7bb6b48f7093208daa24bf9e1%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C638000745511789084%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ve3aIgFgfz3t%2Fjgi0q9CqqSdZWPi1UlzaYKAHVFg3vM%3D&reserved=0> meant to become the document that defines the key formats for all the PQ keys that will be standardized? If not, then it should probably just refer to whatever documents will define the formats so that we can at least agree on one common format for the PQ keys. Cheers, John Gray Entrust Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system. _______________________________________________ Spasm mailing list Spasm@ietf.org<mailto:Spasm@ietf.org> https://www.ietf.org/mailman/listinfo/spasm<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm__%3B!!FJ-Y8qCqXTj2!fTiMY5BETVkwFJRmHwVhbOWjnlC8kRSBDfYIDsY0npeD5m5x8ND5iec1AXNsT1Xuh1EEprR62BBq4CA%24&data=05%7C01%7Ctomas.gustavsson%40keyfactor.com%7C0d805ec7bb6b48f7093208daa24bf9e1%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C638000745511789084%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Tsj6wwC6pQeBMjKgiFCJJbjB2Zb%2BrIEvqoCAu%2BNxwWE%3D&reserved=0>
- [lamps] Multiple drafts with PQ algorithm key enc… John Gray
- Re: [lamps] [EXTERNAL] [Pqc] Multiple drafts with… Mike Ounsworth
- Re: [lamps] [Pqc] Multiple drafts with PQ algorit… Massimo, Jake
- Re: [lamps] [Pqc] Multiple drafts with PQ algorit… Bas Westerbaan
- Re: [lamps] [EXTERNAL] Re: [Pqc] Multiple drafts … Mike Ounsworth
- Re: [lamps] [EXTERNAL] Re: [Pqc] Multiple drafts … Christine Cloostermans
- Re: [lamps] [EXTERNAL] Re: [Pqc] Multiple drafts … Mike Ounsworth
- Re: [lamps] Multiple drafts with PQ algorithm key… Russ Housley
- Re: [lamps] Multiple drafts with PQ algorithm key… Tim Hollebeek
- Re: [lamps] Multiple drafts with PQ algorithm key… Blumenthal, Uri - 0553 - MITLL
- Re: [lamps] Multiple drafts with PQ algorithm key… Russ Housley
- Re: [lamps] Multiple drafts with PQ algorithm key… Tim Hollebeek
- Re: [lamps] Multiple drafts with PQ algorithm key… Blumenthal, Uri - 0553 - MITLL
- Re: [lamps] [EXTERNAL] Re: [Pqc] Multiple drafts … Christine Cloostermans
- Re: [lamps] Multiple drafts with PQ algorithm key… Markku-Juhani O. Saarinen
- Re: [lamps] [EXTERNAL] Re: Multiple drafts with P… John Gray
- Re: [lamps] Multiple drafts with PQ algorithm key… Kampanakis, Panos
- Re: [lamps] Multiple drafts with PQ algorithm key… Mike Ounsworth
- Re: [lamps] Multiple drafts with PQ algorithm key… Kris Kwiatkowski
- Re: [lamps] [EXTERNAL] Re: Multiple drafts with P… Mike Ounsworth
- Re: [lamps] [EXTERNAL] Re: Multiple drafts with P… Tomas Gustavsson
- Re: [lamps] [Pqc] Multiple drafts with PQ algorit… Dieter Bratko