NISTIR 8647, Transition to Post-Quantum Cryptography Standards
Moody, Dustin (Fed)
All,
The initial public draft (ipd) of NIST Interagency Report (IR) 8547, Transition to Post-Quantum Cryptography Standards, is now available for public comment.
https://csrc.nist.gov/pubs/ir/8547/ipd
This report describes NIST’s expected approach to transitioning from quantum-vulnerable cryptographic algorithms to post-quantum digital signature algorithms and key-establishment schemes. It identifies existing quantum-vulnerable cryptographic standards and the current quantum-resistant standards that will be used in the migration. This report should inform the efforts and timelines of federal agencies, industry, and standards organizations for migrating information technology products, services, and infrastructure to PQC. Comments received on this draft will be used to revise this transition plan and feed into other algorithm and application-specific guidance for the transition to PQC.
The public comment period is open through January 10, 2025. See the publication details for a copy of the draft and instructions for submitting comments.
Mike Gardiner
Do you anticipate deprecating more options before 2035? Using something as if it was acceptable a few months before it transitions to disallowed seems odd. I would almost wonder why not mark them all deprecated in 2030 or 2033
perhaps.
Best Regards,
Michael
--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/SA1PR09MB86695DBADACFD5A025E35FECE5592%40SA1PR09MB8669.namprd09.prod.outlook.com.
D. J. Bernstein
> The initial public draft (ipd) of NIST Interagency Report (IR) 8547,
> Transition to Post-Quantum Cryptography Standards, is now available
> for public comment.
ECC is also a timeline for discouraging/disallowing ECC+PQ?
For reasons explained in my pqc-forum posting dated 16 Oct 2024 21:14:23
+0200, I was hoping to see a document with (1) a much faster timeline for
discouraging/disallowing ECC but (2) a clear statement that this isn't
discouraging/disallowing ECC+PQ.
---D. J. Bernstein
John Mattsson
Thanks Dustin,
Good with a clear date, 2035, for disallowment of RSA and ECC.
The first implication of this new very though requirement from US government is that Ericsson, telecom, and most other industries will very likely go for 100% hybrids aligning with e.g., ANSSI’s requirement that "Post-quantum algorithms must be hybridized" [1]. When SIKE was presented at the first PQC workshop, Shamir said: "I don't think this should be deployed in the next 20 years". The same is true for early implementations, many of them have severe implementation bugs and the vast majority of them have horrible side-channels. We have previous had a lot of discussions internally about using non-hybrids, but I think this new requirement from US government puts an abrupt end to such discussions. The 2035 end date means that we need to pick the very first available implementations and use them in production systems.
As NIST correctly states, the journey from algorithm standardization (2024) to full integration into information systems can take 20 years. In retrospect, there should probably not have been such a long competition, but instead the most promising candidates should have been picked much earlier.
Dan Bernstein wrote:
>Can you please clarify whether the timeline for discouraging/disallowing
>ECC is also a timeline for discouraging/disallowing ECC+PQ?
My understanding of the definition "disallowed - The algorithm or key length is no longer allowed for applying cryptographic protection" is that a ML-KEM-512+P-521 hybrid would have a NIST security strength of 256 bit until 2035 when it drops to 128 bits (or category 1).
Cheers,
John
--
bruno
Hi,
I read it as ECC is disallowed in hybrid or single use after 2035 and it make sense IMHO anyway starting to when a CRQC is available.
I think it would be secure to write that after 2035 we should
have PQC1 + PQC2 even PQC1 (ML-DSA, ML-KEM ...) is estimated to
have more than X (X=128, 256) security bits to avoid other
issues... just a thought...I do not see any reason to not write as
a recommendation.
B.
D. J. Bernstein
> I read it as ECC is disallowed in hybrid or single use after 2035
interpreting it that way (disallowing ECC includes disallowing ECC+PQ
hybrids), readers interpreting it the other way (the critical point is
to include PQ, so of course disallowing ECC doesn't disallow ECC+PQ),
and readers who aren't sure. So clarification is needed.
> and it make sense IMHO anyway starting to when a CRQC is available.
Anyway, the goal of the White House directive at hand is "moving the
maximum number of systems off quantum-vulnerable cryptography within a
decade of the publication of the initial set of standards". ECC+PQ isn't
any more quantum-vulnerable than PQ is. A clear recommendation of ECC+PQ
does a better job of encouraging a prompt move than recommending PQ.
---D. J. Bernstein
Mike Gardiner
Dan,
ECC+PQC is clearly more vulnerable in a post quantum world because there is a wider attack surface that is inherently vulnerable. There aren't many real examples of implementations for hybrid cryptography today. That complexity will come with exploitable bugs that will cause harm along the way. Is that pain worth it for a few years of utility?
Duplication/Redundancy isn't defence-in-depth. It was a solution to be both compliant and ensure due diligence around long term data protection.
--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/20241113105522.450263.qmail%40cr.yp.to.
Paulo Barreto
--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
John Mattsson
Mike Gardiner wrote:
>ECC+PQC is clearly more vulnerable in a post quantum
>world because there is a wider attack surface
That's like saying that the attack surface is larger if you wear both sides of your suspenders...
It is but attacks on one side will not make your pants fall off...
Cheers,
John
Regenscheid, Andrew R. (Fed)
When an algorithm is "disallowed" according to SP 800-131A or NIST IR 8547, it may no longer be used "for the stated purpose." Essentially one must assume that a disallowed digital signature scheme is vulnerable to forgeries, a disallowed key-establishment scheme is vulnerable to key recovery attacks, etc. This is no different from any other algorithm that is not "approved."
Our current and planned approach to hybrid modes would accommodate the use of unapproved algorithms alongside approved algorithms, provided the scheme is designed to remain secure if only the approved algorithm is secure. This applies whether the unapproved algorithm is one that has never been approved or is one that was previously approved but has become disallowed.
We can clarify this point in the NIST IR. Additional requirements and guidance will be developed as part of the upcoming SP 800-227 on KEMs, and revisions to our key derivation guidelines (e.g., SP 800-56C).
Regards,
Andy Regenscheid, NIST
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/20241112200508.406011.qmail%40cr.yp.to <https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/20241112200508.406011.qmail%40cr.yp.to>.
Deirdre Connolly
Our current and planned approach to hybrid modes would accommodate the use of unapproved algorithms alongside approved > algorithms, provided the scheme is designed to remain secure if only the approved algorithm is secure. This applies whether the unapproved algorithm is one that has never been approved or is one that was previously approved but has become disallowed.
We can clarify this point in the NIST IR. Additional requirements and guidance will be developed as part of the upcoming SP 800-227 on KEMs, and revisions to our key derivation guidelines (e.g., SP 800-56C).
Yes please.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CO6PR09MB821375EB2DC278C7E3936326E45A2%40CO6PR09MB8213.namprd09.prod.outlook.com.
JOHNSON Darren
It is good to have that clarified/confirmed. Thanks
I have a follow up question for further clarification.
In relation to SP800-56C, there is another thread called " concatenation of key-establishment schemes" that relates to the topic discussed here. It refers to the text that describes how to support approved composite key-establishments. Where Z'=Z||T.
The focus of the existing text is on Z, and how Z is a produced using an approved scheme. And that T is some other value that is pre-shared or established using another scheme that may or may not be approved.
Is the emphasis that is put on Z intentional/significant? Or just a result of the wording that is used? Does it matter which of the two values (Z or T) is established using a approved scheme? Does it matter which value is first and which is second when they are concatenated? The wording seems to focus more on Z than on T.
The reason I ask is that most protocols were designed to establish Z. And when they adopted hybrid, the additional algorithm (typically ML_KEM) is used to establish T. This is clearly approved as both ECDH (assuming the approved curves are used) and ML-KEM is approved. But in 2035 when ECDH is no longer allowed, those existing protocols will no longer have a Z value that is established using an approved scheme. Will be this a problem that needs to be addressed? Or is it ok to have Z and T concatenated in any order?
Thanks
Darren
To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CO6PR09MB821375EB2DC278C7E3936326E45A2%40CO6PR09MB8213.namprd09.prod.outlook.com.
JOHNSON Darren
I've seen that draft. Thanks. I think it emphasizes the relevance of my question. That draft explicitly states that the ML-KEM established secret is put first. That draft was written based on the current wording used by NIST, so what was done in that draft makes sense. But what happens if/when ML-KEM is dropped from FIPS for whatever reason before classical ECC is dropped? New RFCs need to be created and protocol implementations will all need to change.
I think it is important that we get confirmation that the wording used was specific. If NIST really is mandating that the first value in a Z'=Z||T type of construction must be an establishing using an approved scheme, and that the first value cannot be a value established using non-approved scheme, then hybrid schemes may want to take that in to consideration to avoid future pains.
Thanks
Darren
-----Original Message-----
From: Arne Padmos <he...@arnepadmos.com>
Sent: Thursday, November 14, 2024 3:54 AM
To: JOHNSON Darren <darren....@thalesgroup.com>
Cc: pqc-forum <pqc-...@list.nist.gov>
Subject: Re: [pqc-forum] NISTIR 8647, Transition to Post-Quantum Cryptography Standards
See section 3 of
https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-mlkem/ for relevant background info:
Both groups enable the derivation of TLS session keys using FIPS-
approved schemes. NIST's special publication 800-56Cr2 [SP56C]
approves the usage of HKDF [HKDF] with two distinct shared secrets,
with the condition that the first one is computed by a FIPS-approved
key-establishment scheme. FIPS also requires a certified
implementation of the scheme, which will remain more ubiqutous for
secp256r1 in the coming years.
For this reason we put the ML-KEM-768 shared secret first in
X25519MLKEM768, and the secp256r1 shared secret first in
SecP256r1MLKEM768.
Cheers,
Arne
Russ Housley
I think it is important that we get confirmation that the wording used was specific. If NIST really is mandating that the first value in a Z'=Z||T type of construction must be an establishing using an approved scheme, and that the first value cannot be a value established using non-approved scheme, then hybrid schemes may want to take that in to consideration to avoid future pains.
Loganaden Velvindron
Please kindly note that I would also suggest identifying and fixing
servers/middleboxes that don't read large TLS client hello messages
properly and instead downgrade to
classic TLS client hello messages.
(https://tldr.fail/).
This could be added to section 3.1.3. Network Security Protocols where
TLS migration strategy is discussed.
> You received this message because you are subscribed to the Google Groups "pqc-forum" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
Nadim Kobeissi
https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf
The table appears to erroneously refer to ML-DSA-768 and ML-DSA-1024, whereas these should be (unless I’m mistaken) ML-KEM-768 and ML-KEM-1024.
Nadim Kobeissi
Symbolic Software • https://symbolic.software
Arne Padmos
Mike Ounsworth
Dustin,
Substantive feedback:
I would add a glossary. It would be great for NIST to provide an authoritative definition to a bunch of terms that have lead to great deals of hallway arguments -- “post quantum” vs “quantum resistant” vs “quantum secure” vs “quantum safe”. Personally, I like the interpretation that “Post-Quantum” is simply a name for the set of algorithms that arose from the NIST Post-Quantum “Competition”, and that PQ algs can be used to build a “quantum-secure” or “quantum-safe” or “quantum-resistant” solution. Once you define these terms, you can straighten out your usage of them because I think you’re using a few of these interchangeably throughout. Also “classical” vs “traditional” vs “quantum-vulnerable” vs “quantum-cryptography (QKD and friends)”.
Are you brave enough (and is this document the right place) to take a stab at defining “cryptography agility”? This is a term in need of a robust definition, and I think some of the sections would benefit from it.
4.1
I notice that you have not given yourself the ability to move these timelines forward if quantum computer research progresses faster than expected.
Referring to EC / RSA by bit strength seems like it might be a bit of a moving goalpost over time if, for example, we see a big advancement in number field sieve that significantly drops all RSA variants’ security. Is this intentional? If so, it’s probably worth stating that explicitly.
Nitpicky feedback:
1. Introduction
“In response, NIST has released three PQC standards…” Why no mention of SP 800-208 here? It is mentioned further down in the document.
The framing of “harvest now, decrypt later” makes it seem like only encryption has urgency. Of course, there are also signature usecases with similar levels of urgency and criticality, let’s not downplay that.
- Scope and Purpose
It might be worth expanding, even for one sentence, on why the PQC migration has an unprecedented scale -- you have to touch *everything*. And also unprecedented complexity – bigger size, KEMs don’t fit cleanly into protocols designed for RSA or DH, etc.
2.1.2 Key Establishment
It might be worth a sentence describing that the three key establishment types described here (RSA, ECDH, ML-KEM) all have different APIs that cause them to behave differently, and therefore ML-KEM can not always be used as a direct drop-in-replacement to existing protocols and applications. You allude to this in 2.2.1, but I would bring it up here more explicitly. Another source of refactoring is the inordinate amount of RSA stuff that “cheats” and uses an encryption key to sign something like a CSR. You just won’t be able to do this with PQC algs. A lot of registration flows are going to need serious re-thinking.
2.1.3 Symmetric Cryptography
I find your definition a bit wonky because hash functions, KDFs, and random bit generators don’t have “keys”, nor do they have “an operation and its inverse”. Perhaps this would present cleaner if you split this section into “keyed” and “non-keyed” symmetric primitives?
2.2.1
You are using here the term “classical” for the first time. This probably deserves a proper definition up above.
Note: within the IETF, we prefer “traditional” – “quantum-vulnerable” is also popular -- because in physics “classical” is the opposite of “quantum”, so you would assume that “classical cryptography” is anything that runs on my laptop, which includes both RSA and ML-KEM, and that the opposite is “quantum cryptography” which requires quantum hardware, such a QKD. In the end, you’re probably good to use whatever terms you want, just define it clearly at the top.
2.2.2
Nit: JCA is not a library, it’s just an interface (set of APIs) that any java-compatible crypto library has to implement. The java runtime ships with the Oracle SUN Provider as its default crypto library [1].
3 Migration Considerations
This wording really emphasizes that encryption is the only use-case with urgency, and not signatures. I would change “avoid having their encrypted data exposed” to “avoid having their cryptographically-protected data compromised”. Similarly, the reference to “harvest now, decrypt later” should be accompanied by the signature equivalent, which unfortunately doesn’t have a flashy name, but might be something like “eventual forgery of long-lived signed data”.
3.1.1 Code Signing
Another case is that there’s a lot of old software in the world. Go have a poke around your C:\Program Files and I bet you’ll find some DLLs that were built in 2008 and are still happily running. Giving signed software packages the longest possible shelf-life is a good thing.
3.1.4
I find it a little odd that you’re mentioning S/MIME here, but not OpenPGP, PDF signing, etc. And that you don’t mention specific technologies / protocols in other subsections of 3.1.
3.2 Hybrids
You expected me to have lots to say here. No, this is well-written, I have no objections.
Table 1
Thank you for including this. This was actually fairly hard to find and reference before.
Table 5 has a typo: it lists ML-DSA parameter sets.
Table 7 is interesting. Am I supposed to infer that SHA-1 is still allowed in contexts where only preimage security is required? Is that actual NIST guidance? Am I allowed to take that to my lab and start using HMAC-SHA1 again?
[1]: https://docs.oracle.com/javase/6/docs/technotes/guides/security/SunProviders.html
---
Mike Ounsworth
From: 'Moody, Dustin (Fed)' via pqc-forum <pqc-...@list.nist.gov>
Sent: Tuesday, November 12, 2024 12:56 PM
To: pqc-forum <pqc-...@list.nist.gov>
Subject: [EXTERNAL] [pqc-forum] NISTIR 8647, Transition to Post-Quantum Cryptography Standards
All, The initial public draft (ipd) of NIST Interagency Report (IR) 8547, Transition to Post-Quantum Cryptography Standards, is now available for public comment. https: //csrc. nist. gov/pubs/ir/8547/ipd This report describes NIST’s expected approach
--
David A. Cooper
Table 7 is interesting. Am I supposed to infer that SHA-1 is still allowed in contexts where only preimage security is required? Is that actual NIST guidance? Am I allowed to take that to my lab and start using HMAC-SHA1 again?
Information about the status of SHA-1 and HMAC-SHA1 may be found
in SP
800-131A Rev. 2 (Sections 9 and 10) and the draft version of
SP
800-131A Rev. 3 (Sections 11 and 13). Revision 3 is open for
public comment until December 4, 2024.
Jordi Mur work
Are you brave enough (and is this document the right place) to take a stab at defining “cryptography agility”? This is a term in need of a robust definition, and I think some of the sections would benefit from it.
2.2.1
You are using here the term “classical” for the first time. This probably deserves a proper definition up above.
Note: within the IETF, we prefer “traditional” – “quantum-vulnerable” is also popular -- because in physics “classical” is the opposite of “quantum”, so you would assume that “classical cryptography” is anything that runs on my laptop, which includes both RSA and ML-KEM, and that the opposite is “quantum cryptography” which requires quantum hardware, such a QKD. In the end, you’re probably good to use whatever terms you want, just define it clearly at the top.
Mario Schiener
Best Regards | Viele Grüße
Mario Schiener
Project Lead of Airbus Cryptographic Obsolescence Working Group
Digital Trust Solutions Architect
Airbus Digital Trust Solutions - DSP
Willy-Messerschmitt-Str. 1
82024 Taufkirchen
Germany
Phone: +49 (0) 89 607 200 80
Mobile: +49 (0) 151 280 578 63
Mailto: mario.s...@airbus.com
Visit us on our HUB Community – accessible for Airbus employee only.
Sitz der Gesellschaft: Ottobrunn
Registergericht: Amtsgericht München, HRB 107 648
Vorsitzender des Aufsichtsrates: Dr. Thomas Toepfer
Geschäftsführung: Dr. Michael Schoellhorn (Vorsitzender), Marcella Hoffmann, Andrea Willmeroth, Harald Mannheim
If you are not the intended recipient, please notify Airbus immediately and delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.
John Mattsson
Hi,
Here is a link to the comments Ericsson sent to NIST
https://emanjon.github.io/NIST-comments/2024%20-%20IR%208547.pdf
We think NIST IR 8547 should be rewritten with a strong focus on prioritization and classification. The broad-brush approach required by the initial public draft can have severe negative security and economic consequences. As of today, assessments of deprecation based on prioritization classification should be deferred to industry-led standardization bodies, which have the in-depth knowledge of how NIST algorithms are utilized, the required protection lifetimes, the value of the protected node or data, and the timelines for system upgrades driven by other factors.
The report should clarify early on that “deprecated” also apply to already deployed hardware, much of which cannot be updated. Following the draft report, organizations striving to use only “acceptable” cryptography will need to replace almost all existing hardware, as well as hardware deployed over the next few years, before January 1, 2031. Have the Department of Commerce analyzed the economic consequences of this?
It is hard to understand why the US government thinks that Mr. Arkko’s connected toaster [1] should follow the same timeline as US national security systems protecting highly classified data that need to be confidential for many decades [2]. Formulated differently, it is hard to understand why the US national security systems do not have harder requirements than Mr. Arkko’s connected toaster.
Cheers,
John
[1] Now, Even Granny's Fuzzy Slippers Are Texting You
https://www.wsj.com/articles/SB10001424052702303544604576434013394780764
[2] Announcing the Commercial National Security Algorithm Suite 2.0
https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF
Sebastien Riou
Sebastien Riou
Director, Product Security Architecture
PQShield Ltd
M: +33 782 320 285
--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
John Mattsson
Hi,
I completely agree that there are cybersecurity threats to Mr. Arkko's connected toaster and that it should eventually be migrated. However, I question the logic of migrating Mr. Arkko's toaster at the same time as U.S. national security systems that protect highly classified data requiring confidentiality for many decades.
National security systems must be migrated long before CRQCs (Cryptographically Relevant Quantum Computers) are available to ensure adequate protection. In contrast, to safeguard against malware, Mr. Arkko’s connected toaster would only need migration when CRQCs become a reality. Given that Mr. Arkko's toaster is a unique construction and low value, it seems improbable that nation-states would allocate their expensive and scarce CRQC resources to ignite Mr. Arkko's house. Early CRQCs will likely be prohibitively expensive, so initial attackers will almost certainly focus on high-value targets [1].
This leaves two plausible conclusions:
- The NSA made a significant mistake, and Suite B and CNSA 1.0 will not protect highly classified data for the necessary duration.
- NIST IR 8547 is requiring Mr. Arkko to migrate his toaster far earlier than necessary.
I see no reason to believe the first conclusion. The NSA operates with a high degree of competence, and I suspect they share the view of their Five Eyes partner, ASD, that already encrypted data will remain secure for the duration of its sensitivity [2].
Cheers,
John
[1] On factoring integers, and computing discrete logarithms and orders, quantumly
https://www.wsj.com/articles/SB10001424052702303544604576434013394780764
[2] ASD says quantum no immediate threat to encrypted government data
From: Sebastien Riou <sebasti...@pqshield.com>
Date: Saturday, 11 January 2025 at 14:38
To: John Mattsson <john.m...@ericsson.com>
Cc: pqc-forum <pqc-...@list.nist.gov>
Sophie Schmieg
Jacob Alperin-Sheriff
Sebastien Riou
Mr. Arkko’s connected toaster would only need migration when CRQCs become a reality.
Given that Mr. Arkko's toaster is a unique construction and low value, it seems improbable that nation-states would allocate their expensive and scarce CRQC resources to ignite Mr. Arkko's house.
Early CRQCs will likely be prohibitively expensive, so initial attackers will almost certainly focus on high-value targets [1].
Sebastien Riou
Director, Product Security Architecture
PQShield Ltd
M: +33 782 320 285
dustin...@nist.gov
Q R
--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/aaeafedc-8f43-4fd5-ae3d-8b427d27a92cn%40list.nist.gov.
John Mattsson
Hi,
I appreciated that NIST’s slides on IR 8547 highlighted both long-lived confidentiality and long-lived cryptographic infrastructures as priorities. I don’t see why a nation-state would spend costly CRQC resources to decrypt past communications but refrain from using them to forge current signatures. After all, many signatures protect high-value targets.
Several comments on IR 8547 ipd requested clarification on hybrids. Which types of hybrids are approved, and will hybrids be disallowed after 2035? If we set aside hybrids between two approved algorithms and focus only on PQC/classical hybrids, I believe the following points apply:
- Pre-2024: PQC not standardized and should be seen as contributing zero security. Security relies on Traditional. Important that the hybrid does not weaken the security of Traditional.
- Post-2035: Traditional disallowed and should be seen as contributing zero security. Security relies on PQC. Important that the hybrid does not weaken the security of PQC.
In addition to clarifying that well-designed PQC/classical hybrids will remain permitted after 2035, I believe NIST IR 8547 should explicitly state that any PQC/classical hybrid that weakens the security of the PQC component will be disallowed after 2035. Examples
include ML-KEM hybrids that provide only IND-CPA security, as well as ML-DSA, SLH-DSA, or FN-DSA hybrids with trivial attacks on SUF-CMA security. I think almost all hybrid KEMs I have seen achieve IND-CCA2 security, and draft-josefsson-ssh-ed25519mldsa65
is a hybrid signature proposal for SSH that provides SUF-CMA security even when ECC is broken by CRCQs.
I really appreciate that both ML-KEM and HQC-KEM achieve IND-CCA2 security, and that ML-DSA, SLH-DSA, and FN-DSA are all believed to meet, or come close to meeting, SUF-CMA security.
Cheers,
John
--
John Mattsson
Hi,
The only statement IR 8547 makes regarding SP 800-57 is that "NIST’s long-term cryptographic algorithm transition plans are outlined in SP 800-57"
- I think IR 8547 should also reference SP 800-57 for the definition of the security categories, as is done in FIPS 203–205: “The security categories 1–5 are defined in SP 800-57, Part 1”
- I think IR 8547 should also reference SP 800-57 for additional guidance and requirements on interpreting “Disallowed after 2035”. In SP 800-57, the usage period is typically divided into two parts: the originator-usage period and the recipient-usage period. As stated in Section 5.6.4: “The period allowed for applying protection (the originator-usage period) could be shorter than the algorithm security lifetime (see Figure 2).”
Cheers,
John