Re: [lamps] Multiple drafts with PQ algorithm key encodings that are not compatible.
Mike Ounsworth <Mike.Ounsworth@entrust.com> Thu, 29 September 2022 19:45 UTC
Return-Path: <Mike.Ounsworth@entrust.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDFF2C14F737; Thu, 29 Sep 2022 12:45:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.807
X-Spam-Level:
X-Spam-Status: No, score=-2.807 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=entrust.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LlBTy738iDrk; Thu, 29 Sep 2022 12:45:23 -0700 (PDT)
Received: from mx08-0015a003.pphosted.com (mx08-0015a003.pphosted.com [185.183.30.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7356DC14F6E5; Thu, 29 Sep 2022 12:45:23 -0700 (PDT)
Received: from pps.filterd (m0242863.ppops.net [127.0.0.1]) by mx08-0015a003.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 28THcoOP028886; Thu, 29 Sep 2022 14:45:19 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=entrust.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=mail1; bh=ZG4rCkCp+1Xc4Dd5f6h3O8sm8TjLs2cmTU8q2eR8aUs=; b=VrXsC69iZz+/EApZxGHXSgeSvjkJct+VVehUPNQ1JcGXqU+3Ye/EDXYRAKYhDjP4BGhx otpmz1/cz11ezXvzfe5gRU+6eHvlw+hKc68ZwxotR8W6/i5oKyjkFvKFFLLSf01i2NxZ R+HuCCqtMpqIkd0XVOYvpQqq4o6/MFWX5k76gNKacSVMtkNxLeMvTBbJS15YWIMJmCl3 dcVUoKat1Y5YfVXbHVsh0np+hdvuEUUh/r7ObdTYD0nBvAV0G4boj9iQTlJ7sN6o6wuZ Iz0cl1QsTGxonyTSgWfMPLbyuZzTRwupOGK/3I6swdqMwOqwvGsFc9C8t1r1ZaGYBnF3 Jg==
Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2101.outbound.protection.outlook.com [104.47.58.101]) by mx08-0015a003.pphosted.com (PPS) with ESMTPS id 3jsvvrpwky-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 29 Sep 2022 14:45:19 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=USC/2mx0JmYZ3aLe1th8ukTVUiO13iGLoDB3t8EMqWxwM6MizeORBK19ngNNkvoP/eGbh8GVnXgZSVNe8PmLrj6HO22fK9g9kHvTsHJb8Fl+Au0Dk7l0T50EQKSPAU0r8QVnLsBbMzz0Y1ztCR7LLdMusHFqgeq4rccN3WOyS8yLGa9+Ie+/vQRQbzBTsDbgFPERM2oIWPhZtFETUcQEzz6aBgj07ZYnLedVtYGmon4kF/hFB4ixizoUBrTZr2nV5pz+vQ6advnLRUgFjh489WL7xPsmzgRq9Na/84g8eYv6Wj51ktbxWejew7M/prZv/c6rWBD3qK9vPA6GS3jN0A==
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=ZG4rCkCp+1Xc4Dd5f6h3O8sm8TjLs2cmTU8q2eR8aUs=; b=VrP5dQDgIe22RfqwkWX14x04DkaQq0ZFmmD+IG26ucEAteZNvgP2SZh2tMRq/jCAVPO+ShIMWoZtJkIirB/IfeaaLc4ylzBft/RKQGGIXIkUNfstiSueG75ODkL8A0eSS6Uh0YL6h/91N4nJQ4zJBhre4m2V1tQRMSI83edGSswqgBE94MLx0Oy71Eb/KsIkrWjP2oBXZJeg55gqqbGOOkKE0PasfDZnj77sReAksVQNRt5eLNrxTzm31khekhMZJ9lwCOvp5o/PV3tdWnjaTNl17FYPtlUXpNsVA2FCdWF+PWhKAmxdIrXNA5uAdpeZk33CUHhN/ih1zr8GSs4OQw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=entrust.com; dmarc=pass action=none header.from=entrust.com; dkim=pass header.d=entrust.com; arc=none
Received: from CH0PR11MB5739.namprd11.prod.outlook.com (2603:10b6:610:100::20) by DM4PR11MB6384.namprd11.prod.outlook.com (2603:10b6:8:8a::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5654.25; Thu, 29 Sep 2022 19:45:15 +0000
Received: from CH0PR11MB5739.namprd11.prod.outlook.com ([fe80::9d8e:5cd6:89b8:244c]) by CH0PR11MB5739.namprd11.prod.outlook.com ([fe80::9d8e:5cd6:89b8:244c%2]) with mapi id 15.20.5654.025; Thu, 29 Sep 2022 19:45:15 +0000
From: Mike Ounsworth <Mike.Ounsworth@entrust.com>
To: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>, Tim Hollebeek <tim.hollebeek=40digicert.com@dmarc.ietf.org>, Russ Housley <housley@vigilsec.com>
CC: LAMPS <spasm@ietf.org>
Thread-Topic: [lamps] Multiple drafts with PQ algorithm key encodings that are not compatible.
Thread-Index: AQHY1BqcW/llzjfuLEOFulCvlhkhLK32oYqAgAAol8A=
Date: Thu, 29 Sep 2022 19:45:15 +0000
Message-ID: <CH0PR11MB5739A6E1478C323EA9B24F909F579@CH0PR11MB5739.namprd11.prod.outlook.com>
References: <DM6PR11MB25852643FB14014E92A5CFE1EA549@DM6PR11MB2585.namprd11.prod.outlook.com> <79AD46D5-A9C5-45F2-8E88-0359A3E2FCF3@vigilsec.com> <SJ0PR14MB5489FB0CF47FC5530C5CA48883579@SJ0PR14MB5489.namprd14.prod.outlook.com> <ABE9A15C-6D36-43BC-8869-C81E9AC72B32@vigilsec.com> <SJ0PR14MB54890C5A453F7558C8A3A55883579@SJ0PR14MB5489.namprd14.prod.outlook.com> <321B8233-2F65-4E18-A0E5-F7C373412ABF@ll.mit.edu>
In-Reply-To: <321B8233-2F65-4E18-A0E5-F7C373412ABF@ll.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: CH0PR11MB5739:EE_|DM4PR11MB6384:EE_
x-ms-office365-filtering-correlation-id: b58b73f6-2290-479d-40e8-08daa25321aa
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: uhwMYsOzwTlwj64RRv2L9tQIiMC0VWt21syNuIL/8pHxliFhGOqftYmfyVU3rT8uHkP5CPJZAJBa8aODhi00EJbfu9mZpcLP4QS0+N1TtA2Ok4WEggyxdqSJIZ9PqYGeXy7W2Yzuca+yHlS9aTRml0QwjKXBDIuDnbZ/vczwGz8pBON7LtUbzJ8qWsMX1xEulnCRfSx+M+KvplVSzdhnL1kkbCHYau8lQGtQobGUyw49hzXzwCITEmx/wt5K9uQUBQwOPIRO4gB6pzSxFNl4WoIGmYyPiiHe1miE1JEGN7/YxKhhw3QATs13DYqixcqXpkLa279ntXatS6HrzDZcjL9P8qRI4ct+TcAY2eszVwj78G1KcT9H0WqAL5m468v+wU5IFH7Hz9lupho2pm6+oKpLrnMVKDvHWZ/yNxwsib+Ywc0gsiMF2fOtCZ9KLfWuu08xuXkvGsYtm06fgiUYEgtlT8POGr1eIkT0Nx0bUQ3jQB1HALdPGwDtNJhN5PsKH3JDn4PbndQkOAm6J2LKT0sIjLFQ1e2mUx1gte6gsTXVMWVr/Gnh8aEpPuHEDVl+hM0pdjJAkyq8GWXIYOuAOwCZC2pdiMzAkzzZNaghcx5YJIDOUYeCJaAF2Hco9yap6OAgeQE8huvjNqMtNaFwwLSmiUSL95/tom5PedkFz4VsmTneqKq3ILaabzbjwEvtuC+Oz7gPuuMyVExzJkWpyJUgSJwYDfZ/kuGzAcVst4undM9goiB56EoO4WyR5vZ57DHE/UDp4gPSfEAU+1OLzYw41khz9YFHSYoIRd6g7BjZj5aDuV7PuOQo4COp9r0X8gAmZtVXaCsgzPqADiDHXQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH0PR11MB5739.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230022)(346002)(366004)(136003)(39860400002)(396003)(376002)(451199015)(6506007)(71200400001)(478600001)(53546011)(966005)(9686003)(41300700001)(186003)(5660300002)(26005)(7696005)(55016003)(64756008)(8936002)(2906002)(52536014)(83380400001)(110136005)(66946007)(76116006)(66476007)(66556008)(8676002)(316002)(66446008)(38100700002)(4326008)(86362001)(33656002)(38070700005)(122000001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: HDpzBr5jLLmUULiNUeriepF6Vm99w29QdKN3I1Zkrk+2Q0dPIxwmBYLix+XUsSiKt9eRcIX2F2aPH+W4w/v0I6DCTZX2+IWC7/XwMk6C9yvrPPqTETWO7bP35+ShGBVxr3sDyf1UNR4kq74ZO+4Bi04p86Mv3Y8EmYWHv4EhdPerS2n+UONL8G2uLybYIluXEpZ9ulXvL7w5TNX5GKJ3IoEmAbtV/knbw6rMz41/L4UE2AmFJqO9e+jI/yumv8Ni3wdgsFivM8BdZHoLYY4NfCLBCCRAjeaTna/LEJHcvhNp5Nvru6aewuHPsLAGptAEpkiN/erkFV8XzSihrIklHGC6rKffJLcG0keAPp5hTZP2mNsp3gmydw/RsJve0eJKaVDUlKjbfcDfkFvLriSxzHK6MFYJGBpRRRhfLsWkgMqJN79HFIwMN5fUMo+bf7jU2mwT36CT2gUrxslc1/TUUYf3+44FM2Obj0+LiOuvT7bODXh17+bRvjAvAn/KTEbh626PNNz9aBcT3QaAqbKTRUmTQfu8Eu8y7E6iimJGVP7JmyBhOFCnfwhJyu3vdI8byRx9+uXTsBoRWUt2ZmQORXLLUEMNVM5kVnXGSmuqwjGVhhFEXpAHoOLr7qEnHGHdMLcycSUO/l8eNpxmYhoUWp4DObiAILQspmi7fFA6bjMJqWv5WT+Lut8Q3rnqI4ek3t3ZY9tXLyJAHYIrcqFQCSMB3pdIYWb1FYqNt0JBUOlKUIa6+C995gH3WdE65h1BL627lYoi4yngHTvwoaxSXdOd8rKR9bWbftiUYRp69L73WUERS9O3zBuM47VIpAfSDNi2nRb+DXyWDNZgtaMLJ3RQmjto7IMT6ldkrsh1CZCiOG4PHGs+HSeWjsI+J16c8+ubJ3jppuiUHyybcRBf+ZlVnzj+ChZiCZidYNoUmoXGCcY1sNcTQREmfbFfBrWviC+objfntEmdc11RjzbCW2+PN9OtbvZLEy4EI2wxAvotPpwmKxVN+fJpSJWLICTkjU0sFZoWiv921MuWkSXsxAwZZDqXCU0WPwRuqzU2MNUfpRvofGs5j+Yq4XNKu5h0zaQ559rE4CRpLYrbGpdqywL2Skrox/xJRCNzdt03zK24xI7wrQyLUA1RSgEiI1At/0rNXH3eVKZ0TFZY7h1q6GMBKlG8BYJXqa+V0FSXAyq3k1E4dQjn0tfgWN8HlgqPHRPe8wkh8ATFj+XGTkomEieqtNzqz34fO1uWw2iWxOneVKPaDfBYViQLHJhACgDgfh8MXD6GFr25HI6xABQbu/KOK1up2K/0CzkMYO3/ZV9LyrXADWhpRu66OMNGA4BrkapklNgKBEvTeDX5JwjdIJG4WSyqxoQzhT/QLnHKPza/DAYc1seuDNOJPLFmcyTof0+Pt9znnuxrCGHPZOIHvXi8ipAsbhBIidK884JfJeFmB04W8rfhLCAtGyLv+xD8ZFO88obWfAUE4NMgloNaynnICgRnZwWUEQ5yne+Hf06Qszb9sbMVLymC1V4NmoYOnQ8USEbDYcPHhUaxUUwMejiNoBbh3BVRilNpFX07+QKMvs2tRpyJjth7Y63NJbjb
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: entrust.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CH0PR11MB5739.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b58b73f6-2290-479d-40e8-08daa25321aa
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Sep 2022 19:45:15.6981 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f46cf439-27ef-4acf-a800-15072bb7ddc1
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: bgACCHd5uZt2zrb/QREdQUpqrSXz6ihV6fY7whgf5qcw4tViGsqjUxPnkO2D4jhx2WwqPYtgwq0anbLwODvl4aEIbJGP2MozN4zw2doIgYU=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR11MB6384
X-Proofpoint-GUID: PjjTB8Dm0vYFpucHu-yKVxf2XwTIx2UP
X-Proofpoint-ORIG-GUID: PjjTB8Dm0vYFpucHu-yKVxf2XwTIx2UP
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.528,FMLib:17.11.122.1 definitions=2022-09-29_11,2022-09-29_03,2022-06-22_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 spamscore=0 priorityscore=1501 phishscore=0 adultscore=0 lowpriorityscore=0 impostorscore=0 clxscore=1011 mlxscore=0 malwarescore=0 suspectscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2209130000 definitions=main-2209290124
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/XFjjF36sk6_u1HQN2I9eoT1Efpc>
Subject: Re: [lamps] 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: Thu, 29 Sep 2022 19:45:28 -0000
So, taking the CRYSTALS keygens as examples: Dilithium: 01: \zeta <- {0,1}^256 Then to my eyes, the rest of the keygen is just hashing and some not horrible arithmetic. Kyber: 01: d <- {byte}^32 Then to my eyes, the rest of the keygen is just hashing and some not horrible arithmetic. What are the performance numbers for Round 3 keygens? My go-to was https://www.safecrypto.eu/pqclounge/, but it does not appear to have round 3, and I admit that I am having troubles navigating https://bench.cr.yp.to/primitives-sign.html to find keygen numbers. I can certainly see why it would be attractive to only store / transmit the 32 byte seed. Are there any use cases that *can* tolerate the bandwidth, but *can not* tolerate re-running the keygen on demand? Also, I assume similar arguments apply to SPHINCS+, XMSS, LMS, but not to Falcon since the Falcon seems to have heavier field computations, and to need more than a single random value (but I’m just reading the spec). --- Mike Ounsworth Software Security Architect, Entrust From: Spasm <spasm-bounces@ietf.org> On Behalf Of Blumenthal, Uri - 0553 - MITLL Sent: September 29, 2022 12:00 PM To: Tim Hollebeek <tim.hollebeek=40digicert.com@dmarc.ietf.org>; Russ Housley <housley@vigilsec.com> Cc: LAMPS <spasm@ietf.org> 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. ________________________________________ Yes, it’s a tradeoff. Given the cost of the constraints, and the fact that computing power tends to consistently grow (without necessarily consuming much more power), but the bandwidth of the radio communications does not (e.g., there’s no way to squeeze significantly more bits through an HF “connection”), I strongly support favoring smaller structures to go across the wire, rather than larger structures that take less CPU cycles to process. -- V/R, Uri From: Spasm <mailto:spasm-bounces@ietf.org> on behalf of Tim Hollebeek <mailto:tim.hollebeek=40digicert.com@dmarc.ietf.org> Date: Thursday, September 29, 2022 at 11:47 To: Russ Housley <mailto:housley@vigilsec.com> Cc: LAMPS <mailto:spasm@ietf.org> Subject: Re: [lamps] Multiple drafts with PQ algorithm key encodings that are not compatible. Yes, I get that part, I just wanted to make sure I correctly understood what aspect of uni-qsckeys you were referring to. It is a little unfortunate that both encodings are important for different use cases, and we can’t just pick one. Perhaps different algorithm OIDs would be cleaner than fooling around with CHOICE and OPTIONAL all over the place. But that’s probably going to get tricky too… -Tim From: Russ Housley <mailto:housley@vigilsec.com> Sent: Thursday, September 29, 2022 11:14 AM To: Tim Hollebeek <mailto:tim.hollebeek@digicert.com> Cc: LAMPS <mailto:spasm@ietf.org> Subject: Re: [lamps] Multiple drafts with PQ algorithm key encodings that are not compatible. Tim: There is a tradeoff between size and computation. By including values that can be calcualted, the key gets bigger, but it is easier to consume. However, more battery is needed to transmit and receive the bigger structure. Russ On Sep 29, 2022, at 10:28 AM, Tim Hollebeek <mailto:tim.hollebeek=40digicert.com@dmarc.ietf.org> wrote: Are you referring to the option for partial vs full encoding for some of the private keys, or something else? -Tim From: Spasm <mailto:spasm-bounces@ietf.org> On Behalf Of Russ Housley Sent: Thursday, September 29, 2022 10:12 AM To: LAMPS <mailto:spasm@ietf.org> Subject: Re: [lamps] Multiple drafts with PQ algorithm key encodings that are not compatible. Trimming the recipient list because the other messages needed moderation for "too many recipients" draft-uni-qsckeys-01 makes the argument that for the private keys, one size does not fit every use case. If there is consensus on this view, thenOPTIONAL fields or a CHOICE within the private key structure seems like a simple way forward. I was really hoping that the public key would _always_ be an OCTET STRING. No optional parts. Russ On Sep 28, 2022, at 2:33 PM, John Gray <mailto:John.Gray=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. 😊 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/ 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/ 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/ 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/ 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/ 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 mailto:Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm _______________________________________________ Spasm mailing list mailto:Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm
- [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