[lamps] Re: [EXT] Re: External email: RE: Re: External email: RE: [EXTERNAL] Responding to ISSUE #5
Phillip Hallam-Baker <phill@hallambaker.com> Fri, 23 August 2024 00:41 UTC
Return-Path: <hallam@gmail.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 E1AF4C169432 for <spasm@ietfa.amsl.com>; Thu, 22 Aug 2024 17:41:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.65
X-Spam-Level:
X-Spam-Status: No, score=-6.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
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 domaE_HjIzbS for <spasm@ietfa.amsl.com>; Thu, 22 Aug 2024 17:40:56 -0700 (PDT)
Received: from mail-oa1-f45.google.com (mail-oa1-f45.google.com [209.85.160.45]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8BF1C169430 for <spasm@ietf.org>; Thu, 22 Aug 2024 17:40:56 -0700 (PDT)
Received: by mail-oa1-f45.google.com with SMTP id 586e51a60fabf-26fde6117cfso1027012fac.1 for <spasm@ietf.org>; Thu, 22 Aug 2024 17:40:56 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724373656; x=1724978456; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=01k9fHF2D2XhvnEk7d+BIuxuvyIJ/qydhL6/L8dSL+Q=; b=en2oZcyRgY8Qs06kDfR8JHxcxiiYssMzCOlT9yKv8uw9gRE7qrVlkMdDvot4qa9Y2a w1SHW5yuUGRq3+GDNfX3aqVZZ/MPnsnPy/uZR1ycenQMZxOP85rplE/QIE5MP08p+qxi Ct2sjyTsaD3pjRf8S3eEfLAAYAn+9GSV1gS+YQoS0TvmjUGm95rRdrA3a1p3bJuO2HLM 0g0Hleb9Qyg5V9RmufDqxL7e0XdK/O1nsgTTrZ6LJofv7rWNN6Og2MA89O02HTgltvYj jlSkwjO55Z32Hb+5L0QNUsrJOnJpmmoW1Lqn0Ze50JYzx4ohpaWIM3JmoQyJ4QGMOWTY 8Rgg==
X-Forwarded-Encrypted: i=1; AJvYcCUe7Tg22zqBPImvnwPNnNokD54dIAG1q/0v/80rrNvjZgKjHLlY25hdNAuJ8lCkW6Vi5t4Zzw==@ietf.org
X-Gm-Message-State: AOJu0Yz5Jf13+Qu3+AtmxGvQvwmQBBlxWZX2OordY/m5kU8gdSzPjL5H axqf7VqQs8fbpSsp2zdqg8xACuBdtb5clZCpn7cKYjRNJGQsMzyb1c8S2eGptBSV4HwHvhlKFo5 s+kPwQckodMwWZ+638RbFtzU04A0MyA==
X-Google-Smtp-Source: AGHT+IH6z679xJlvsYVAtDoaoh5uzuWHuFNVwb+0DFfnGHD9nyf9oORCV/xIRbalvAVZfSANokLQbDoFIPD6EYALY6Q=
X-Received: by 2002:a05:6870:e314:b0:25c:b3c9:ecda with SMTP id 586e51a60fabf-273e6696e1emr531070fac.38.1724373655469; Thu, 22 Aug 2024 17:40:55 -0700 (PDT)
MIME-Version: 1.0
References: <01a801dae4ba$c5dfcf00$519f6d00$@enigma.com.pl> <CH0PR11MB57394FCDB757B76712CCB2599F872@CH0PR11MB5739.namprd11.prod.outlook.com> <013301daf236$58df83d0$0a9e8b70$@enigma.com.pl> <CH0PR11MB5739F6443BDF9B9CB34F33969F8E2@CH0PR11MB5739.namprd11.prod.outlook.com> <MW4PR09MB1005946AD51E94501A8E6BE11F38E2@MW4PR09MB10059.namprd09.prod.outlook.com> <00d701daf475$f6c83d80$e458b880$@enigma.com.pl> <CH0PR11MB5739C618CF021D5EDCCC0D669F8F2@CH0PR11MB5739.namprd11.prod.outlook.com> <BN0P110MB1419C843293E586E05AD448D908FA@BN0P110MB1419.NAMP110.PROD.OUTLOOK.COM>
In-Reply-To: <BN0P110MB1419C843293E586E05AD448D908FA@BN0P110MB1419.NAMP110.PROD.OUTLOOK.COM>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Thu, 22 Aug 2024 20:40:43 -0400
Message-ID: <CAMm+LwgUePyfCYrmo4TBe2cNGz=83ww3xJzO4j9CBunygB9png@mail.gmail.com>
To: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
Content-Type: multipart/alternative; boundary="00000000000031c76506204f071f"
Message-ID-Hash: CNMZBIQJGJ6UBEHVA6VKBRSK5WHXOJNI
X-Message-ID-Hash: CNMZBIQJGJ6UBEHVA6VKBRSK5WHXOJNI
X-MailFrom: hallam@gmail.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: Mike Ounsworth <Mike.Ounsworth=40entrust.com@dmarc.ietf.org>, Piotr Popis <piotr.popis@enigma.com.pl>, "Dang, Quynh H. (Fed)" <quynh.dang=40nist.gov@dmarc.ietf.org>, John Gray <John.Gray@entrust.com>, "spasm@ietf.org" <spasm@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [lamps] Re: [EXT] Re: External email: RE: Re: External email: RE: [EXTERNAL] Responding to ISSUE #5
List-Id: This is the mail list for the LAMPS Working Group <spasm.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/yM1XuZyQPlRO2A6fyH-hZBv7nnE>
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>
My reason for using hybrid is that I cannot get the control I need using Kyber alone. Alice creates a document to share with the W Group. So when Bob joins, he gets access, then Carol joins, she gets access, Bob leaves, his access is terminated. The way this is done right now is using Ford-Weiner symmetric key release and that means that the administrator of the key server has the ability to decrypt every document. Using threshold, we can set up the key server so that it can control decryption of documents by performing its half of a key agreement (or not) but cannot decrypt documents because it only has a share in the decryption key. I would prefer to use a fully threshold scheme but since I don't have one, a mechanism which means that the adversary has to compromise the key server AND have a CRQC to break ECDH to decrypt a document gives me plenty of security for most current needs. On Thu, Aug 22, 2024 at 5:01 PM Blumenthal, Uri - 0553 - MITLL < uri@ll.mit.edu> wrote: > We all intuitively understand that a hybrid is as strong as its strongest > component, and that the whole reason for doing this is that we can’t > predict which algorithms will remain strong over the next 10 years. I think > that concept is fairly straightforward and easy to understand. > > > > Correct. But with Hybrids, the main bet is on whether CRQC will become a > reality. > > > > Does reducing that to a single number, or pair of numbers, or quadruple of > numbers per row of the table, and the lengthy security consideration about > how to interpret those numbers, make that concept easier to understand and > communicate? I don’t think so. Does it help an implementor who is trying to > write software against this spec? I also don’t think so. > > > > Hmm, respectfully partially-disagree. If your hybrid has a Classic part > assumed to be 112 bits strong, and a PQ part assumed to be 126 bits strong > (for example) – you can say that the minimal strength of this hybrid is > 112, and maximum 126, under assumption that at least one of the two > mechanisms withstands Classic attack, and CRQC is unavailable. What’s not > to understand? > > > > But indeed, reducing this to *one* number would be misleading. A range > would make more sense to me (beside the fact that hybrids in general don’t > 😉). > > > > My vote is to leave this out of the LAMPS composite documents. If some > other working group thinks that it improves their document to include it, > then great, but I don’t think that’s the case here. > > > > I’d probably put ranges in. > > > > TNX > > *From:* Piotr Popis <piotr.popis@enigma.com.pl> > *Sent:* Thursday, August 22, 2024 4:31 AM > *To:* 'Dang, Quynh H. (Fed)' <quynh.dang=40nist.gov@dmarc.ietf.org>; Mike > Ounsworth <Mike.Ounsworth@entrust.com>; John Gray <John.Gray@entrust.com>; > spasm@ietf.org > *Subject:* RE: External email: RE: [lamps] Re: External email: RE: > [EXTERNAL] Responding to ISSUE #5 > > > > Hi All I have a similar opinion about the security of combinations of > algorithms to Quynh. It is rather indisputable that if we assume that both > algorithms are secure, then the combination is secure as the stronger of > the pair. Of course, in > > Hi All > > I have a similar opinion about the security of combinations of algorithms > to Quynh. > > > > It is rather indisputable that if we assume that both algorithms are > secure, then the combination is secure as the stronger of the pair. > > > > Of course, in the above context of security, "algorithm" is a certain > cryptographic suite, which, for example, in the case of RSA-based > signatures must take into account not only the key length. The security > strength associated with the RSA digital signature process is no greater > than the minimum of the security strength associated with the bit length of > the modulus and the security strength of the hash function that is employed. > > > > We create a hybrid combination because we consider it a significant risk > that individual algorithms may not be secure: > > - "classical", because there is a risk of creating a quantum computer with > appropriate computing power, and > > - "post-quantum", because the previous cryptanalysis may have been > insufficient (the case of “SIKE”). > > "Hybridity" therefore somehow assumes that we cannot presume that both > algorithms are secure. > > > > So how do we define the security of the combination? The matter is not > trivial (as aptly summarized Quynh) and requires discussion. > > > > In response to Mike's email I would like to point out that FIPS > 203/204/205 contain the following definitions: > > security category - a number associated with the security strength of a > post-quantum cryptographic algorithm. > > security strength - a number associated with the amount of work (i.e., the > number of operations) that is required to break a cryptographic algorithm > or system. > > > > In terms of "security category" FIPS 203/204/205 refer to NIST SP 800-57 > Part 1: > > a) 203 and 204: rev. 5 (or as amended); > > b) 205: Section 5.6 of forthcoming rev. 6. > > > > When preparing my proposal for "Overall Security strength" I took mainly > into account the appendix A of the draft FIPS 203. To my surprise this > appendix was removed from the final version, but I assume that its content > (maybe slightly changed) will be in NIST SP 800-57 part 1 rev. 6. > Unfortunately, this draft is not publicly available yet. > > > > I am not sure whether NIST will define "equivalence" between Security > Category and Security strength, which would allow for a single value. We > may have to use two numbers for hybrid compositions - as I wrote in the > previous email - I suggest consulting NIST on this matter (and probably > wait for version 6 of 800-57 Part 1). > > --- > > Piotr Popis > > > > *From:* Dang, Quynh H. (Fed) <quynh.dang=40nist.gov@dmarc.ietf.org> > *Sent:* Wednesday, August 21, 2024 6:57 PM > *To:* Mike Ounsworth <Mike.Ounsworth@entrust.com>; Piotr Popis < > piotr.popis@enigma.com.pl>; John Gray <John.Gray@entrust.com>; > spasm@ietf.org > *Subject:* External email: RE: [lamps] Re: External email: RE: [EXTERNAL] > Responding to ISSUE #5 > > > > Hi all, > > > > A fundamental question we need to decide on before we could name security > strength of a hybrid construction of a PQ algorithm and a classic one. > > > > Is this based on the classical security level (or an estimated classical > bits of security) of the PQ one ? (1) > > > > Is this based on the post-quantum security level (or an estimated > post-quantum bits of security) of the PQ one ? (2) > > > > Is this based on the classical security level (or an estimated classical > bits of security) of the classical one ? (3) > > > > Is this based on the classical security level (or an estimated classical > bits of security) of the weaker classical security one ? (4) > > > > Is this based on the classical security level (or an estimated classical > bits of security) of the stronger classical security algorithm ? (5) > > > > Under the classical world, one needs to assume which one is broken and > which one is secure. With that, the secure one is the security of the > combo. So, one combo can have 2 different security levels if both > algorithms have different classical security levels. > > > > Under the classical world, if both are secure then the stronger classical > security one is the security of the combo. > > > > Under the pq world, only the pq one is the security of the combo. > > > > Regards, > > Quynh. > > > > > > *From:* Mike Ounsworth <Mike.Ounsworth=40entrust.com@dmarc.ietf.org> > *Sent:* Wednesday, August 21, 2024 9:34 AM > *To:* Piotr Popis <piotr.popis=40enigma.com.pl@dmarc.ietf.org>; John Gray > <John.Gray@entrust.com>; spasm@ietf.org > *Subject:* [lamps] Re: External email: RE: [EXTERNAL] Responding to ISSUE > #5 > > > > Hi Piotr, > > > > What does the term “Overall Security Strength” mean? > > > > Can you please point me to a peer-reviewed academic paper that formally > defines this concept? The problem is that we have a classical algorithm, > which defines its security in bits, ex.: “RSA 2048 has 112 bits of security > against current best-known attacks”, and a PQ algorithm which defines its > security in terms of a specific security property of a symmetric primitive, > ex.: “Comparable to a collision search on SHA-256 / SHA3-256” which you > might think is “128 bit”, but in fact the definition is more subtle than > that. > > > > So we have a numeric quantity, and a non-numeric property, one of which > applies when the adversary has a CQRC, and one of which applies knows of a > weakness in ML-KEM. I don’t know how to combine that into a single number. > If you know of a peer-reviewed paper that discusses this in detail, I would > love to read it an learn. > > > > --- > > *Mike* Ounsworth > > > > *From:* Piotr Popis <piotr.popis=40enigma.com.pl@dmarc.ietf.org> > *Sent:* Monday, August 19, 2024 7:50 AM > *To:* Mike Ounsworth <Mike.Ounsworth@entrust.com>; John Gray < > John.Gray@entrust.com>; spasm@ietf.org > *Subject:* RE: External email: RE: [EXTERNAL] [lamps] Responding to ISSUE > #5 > > > > Hi All My detailed proposal is as follows: Version 1 > +===================+============+=========+===============+========+=========+ > | Composite KEM |OID |First |Second |KDF |Overall | | | > |Algorithm|Algorithm | |Security | | | | | | |strength > > > > Hi All > > My detailed proposal is as follows: > > Version 1 > > > +===================+============+=========+===============+========+=========+ > > | Composite KEM |OID |First |Second |KDF > |Overall | > > | | |Algorithm|Algorithm | > |Security | > > | | | | | > |strength | > > > +===================+============+=========+===============+========+=========+ > > | id-MLKEM512-ECDH |<CompKEM>.1 |MLKEM512 |ECDH-P256 |SHA3-256| > 128 bits| > > | -P256 | | | | > | | > > > +-------------------+------------+---------+---------------+--------+---------+ > > | id-MLKEM512- |<CompKEM>.2 |MLKEM512 |ECDH- |SHA3-256| > 128 bits| > > | ECDH- | | |brainpoolp256r1| > | | > > | brainpoolP256r1 | | | | > | | > > > +-------------------+------------+---------+---------------+--------+---------+ > > | id- |<CompKEM>.3 |MLKEM512 |X25519 |SHA3-256| > 128 bis | > > | MLKEM512-X25519 | | | | > | | > > > +-------------------+------------+---------+---------------+--------+---------+ > > | id- |<CompKEM>.13|MLKEM512 |RSA-OAEP 2048 |SHA3-256| > 112 bits| > > | MLKEM512-RSA2048 | | | | > | | > > > +-------------------+------------+---------+---------------+--------+---------+ > > | id- |<CompKEM>.4 |MLKEM512 |RSA-OAEP 3072 |SHA3-256| > 128 bits| > > | MLKEM512-RSA3072 | | | | > | | > > > +-------------------+------------+---------+---------------+--------+---------+ > > *| id- |<CompKEM>.41|MLKEM512 |RSA-OAEP 4096 |SHA3-256| > 128 bits|* > > * | MLKEM512-RSA4096 | | | | |* > | > > * +-------------------+------------+---------+---------------+--------+* > ---------+ > > *| id-MLKEM768-ECDH |<CompKEM>.5 |MLKEM768 |ECDH-P384 |SHA3-384| > 192 bits|* > > * | -P384 | | | | |* > | > > * +-------------------+------------+---------+---------------+--------+* > ---------+ > > *| id-MLKEM768- |<CompKEM>.6 |MLKEM768 |ECDH- |SHA3-384| > 192 bits|* > > * | ECDH- | | |brainpoolp384r1| |* > | > > * | brainpoolP384r1 | | | | |* > | > > * +-------------------+------------+---------+---------------+--------+* > ---------+ > > *| id- |<CompKEM>.7 |MLKEM768 |X448 |SHA3-384| > 192 bits|* > > * | MLKEM768-X448 | | | | |* > | > > * +-------------------+------------+---------+---------------+--------+* > ---------+ > > *| id-MLKEM1024-ECDH |<CompKEM>.8 |MLKEM1024|ECDH-P521 |SHA3-512| > 256 bits|* > > * | -P521 | | | | |* > | > > * +-------------------+------------+---------+---------------+--------+* > ---------+ > > | id-MLKEM1024- |<CompKEM>.9 |MLKEM1024|ECDH- |SHA3-512| > 256 bits| > > | ECDH- | | |brainpoolP512r1| > | | > > | brainpoolP512r1 | | | | > | | > > > +-------------------+------------+---------+---------------+--------+---------+ > > > > or > > Version 2 > > > > > +===================+============+=========+===============+========+===========+ > > | Composite KEM |OID |First |Second |KDF | > Overall | > > | | |Algorithm|Algorithm | | > Security | > > | | | | | | > Category | > > > +===================+============+=========+===============+========+===========+ > > | id-MLKEM512-ECDH |<CompKEM>.1 |MLKEM512 |ECDH-P256 > |SHA3-256| 1 | > > | -P256 | | | | > | | > > > +-------------------+------------+---------+---------------+--------+-----------+ > > | id-MLKEM512- |<CompKEM>.2 |MLKEM512 |ECDH- > |SHA3-256| 1 | > > | ECDH- | | |brainpoolp256r1| > | | > > | brainpoolP256r1 | | | | > | | > > > +-------------------+------------+---------+---------------+--------+-----------+ > > | id- |<CompKEM>.3 |MLKEM512 |X25519 > |SHA3-256| 1 | > > | MLKEM512-X25519 | | | | > | | > > > +-------------------+------------+---------+---------------+--------+-----------+ > > | id- |<CompKEM>.13|MLKEM512 |RSA-OAEP 2048 > |SHA3-256|less than 1| > > | MLKEM512-RSA2048 | | | | > | | > > > +-------------------+------------+---------+---------------+--------+-----------+ > > | id- |<CompKEM>.4 |MLKEM512 |RSA-OAEP 3072 > |SHA3-256| 1 | > > | MLKEM512-RSA3072 | | | | > | | > > > +-------------------+------------+---------+---------------+--------+-----------+ > > *| id- |<CompKEM>.41|MLKEM512 |RSA-OAEP 4096 > |SHA3-256| 1 |* > > * | MLKEM512-RSA4096 | | | | |* > | > > * +-------------------+------------+---------+---------------+--------+* > -----------+ > > *| id-MLKEM768-ECDH |<CompKEM>.5 |MLKEM768 |ECDH-P384 > |SHA3-384| 3 |* > > * | -P384 | | | | |* > | > > * +-------------------+------------+---------+---------------+--------+* > -----------+ > > *| id-MLKEM768- |<CompKEM>.6 |MLKEM768 |ECDH- > |SHA3-384| 3 |* > > * | ECDH- | | |brainpoolp384r1| |* > | > > * | brainpoolP384r1 | | | | |* > | > > * +-------------------+------------+---------+---------------+--------+* > -----------+ > > *| id- |<CompKEM>.7 |MLKEM768 |X448 > |SHA3-384| 3 |* > > * | MLKEM768-X448 | | | | |* > | > > * +-------------------+------------+---------+---------------+--------+* > -----------+ > > *| id-MLKEM1024-ECDH |<CompKEM>.8 |MLKEM1024|ECDH-P521 > |SHA3-512| 5 |* > > * | -P521 | | | | |* > | > > * +-------------------+------------+---------+---------------+--------+* > -----------+ > > | id-MLKEM1024- |<CompKEM>.9 |MLKEM1024|ECDH- > |SHA3-512| 5 | > > | ECDH- | | |brainpoolP512r1| > | | > > | brainpoolP512r1 | | | | > | | > > > +-------------------+------------+---------+---------------+--------+-----------+ > > > > Comments: > > 1. Only one version could be introduced into the standard; preferably in > the "Security Considerations" Section. > > 2. FIPS 203 final version dropped the appendix A that was in the draft. > However, as long as NIST SP 800-131A rev. 2 in table 4 (page 13) defines > the security of algorithms based on "security strength" in bits it seems > that table version 1 is appropriate. > > 3. On the other hand, FIPS 203 uses the term "Security Category" which is > not intended to be a simple equivalent of "security strength" - see text > under Table 3 in FIPS 203. Hence, perhaps version 2 would be more > appropriate. In my opinion it would be best to consult with NIST on this. > > 4. If a quantum computer with sufficient computing power (CRQC) were to > appear, then: > > a) the classical algorithm would become useless, but the Security > Category/Security strength column would remain at the same level (in such a > situation I withdraw from the formulation about the "weakest element|"); > > b) we would probably start defining OIDs with two PQ algorithms, i.e. the > hybrid approach would still be appropriate, but "hybridity" would be > defined differently. 😊 > > > > --- > > Piotr Popis > > > > > > *From:* Mike Ounsworth <Mike.Ounsworth=40entrust.com@dmarc.ietf.org> > *Sent:* Wednesday, August 14, 2024 4:36 PM > *To:* Piotr Popis <piotr.popis@enigma.com.pl>; 'John Gray' < > John.Gray@entrust.com>; spasm@ietf.org > *Subject:* External email: RE: [EXTERNAL] [lamps] Responding to ISSUE #5 > > > > Hi Piotr, > > > > > “In addition, it might be appropriate to add a column, for example, in > Table 6 (or even better, in a new table in Section 11.1) indicating the > "overall" Security strength, which would take into account the weakest > element.” > > > > While I agree that this will be useful to a reader, I think that coming up > with a single “overall security strength” for a composite will be > difficult. For example, are you considering before or after your adversary > has a CRQC? Perhaps the best we could do is to have two columns for > “Classical security” and “PQ Security” and list different numbers in each > column. Is this worth doing? > > > > Tracked in github: > > https://github.com/lamps-wg/draft-composite-sigs/issues/29 > <https://urldefense.com/v3/__https:/github.com/lamps-wg/draft-composite-sigs/issues/29__;!!FJ-Y8qCqXTj2!YaYM8QGNiQXGJn3-TbwQK0cqF8rpyuTHoa2mjxKoB7BGqSgfdYfaPtEeTKD51I3ZDN7kZ2EM_qRVutoXW8XJ1DL5pOcdZOv43v_1$> > > > > --- > > *Mike* Ounsworth > > > > *From:* Piotr Popis <piotr.popis=40enigma.com.pl@dmarc.ietf.org> > *Sent:* Friday, August 2, 2024 4:03 AM > *To:* 'John Gray' <John.Gray=40entrust.com@dmarc.ietf.org>; spasm@ietf.org > *Subject:* [EXTERNAL] [lamps] Responding to ISSUE #5 > > > > Hi All My suggestion is to drop the RSA key size from the OID at all. > However, if the group decided otherwise, that's not a problem for me. But > in such a case, I recommend that the relevant cryptographic compositions be > as close as possible > > > > Hi All > > My suggestion is to *drop the RSA key size from the OID at all. *However, > if the group decided otherwise, that's not a problem for me. > > > > But in such a case, I recommend that the relevant cryptographic > compositions be as close as possible to NIST Security strength/Security > Category. > > For example, as suggested by Mike, RSA 4096 we should pair it with the > same cipher suites as the RSA-3072 combo. > > > > In addition, it might be appropriate to add a column, for example, in > Table 6 (or even better, in a new table in Section 11.1) indicating the > "overall" Security strength, which would take into account the weakest > element. > > ---- > > Piotr Popis > > > > > > *From:* John Gray <John.Gray=40entrust.com@dmarc.ietf.org> > *Sent:* Thursday, August 1, 2024 11:41 PM > *To:* spasm@ietf.org > *Subject:* [lamps] Composite Signatures and KEM open issues that need > feedback > > > > Hello Lamps. > > Thanks for the feedback at IETF 120 for composite signatures and composite > KEMs. We the authors have compiled together all the currently open > questions about composites into one email (sorry it is so long). > > Feedback on-list is great. Discussion directly on the linked github issue > is better. > > If you’re going to comment on the mailing list. Please carefully tag which > issue you are discussing so that it stays somewhat orderly … “Responding to > ISSUE #3”. > > > > Open Questions on Composite Signatures: > > ISSUE #1 > > (Github issue: https://github.com/lamps-wg/draft-composite-sigs/issues/9 > <https://urldefense.com/v3/__https:/github.com/lamps-wg/draft-composite-sigs/issues/9__;!!FJ-Y8qCqXTj2!dMdIjqsPL1q3R2Id8EA2I0a_P18dTjGENAIIStUQ4WelWt7GEPdO57e9P4Btj9-PJv_2_aYSyGnK15TQWrjHqIe_su2kRiy8HmYPi07FMA$> > ) > > > > The ML-DSA public key should be an unwrapped BIT STRING with no ASN.1 type > around them. Currently the ML-DSA draft > draft-ietf-lamps-dilithium-certificates uses this: > > pk-MLDSA PUBLIC-KEY ::= { > > IDENTIFIER id-MLDSA > > -- KEY no ASN.1 wrapping -- > > PARAMS ARE absent > > CERT-KEY-USAGE { nonRepudiation, digitalSignature, > > keyCertSign, cRLSign } > > --- PRIVATE-KEY no ASN.1 wrapping -- > > } > > We could try using something like an ENCODED BY id-rawkey as in: > > id-raw-key ::= SOME OBJECT IDENTIFIER > > pk-CompositeSignature {OBJECT IDENTIFIER:id, > > FirstPublicKeyType,SecondPublicKeyType } > > PUBLIC-KEY ::= { > > IDENTIFIER id > > KEY SEQUENCE { > > firstPublicKey BIT STRING (CONTAINING FirstPublicKeyType | > ENCODED BY id-raw-key), > > secondPublicKey BIT STRING (CONTAINING SecondPublicKeyType | > ENCODED BY id-raw-key) > > } > > PARAMS ARE absent > > CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyCertSign, > cRLSign} > > } > > Or just have some text that explains the BIT STRING is a raw key without > the extra ASN.1 type wrapping. Does the working group have a preference on > this matter? The authors think adding some explanatory text should be > sufficient. > > > > ISSUE #2 > > (Github Issue: https://github.com/lamps-wg/draft-composite-sigs/issues/19 > <https://urldefense.com/v3/__https:/github.com/lamps-wg/draft-composite-sigs/issues/19__;!!FJ-Y8qCqXTj2!dMdIjqsPL1q3R2Id8EA2I0a_P18dTjGENAIIStUQ4WelWt7GEPdO57e9P4Btj9-PJv_2_aYSyGnK15TQWrjHqIe_su2kRiy8HmaZiH08cw$> > ) > > > > Do we make the Domain separator Hash (DER (OID)) instead of just > DER(OID)? The one advantage is we end up with a fixed length Domain > separator. The authors don’t think this is required, but are willing to > make the change if the working group would like to see this done. > > > > ISSUE #3 > > (Github issue: https://github.com/lamps-wg/draft-composite-sigs/issues/6 > <https://urldefense.com/v3/__https:/github.com/lamps-wg/draft-composite-sigs/issues/6__;!!FJ-Y8qCqXTj2!dMdIjqsPL1q3R2Id8EA2I0a_P18dTjGENAIIStUQ4WelWt7GEPdO57e9P4Btj9-PJv_2_aYSyGnK15TQWrjHqIe_su2kRiy8HmZgDz_4qQ$> > ) > > Should we consider compacting the CompositeSignaturePrivateKey format? > For example, today it is: > > CompositeSignaturePrivateKey ::= SEQUENCE SIZE (2) OF OneAsymmetricKey > > We could compact it to: > > CompositeSignaturePrivateKey ::= SEQUENCE SIZE (2) OF OCTET STRING > > Then implementations would need to recompose the OneAsymmetricKey using > the combination of settings give by the OID. This removes the redundant > information from the CompositeSignaturePrivateKey because it is now carried > in the OID representation itself. > > The authors don’t have strong opinion on whether this should be changed. > The two benefits: > > Smaller private keys (maybe a couple percent) > > Aligns with the compact format used in the public key. > > 3. It makes it a bit more difficult for implementors (but not too > much). > > --------- > > Open Issues affect both Composite Signatures and Composite KEM: > > ISSUE #4 > > Timing. Does LAMPS have an official or unofficial milestone for > publishing? Answer could be different for KEMs and Sigs. Obviously, > there’s going to be a flurry of PQC drafts from LAMPS and others once FIPS > 203, 204, 205 are out. Are we trying to get these into that wave, or not? > In particular, should we wait X years for CFRG to finish their KEM > Combiners activity, or should we publish this and fix it later if we need > to? (The authors and the general feel at LAMPS 120 was to > publish-now-fix-later). > > > > ISSUE #5 > > (Github issues: > > 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!dMdIjqsPL1q3R2Id8EA2I0a_P18dTjGENAIIStUQ4WelWt7GEPdO57e9P4Btj9-PJv_2_aYSyGnK15TQWrjHqIe_su2kRiy8HmYIjqiuAg$> > > https://github.com/lamps-wg/draft-composite-sigs/issues/24 > <https://urldefense.com/v3/__https:/github.com/lamps-wg/draft-composite-sigs/issues/24__;!!FJ-Y8qCqXTj2!dMdIjqsPL1q3R2Id8EA2I0a_P18dTjGENAIIStUQ4WelWt7GEPdO57e9P4Btj9-PJv_2_aYSyGnK15TQWrjHqIe_su2kRiy8HmZOtTBM-Q$> > > > https://github.com/lamps-wg/draft-composite-sigs/issues/23 > <https://urldefense.com/v3/__https:/github.com/lamps-wg/draft-composite-sigs/issues/23__;!!FJ-Y8qCqXTj2!dMdIjqsPL1q3R2Id8EA2I0a_P18dTjGENAIIStUQ4WelWt7GEPdO57e9P4Btj9-PJv_2_aYSyGnK15TQWrjHqIe_su2kRiy8HmZJ8ofuUw$> > > Should the RSA key size be specified by the OID, or left free? > Related sub question: if specified, which RSA key sizes should we support? > Currently we have {2048, 3072}, but we’ve been asked by an implementer to > add 4096. Should it then be {2048, 4096}? Jan is advocating for having all > three RSA sizes. > > > > Arguments for removing the key size restriction: it completely avoids that > related sub question. > > > Arguments against: we probably should provide guidance on how to pair RSA > key sizes with the ML-KEM and KDF parameter. Removing the RSA key size > does not shorten the current list; you need a minimum of 4 RSA combos to > hit: MLDSA44+PSS, MLDSA44+PKCS1, MLDSA65+PSS, MLDSA65+PKCS1, and the > equivalents on the KEM side. Reminder: having both L1/2, and L3 with RSA > is sort of about matching security levels (although we would be quite happy > to call all levels of RSA “NIST PQC L1”), but it’s more about people trying > to add PQ to an RSA deployment and they only want to implement one size of > ML-*. Maybe this is a weak argument? But then if we only go with one PQ > level, then which ML-DSA and which ML-KEM is “the one”? > > > > For signature the authors are intending to add two new combinations with > RSA 4096. We suggest: > > > > id-MLDSA65-RSA4096-PSS-SHA512 > > id-MLDSA65-RSA4096-PKCS15-SHA512 > > > > For KEM we are intended to add > > id-MLKEM512-RSA4096 > > ----------- > > Open Issues affecting Composite KEM > > ISSUE #6 > > (Github: https://github.com/lamps-wg/draft-composite-kem/issues/40 > <https://urldefense.com/v3/__https:/github.com/lamps-wg/draft-composite-kem/issues/40__;!!FJ-Y8qCqXTj2!dMdIjqsPL1q3R2Id8EA2I0a_P18dTjGENAIIStUQ4WelWt7GEPdO57e9P4Btj9-PJv_2_aYSyGnK15TQWrjHqIe_su2kRiy8HmZEJCYVSQ$> > ) > > > > Combiner construction. We’re on-path to align with OpenPGP and X-Wing. We > greatly appreciate the interaction with Quynh Dang to make sure this is > FIPS-compliant. > > Sorry for the confusing notation on the slides and in draft-04. > > The intention is to get as close to the OpenPGP construction as we can, > which is: > > SHA3-*( mlkemSS || tradSS || tradCT || tradPK || domSep ) > > > Note: X-wing puts its spaceship ascii art domain separator first, which we > believe will not pass SP800.56Cr2; We believe it has to be at the end to > fit 56Cr2’s FixedInfo. > > The authors will work with the authors of draft-openpgp-pqc, X-Wing, and > the forthcoming KEM Combiners draft at CFRG to align hopefully to the point > of binary compatibility. I don’t think we actually need any WG feedback, > unless there are objections. > > https://github.com/lamps-wg/draft-composite-kem/issues/40 > <https://urldefense.com/v3/__https:/github.com/lamps-wg/draft-composite-kem/issues/40__;!!FJ-Y8qCqXTj2!dMdIjqsPL1q3R2Id8EA2I0a_P18dTjGENAIIStUQ4WelWt7GEPdO57e9P4Btj9-PJv_2_aYSyGnK15TQWrjHqIe_su2kRiy8HmZEJCYVSQ$> > https://github.com/lamps-wg/draft-composite-kem/issues/45 > <https://urldefense.com/v3/__https:/github.com/lamps-wg/draft-composite-kem/issues/45__;!!FJ-Y8qCqXTj2!dMdIjqsPL1q3R2Id8EA2I0a_P18dTjGENAIIStUQ4WelWt7GEPdO57e9P4Btj9-PJv_2_aYSyGnK15TQWrjHqIe_su2kRiy8HmawI8QXbA$> > > > > ISSUE #7 > > (Github: https://github.com/lamps-wg/draft-composite-kem/issues/54 > <https://urldefense.com/v3/__https:/github.com/lamps-wg/draft-composite-kem/issues/54__;!!FJ-Y8qCqXTj2!dMdIjqsPL1q3R2Id8EA2I0a_P18dTjGENAIIStUQ4WelWt7GEPdO57e9P4Btj9-PJv_2_aYSyGnK15TQWrjHqIe_su2kRiy8HmZqgIhVvw$> > ) > > > > For a security proof of the ML-KEM + ECDH combos, we can point to the > X-Wing paper. We should have a similar proof for the RSA-OAEP combos. Not > sure how to go about attracting someone to help with this, or if we should > attempt proof-writing ourselves. > > > > ISSUE #8 > > (Github: https://github.com/lamps-wg/draft-composite-kem/issues/52 > <https://urldefense.com/v3/__https:/github.com/lamps-wg/draft-composite-kem/issues/52__;!!FJ-Y8qCqXTj2!dMdIjqsPL1q3R2Id8EA2I0a_P18dTjGENAIIStUQ4WelWt7GEPdO57e9P4Btj9-PJv_2_aYSyGnK15TQWrjHqIe_su2kRiy8HmYPtzonQQ$> > ) > > KEM domain separators. > Currently we are using DER(OID) as the domain separator. We think it is > desirable that a shared secret derived for CMS cannot be swapped into, for > example, an OpenPGP or HPKE context. But maybe that does not need to be > handled at the KEM algorithm level, maybe it is already handled at the > protocol level (CMS KEMRI, for example), and so we should align on domain > separators with OpenPGP? > > For X-Wing in particular, for that one we could take the “\.//^\”, but as > mentioned above, that wouldn’t give binary compatability anyway since they > put it at the beginning, and we have to put it at the end for FIPS > reasons. Do we want binary compatibility with OpenPGP KEM and XWing. If > this is true then shouldn’t we have one composite KEM primitive draft, and > then drafts that specify usage in OpenPGP and CMS. We also need to think > about the encoding of the public key. > > > > ISSUE #9 > > (Github: https://github.com/lamps-wg/draft-composite-kem/issues/48 > <https://urldefense.com/v3/__https:/github.com/lamps-wg/draft-composite-kem/issues/48__;!!FJ-Y8qCqXTj2!dMdIjqsPL1q3R2Id8EA2I0a_P18dTjGENAIIStUQ4WelWt7GEPdO57e9P4Btj9-PJv_2_aYSyGnK15TQWrjHqIe_su2kRiy8HmbTfMJ7xA$> > ) > > The term “DHKEM” and “RSAOAEPKEM”. Are those registered and already used? > In particular, does RFC 9180 have a monopoly on the term “DHKEM”? If so, > the authors are happy to take suggestions for what to call our abstract > pseudocode in 2.3.3. > https://github.com/lamps-wg/draft-composite-kem/issues/48 > <https://urldefense.com/v3/__https:/github.com/lamps-wg/draft-composite-kem/issues/48__;!!FJ-Y8qCqXTj2!dMdIjqsPL1q3R2Id8EA2I0a_P18dTjGENAIIStUQ4WelWt7GEPdO57e9P4Btj9-PJv_2_aYSyGnK15TQWrjHqIe_su2kRiy8HmbTfMJ7xA$>. > Are we worried about name collisions of Pseudo code in RFC’s. What do we > rename it to? > > > > ISSUE #10 > > (Github: https://github.com/lamps-wg/draft-composite-kem/issues/50 > <https://urldefense.com/v3/__https:/github.com/lamps-wg/draft-composite-kem/issues/50__;!!FJ-Y8qCqXTj2!dMdIjqsPL1q3R2Id8EA2I0a_P18dTjGENAIIStUQ4WelWt7GEPdO57e9P4Btj9-PJv_2_aYSyGnK15TQWrjHqIe_su2kRiy8HmbzKCrDyw$> > > https://github.com/lamps-wg/draft-composite-kem/issues/49 > <https://urldefense.com/v3/__https:/github.com/lamps-wg/draft-composite-kem/issues/49__;!!FJ-Y8qCqXTj2!dMdIjqsPL1q3R2Id8EA2I0a_P18dTjGENAIIStUQ4WelWt7GEPdO57e9P4Btj9-PJv_2_aYSyGnK15TQWrjHqIe_su2kRiy8HmYTa0CmGw$> > ) > > > > Binding public keys in the KDF. Basically, CMS is used by a lot of > embedded and hardware things – a smartcard applet that decrypts S/MIME is > an example here. It’s never been true in the past that the device needs the > public key in order to do a decryption. Are we asking for trouble if we > suddenly make that a requirement of the RSA / ECC side of the hybrid? > Note that we only need it at the combiner level, not inside the RSA / ECC > decryption routine, which remains unmodified. > The authors vote is that this is an ok thing to prescribe, but: 1) We are > not embedded hardware vendors, and 2) we’ve been asking this question for a > while and have received zero community feedback on it. If we think this > is needed in composite, it will have to added. As an example, in > https://docs.oracle.com/javacard/3.0.5/api/javacard/security/ECPrivateKey.html > <https://urldefense.com/v3/__https:/docs.oracle.com/javacard/3.0.5/api/javacard/security/ECPrivateKey.html__;!!FJ-Y8qCqXTj2!dMdIjqsPL1q3R2Id8EA2I0a_P18dTjGENAIIStUQ4WelWt7GEPdO57e9P4Btj9-PJv_2_aYSyGnK15TQWrjHqIe_su2kRiy8HmZPOkjhhA$> > does not contain the public key. > > > > ISSUE #11 > > (Github: https://github.com/lamps-wg/draft-composite-kem/issues/51 > <https://urldefense.com/v3/__https:/github.com/lamps-wg/draft-composite-kem/issues/51__;!!FJ-Y8qCqXTj2!dMdIjqsPL1q3R2Id8EA2I0a_P18dTjGENAIIStUQ4WelWt7GEPdO57e9P4Btj9-PJv_2_aYSyGnK15TQWrjHqIe_su2kRiy8HmaztQipkQ$> > ) > > > > KDF = SHA3 … what about SHA2. > This question should probably have the same answer as Dan van Geest’s > related question about draft-cms-kyber. > The argument for is that even though ML-KEM needs SHA3 internally, this > may not always be available to the layer of code doing the combiner, or the > CMS EnvelopedData. Just a note, because the KDF is part of the composite > OID, adding HKDF-SHA2 will 2x the size of the list. If the WG wants us to > do this, great, but please don’t complain at us about the size of the list. > > > > The authors suggest, rather than 2x'ing the whole list, we do the > following: > > > > All RSA combinations use HKDF-SHA2. > > Each of the P256 and brainpoolP256 combinations are offered with both SHA3 > (to align with X-Wing), and HKDF-SHA2. The new list would then be: > > > > | Composite KEM | KDF | > > |--------- | -------- | > > | id-MLKEM512-ECDH-P256 | SHA3-256 | > > | id-MLKEM512-ECDH-P256 | HKDF-SHA2 | > > | id-MLKEM512-ECDH-brainpoolP256r1 | SHA3-256 | > > | id-MLKEM512-ECDH-brainpoolP256r1 | HKDF-SHA2 | > > | id-MLKEM512-X25519 | SHA3-256 | > > | id-MLKEM512-RSA2048 | HKDF-SHA2 | > > | id-MLKEM512-RSA3072 | HKDF-SHA2 | > > | id-MLKEM512-RSA4096 | HKDF-SHA2 | > > | id-MLKEM768-ECDH-P256 | SHA3-384 | > > | id-MLKEM768-ECDH-P256 | HKDF-SHA2 | > > | id-MLKEM768-ECDH-brainpoolP256r1 | SHA3-384 | > > | id-MLKEM768-ECDH-brainpoolP256r1 | HKDF-SHA2 | > > | id-MLKEM768-X25519 | SHA3-384 | > > | id-MLKEM1024-ECDH-P384 | SHA3-512 | > > | id-MLKEM1024-ECDH-brainpoolP384r1 | SHA3-512 | > > | id-MLKEM1024-X448 | SHA3-512 | > > {: #tab-kem-algs title="Composite KEM key types"} > > > > ISSUE #12 > > (Github: https://github.com/lamps-wg/draft-composite-kem/issues/47 > <https://urldefense.com/v3/__https:/github.com/lamps-wg/draft-composite-kem/issues/47__;!!FJ-Y8qCqXTj2!dMdIjqsPL1q3R2Id8EA2I0a_P18dTjGENAIIStUQ4WelWt7GEPdO57e9P4Btj9-PJv_2_aYSyGnK15TQWrjHqIe_su2kRiy8HmZqOxcd6Q$> > ) > > Should we remove ML-KEM512 and only offer 768 and 1024? > > > > Thanks in advance for all your feedback to move these drafts forward, > > > > The Composite Signature and KEM authors > > > > *Any email and files/attachments transmitted with it 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 > To unsubscribe send an email to spasm-leave@ietf.org >
- [lamps] Responding to ISSUE #5 Piotr Popis
- [lamps] Re: Responding to ISSUE #5 Carl Wallace
- [lamps] Re: [EXTERNAL] Responding to ISSUE #5 Mike Ounsworth
- [lamps] Re: [EXTERNAL] Responding to ISSUE #5 Tim Hollebeek
- [lamps] Re: [EXTERNAL] Responding to ISSUE #5 Tim Hollebeek
- [lamps] Re: [EXTERNAL] Responding to ISSUE #5 Mike Ounsworth
- [lamps] Re: [EXTERNAL] Responding to ISSUE #5 Mike Ounsworth
- [lamps] Re: [EXTERNAL] Responding to ISSUE #5 John Gray
- [lamps] Re: [EXTERNAL] Responding to ISSUE #5 Michael Richardson
- [lamps] Re: [EXTERNAL] Responding to ISSUE #5 Tim Hollebeek
- [lamps] Re: External email: RE: [EXTERNAL] Respon… Piotr Popis
- [lamps] Re: External email: RE: [EXTERNAL] Respon… Mike Ounsworth
- [lamps] Re: External email: RE: [EXTERNAL] Respon… Dang, Quynh H. (Fed)
- [lamps] Re: External email: RE: Re: External emai… Piotr Popis
- [lamps] Re: External email: RE: Re: External emai… Mike Ounsworth
- [lamps] Re: [EXT] Re: External email: RE: Re: Ext… Blumenthal, Uri - 0553 - MITLL
- [lamps] Re: [EXT] Re: External email: RE: Re: Ext… Mike Ounsworth
- [lamps] Re: [EXT] Re: External email: RE: Re: Ext… Piotr Popis
- [lamps] Re: [EXT] Re: External email: RE: Re: Ext… Mike Ounsworth
- [lamps] Re: [EXT] Re: External email: RE: Re: Ext… Piotr Popis
- [lamps] Re: [EXT] Re: External email: RE: Re: Ext… Phillip Hallam-Baker