Re: [lamps] [Pqc] Multiple drafts with PQ algorithm key encodings that are not compatible.
"Massimo, Jake" <jakemas@amazon.com> Wed, 28 September 2022 21:06 UTC
Return-Path: <prvs=263ee56f7=jakemas@amazon.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 36049C157B4D; Wed, 28 Sep 2022 14:06:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.775
X-Spam-Level:
X-Spam-Status: No, score=-10.775 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.571, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.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 3xtLe6AncGT9; Wed, 28 Sep 2022 14:06:06 -0700 (PDT)
Received: from smtp-fw-2101.amazon.com (smtp-fw-2101.amazon.com [72.21.196.25]) (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 570CCC15A730; Wed, 28 Sep 2022 14:06:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1664399166; x=1695935166; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=jP8eWu01KzsIuPJOzsfH1Tf+hos+7e+Mb/MbCaxCa1g=; b=FUk/UcNBKiCQZ2UagEwFw5GvCOMlCXGAc7ytGiFh0PF2Kbgtrelb8LzQ /RWCo6Fy7QUQJXLN3nYvbLV+prYZ2qVOR1iYmLzjqDQcCGZqGN/dB2ZyT ImK7gwD7o1XYtsbeaUjTj5MSAYA87ufSAuxoITyKXCQ5a+TSqdWAK59/R k=;
X-IronPort-AV: E=Sophos;i="5.93,353,1654560000"; d="scan'208,217";a="246349480"
Thread-Topic: [Pqc] Multiple drafts with PQ algorithm key encodings that are not compatible.
Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-iad-1a-4ba5c7da.us-east-1.amazon.com) ([10.43.8.6]) by smtp-border-fw-2101.iad2.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Sep 2022 21:05:52 +0000
Received: from EX13D28EUB004.ant.amazon.com (iad12-ws-svc-p26-lb9-vlan2.iad.amazon.com [10.40.163.34]) by email-inbound-relay-iad-1a-4ba5c7da.us-east-1.amazon.com (Postfix) with ESMTPS id 96D9681461; Wed, 28 Sep 2022 21:05:47 +0000 (UTC)
Received: from EX19D046EUB001.ant.amazon.com (10.252.61.72) by EX13D28EUB004.ant.amazon.com (10.43.166.176) with Microsoft SMTP Server (TLS) id 15.0.1497.38; Wed, 28 Sep 2022 21:05:46 +0000
Received: from EX19D046EUB001.ant.amazon.com (10.252.61.72) by EX19D046EUB001.ant.amazon.com (10.252.61.72) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.12; Wed, 28 Sep 2022 21:05:46 +0000
Received: from EX19D046EUB001.ant.amazon.com ([fe80::8dcc:eced:3e14:fc7f]) by EX19D046EUB001.ant.amazon.com ([fe80::8dcc:eced:3e14:fc7f%4]) with mapi id 15.02.1118.012; Wed, 28 Sep 2022 21:05:46 +0000
From: "Massimo, Jake" <jakemas@amazon.com>
To: Mike Ounsworth <Mike.Ounsworth@entrust.com>, John Gray <John.Gray=40entrust.com@dmarc.ietf.org>, "pqc@ietf.org" <pqc@ietf.org>, "spasm@ietf.org" <spasm@ietf.org>, "cfrg@ietf.org" <cfrg@ietf.org>
CC: "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>, "Markku-Juhani O. Saarinen" <mjos@pqshield.com>
Thread-Index: AQHY03iYCesHyEWWzU2BDMFcPyHjSq3039yA
Date: Wed, 28 Sep 2022 21:05:46 +0000
Message-ID: <574516F5-098F-4CB6-8D9C-F193BF1B1507@amazon.com>
References: <DM6PR11MB25852643FB14014E92A5CFE1EA549@DM6PR11MB2585.namprd11.prod.outlook.com> <CH0PR11MB5739E17E6696FA41BD909E1D9F549@CH0PR11MB5739.namprd11.prod.outlook.com>
In-Reply-To: <CH0PR11MB5739E17E6696FA41BD909E1D9F549@CH0PR11MB5739.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.43.164.249]
Content-Type: multipart/alternative; boundary="_000_574516F5098F4CB68D9CF193BF1B1507amazoncom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/jHYUcCDLhdZY2WRf09eCOGqZYpc>
X-Mailman-Approved-At: Thu, 29 Sep 2022 06:51:29 -0700
Subject: Re: [lamps] [Pqc] 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: Wed, 28 Sep 2022 21:06:10 -0000
Hi John, Thanks for reaching out, this email is quite timely as Panos and I had been discussing your feedback (among all others from the WG on the Dilithium I-D) just today. Here are my thoughts. Regarding the Public Key: There is a reason as to why I went with: DilithiumPublicKey ::= OCTET STRING In https://datatracker.ietf.org/doc/draft-massimo-lamps-pq-sig-certificates/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-massimo-lamps-pq-sig-certificates/__;!!FJ-Y8qCqXTj2!eSTwME-1IjQkfjJFS0X7lRzbYJ1PhEzSelmmUcLwF9JaceAAKFQwvLRif4O6vS8ijYlK0TG2cYO4rpBHtq5AG1OZQAKxlou-rKXm$>, and not: DilithiumPublicKey ::= SEQUENCE { rho OCTET STRING, t1 OCTET STRING } As found in https://datatracker.ietf.org/doc/draft-uni-qsckeys/01/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-uni-qsckeys/01/__;!!FJ-Y8qCqXTj2!eSTwME-1IjQkfjJFS0X7lRzbYJ1PhEzSelmmUcLwF9JaceAAKFQwvLRif4O6vS8ijYlK0TG2cYO4rpBHtq5AG1OZQAKxlnAfHtmn$>. This is due to the discussions from Peikert and Markku on the NIST PQC forum here https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/eAaiJO1qzkA/m/K66R_ftNBwAJ. The unambiguous public key serialization provides additional security properties (message binding and non-resignability). I attempted to outline this in the last paragraph of my security recommendations. Regarding the Private Key: We’re not too far off here, I was actually in the process of changing the private key structure today from the feedback from the WG. In particular, I agree with the addition of the version parameter – the other differences are just naming conventions. However, upon digesting a comment from Markku: The secret key lengths in Appendix B match with v3.1 (v3.0 has 16 bytes longer private keys), but do not account for ASN.1 encoding of the SEQUENCE in Section 5 of the same I-D. Even section 5 itself does not seem to account for this as it reports "the size necessary to hold all private key elements." There is a de facto key transport encoding for secret keys, defined by the algorithm designers and used in KAT tests, that doesn't have ASN.1 encoding of individual components. It can be simply taken as an OCTET STRING, just like the public key in this I-D. The lengths in Appendix B match that encoding, not the completely new encoding in Section 5. Seconded by Simon Guggi, I also support the byte array encoding for the private key proposed by the algorithm designers. It is an already defined encoding, so I think it makes sense to take that one. And this comment from Ilari Liusvaara: Don't split the private key into fields. Standard Dilithium implementation takes the private key as octet string (as this is cryptographic BCP), so any splitting causes application to need to perform redundant merging/splitting in order to adapt what is in private key with what Dilithium implementation takes. And things get even worse as tr is SHAKE output which gets sticked into a BIT STRING... Which is a cursed combination. I was considering changing the DilithiumPrivateKey ASN.1 to match other private key formats (https://datatracker.ietf.org/doc/draft-ietf-lamps-kyber-certificates/ and https://www.rfc-editor.org/rfc/rfc5915) This means proposing the new sequence structure: DilithiumPrivateKey ::= SEQUENCE { version Version, privateKeyAlgorithm PrivateKeyAlgorithmIdentifier, privateKey OCTET STRING, publicKey [0] IMPLICIT DilithiumPublicKey OPTIONAL } i.e., the parameters are defined/contained within privateKeyAlgorithm. This means we can support the byte array encoding for the private key proposed by the algorithm designers in privateKey an OCTET STRING. Thoughts? Cheers, Jake From: Mike Ounsworth <Mike.Ounsworth@entrust.com> Date: Wednesday, 28 September 2022 at 13:26 To: John Gray <John.Gray=40entrust.com@dmarc.ietf.org>, "pqc@ietf.org" <pqc@ietf.org>, "spasm@ietf.org" <spasm@ietf.org>, "cfrg@ietf.org" <cfrg@ietf.org> Cc: "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: [EXTERNAL][Pqc] Multiple drafts with PQ algorithm key encodings that are not compatible. CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. My curiosity is about the procedural aspect of draft-uni-qsckeys. Is this attached to a working group? Are you indenting to publishing this as an RFC, or is this just to bridge prototyping work until NIST publishes real standards? --- Mike Ounsworth Software Security Architect, Entrust From: Pqc <pqc-bounces@ietf.org> On Behalf Of John Gray Sent: September 28, 2022 1:34 PM To: pqc@ietf.org; spasm@ietf.org; cfrg@ietf.org Cc: 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] [Pqc] 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. ________________________________ 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. 😊 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://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-massimo-lamps-pq-sig-certificates/__;!!FJ-Y8qCqXTj2!eSTwME-1IjQkfjJFS0X7lRzbYJ1PhEzSelmmUcLwF9JaceAAKFQwvLRif4O6vS8ijYlK0TG2cYO4rpBHtq5AG1OZQAKxlou-rKXm$> 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://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-uni-qsckeys/01/__;!!FJ-Y8qCqXTj2!eSTwME-1IjQkfjJFS0X7lRzbYJ1PhEzSelmmUcLwF9JaceAAKFQwvLRif4O6vS8ijYlK0TG2cYO4rpBHtq5AG1OZQAKxlnAfHtmn$> 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://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-lamps-kyber-certificates/__;!!FJ-Y8qCqXTj2!eSTwME-1IjQkfjJFS0X7lRzbYJ1PhEzSelmmUcLwF9JaceAAKFQwvLRif4O6vS8ijYlK0TG2cYO4rpBHtq5AG1OZQAKxlubO7POn$> 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://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-uni-qsckeys/01/__;!!FJ-Y8qCqXTj2!eSTwME-1IjQkfjJFS0X7lRzbYJ1PhEzSelmmUcLwF9JaceAAKFQwvLRif4O6vS8ijYlK0TG2cYO4rpBHtq5AG1OZQAKxlnAfHtmn$> 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://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-uni-qsckeys/01/__;!!FJ-Y8qCqXTj2!eSTwME-1IjQkfjJFS0X7lRzbYJ1PhEzSelmmUcLwF9JaceAAKFQwvLRif4O6vS8ijYlK0TG2cYO4rpBHtq5AG1OZQAKxlnAfHtmn$> 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.
- [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