rfc9958.original.md   rfc9958.md 
--- ---
title: "Post-Quantum Cryptography for Engineers" title: "Post-Quantum Cryptography for Engineers"
abbrev: "PQC for Engineers" abbrev: "PQC for Engineers"
category: info category: info
ipr: trust200902
docname: draft-ietf-pquip-pqc-engineers-latest docname: draft-ietf-pquip-pqc-engineers-14
submissiontype: IETF submissiontype: IETF
number: number: 9958
date: date: 2026-04
consensus: true consensus: true
v: 3 v: 3
area: "Security" lang: en
workgroup: "PQUIP" pi: [toc, symrefs, sortrefs]
area: SEC
workgroup: pquip
keyword: keyword:
- PQC - PQC
venue:
group: "pquip"
type: "Working Group"
mail: "pqc@ietf.org"
arch: "https://mailarchive.ietf.org/arch/browse/pqc/"
stand_alone: yes stand_alone: yes
pi: [toc, sortrefs, symrefs, strict, comments, docmapping] pi: [toc, sortrefs, symrefs, strict, comments, docmapping]
author: author:
- -
fullname: Aritra Banerjee fullname: Aritra Banerjee
organization: Nokia organization: Nokia
city: London city: London
country: United Kingdom country: United Kingdom
email: "aritra.banerjee@nokia.com" email: "aritra.banerjee@nokia.com"
- -
fullname: Tirumaleswar Reddy fullname: Tirumaleswar Reddy.K
organization: Nokia organization: Nokia
city: Bangalore city: Bangalore
region: Karnataka region: Karnataka
country: India country: India
email: "k.tirumaleswar_reddy@nokia.com" email: "k.tirumaleswar_reddy@nokia.com"
- -
fullname: Dimitrios Schoinianakis fullname: Dimitrios Schoinianakis
organization: Nokia organization: Nokia
city: Athens city: Athens
country: Greece country: Greece
email: "dimitrios.schoinianakis@nokia-bell-labs.com" email: "dimitrios.schoinianakis@nokia-bell-labs.com"
- -
fullname: Timothy Hollebeek fullname: Timothy Hollebeek
organization: DigiCert organization: DigiCert
city: Pittsburgh city: Pittsburgh
country: USA region: PA
country: United States of America
email: "tim.hollebeek@digicert.com" email: "tim.hollebeek@digicert.com"
- -
ins: M. Ounsworth ins: M. Ounsworth
name: Mike Ounsworth name: Mike Ounsworth
org: Entrust Limited org: Entrust Limited
abbrev: Entrust abbrev: Entrust
street: 2500 Solandt Road – Suite 100 street: 2500 Solandt Road, Suite 100
city: Ottawa, Ontario city: Ottawa, Ontario
country: Canada country: Canada
code: K2K 3G5 code: K2K 3G5
email: mike.ounsworth@entrust.com email: mike.ounsworth@entrust.com
normative: normative:
ML-KEM: ML-KEM:
title: "FIPS-203: Module-Lattice-based Key-Encapsulation Mechanism Standard" title: "Module-Lattice-Based Key-Encapsulation Mechanism Standard"
target: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf target: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf
date: false seriesinfo:
NIST FIPS: 203
DOI: 10.6028/nist.fips.203
author:
-
org: NIST
date: 2024-08
ML-DSA: ML-DSA:
title: "FIPS-204: Module-Lattice-Based Digital Signature Standard" title: "Module-Lattice-Based Digital Signature Standard"
target: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf target: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf
date: false date: 2024-08
seriesinfo:
NIST FIPS: 204
DOI: 10.6028/NIST.FIPS.204
author:
-
org: NIST
SLH-DSA: SLH-DSA:
title: "FIPS-205: Stateless Hash-Based Digital Signature Standard" title: "Stateless Hash-Based Digital Signature Standard"
target: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.205.pdf target: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.205.pdf
date: false date: 2024-08
seriesinfo:
NIST FIPS: 205
DOI: 10.6028/NIST.FIPS.205
author:
-
org: NIST
Shors: Shors:
title: "Polynomial-time algorithms for prime factorization and discrete logarithm s on a quantum computer" title: "Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithm s on a Quantum Computer"
target: https://arxiv.org/pdf/quant-ph/9508027 target: https://arxiv.org/pdf/quant-ph/9508027
author:
-
fullname: Peter W. Shor
ins: P. Shor
refcontent: >
arXiv:quant-ph/9508027v2
date: 1996-01-25
Grovers: Grovers:
title: "A fast quantum mechanical algorithm for database search" title: "A fast quantum mechanical algorithm for database search"
target: https://dl.acm.org/doi/10.1145/237814.237866 target: https://dl.acm.org/doi/10.1145/237814.237866
author:
-
fullname: Lok K. Grover
date: 1996-07-01
refcontent: >
STOC '96: Proceedings of the twenty-eighth annual ACM symposium on Theory of Co
mputing, pp. 212-219
seriesinfo:
DOI: 10.1145/237814.237866
RSA: RSA:
title: "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems+" title: "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems"
target: https://dl.acm.org/doi/pdf/10.1145/359340.359342 target: https://dl.acm.org/doi/pdf/10.1145/359340.359342
date: false author:
-
fullname: Ronald L. Rivest
-
ins: A. Shamir
-
ins: L. Adleman
date: February 1978
refcontent: >
Communications of the ACM, vol. 21, no. 2, pp. 120-126
seriesinfo:
DOI: 10.1145/359340.359342
RFC6090: RFC6090:
RFC8391: RFC8391:
RFC8554: RFC8554:
RFC8446: RFC8446:
RFC4034: RFC4034:
NTRU: NTRU:
title: "NTRU" title: "NTRU"
target: https://ntru.org/index.shtml target: https://ntru.org/index.shtml
date: false
FrodoKEM: FrodoKEM:
title: "FrodoKEM" title: "FrodoKEM"
target: https://frodokem.org/ target: https://frodokem.org/
date: false
ClassicMcEliece: ClassicMcEliece:
title: "Classic McEliece" title: "Classic McEliece"
target: https://classic.mceliece.org/ target: https://classic.mceliece.org/
date: false
FN-DSA: FN-DSA:
title: "Fast Fourier lattice-based compact signatures over NTRU" title: "FALCON: Fast Fourier lattice-based compact signatures over NTRU"
target: https://falcon-sign.info/ target: https://falcon-sign.info/
date: false date: false
RFC6090: RFC6090:
RFC8235: RFC8235:
informative: informative:
Serious-Crypt:
Grover-search: title: "Serious Cryptography, 2nd Edition"
title: "C. Zalka, “Grover’s quantum searching algorithm is optimal,” Physical Re author:
view A, vol. 60, pp. 2746-2751, 1999." -
target: fullname: Jean-Philippe Aumasson
date: false date: August 2024
refcontent: ISBN 9781718503847
Grover-Search:
title: "Grover's quantum searching algorithm is optimal"
target: https://link.aps.org/doi/10.1103/PhysRevA.60.2746
author:
-
fullname: Christof Zalka
date: October 1999
refcontent: Physical Review A, vol. 60, no. 4, pp. 2746-2751
seriesinfo:
DOI: 10.1103/PhysRevA.60.2746
Threat-Report: Threat-Report:
title: "Quantum Threat Timeline Report 2020" title: "Quantum Threat Timeline Report 2020"
target: https://globalriskinstitute.org/publications/quantum-threat-timeline-rep ort-2020/ target: https://globalriskinstitute.org/publications/quantum-threat-timeline-rep ort-2020/
date: false author:
-
fullname: Michele Mosca
-
fullname: Marco Piani
refcontent: Global Risk Institute
date: 2021-01-27
QC-DNS: QC-DNS:
title: "Quantum Computing and the DNS" title: "Quantum Computing and the DNS"
target: https://www.icann.org/octo-031-en.pdf target: https://www.icann.org/octo-031-en.pdf
date: false author:
-
fullname: Paul Hoffman
date: 2024-04-22
refcontent: ICANN Office of the Chief Technology Officer, OCTO-031v2
NIST: NIST:
title: "Post-Quantum Cryptography Standardization" title: "Post-Quantum Cryptography Standardization"
target: https://csrc.nist.gov/projects/post-quantum-cryptography/post-quantum-cr yptography-standardization target: https://csrc.nist.gov/projects/post-quantum-cryptography/post-quantum-cr yptography-standardization
author:
-
org: NIST
date: false date: false
Cloudflare: Cloudflare:
title: "NIST’s pleasant post-quantum surprise" title: "NIST's pleasant post-quantum surprise"
target: https://blog.cloudflare.com/nist-post-quantum-surprise/ target: https://blog.cloudflare.com/nist-post-quantum-surprise/
date: false author:
-
fullname: Bas Westerbaan
date: 2022-07-08
refcontent: Cloudflare Blog
CS01: CS01:
title: "Design and Analysis of Practical Public-Key Encryption Schemes Secure ag ainst Adaptive Chosen Ciphertext Attack" title: "Design and Analysis of Practical Public-Key Encryption Schemes Secure ag ainst Adaptive Chosen Ciphertext Attack"
target: https://eprint.iacr.org/2001/108 target: https://eprint.iacr.org/2001/108
date: false author:
-
fullname: Ronald Cramer
-
fullname: Victor Shoup
date: 2001
refcontent: Cryptology ePrint Archive, Paper 2001/108
BHK09: BHK09:
title: "Subtleties in the Definition of IND-CCA: When and How Should Challenge-D ecryption be Disallowed?" title: "Subtleties in the Definition of IND-CCA: When and How Should Challenge-D ecryption be Disallowed?"
target: https://eprint.iacr.org/2009/418 target: https://eprint.iacr.org/2009/418
date: false author:
-
fullname: Mihir Bellare
-
fullname: Dennis Hofheinz
-
fullname: Eike Kiltz
date: 2009
refcontent: Cryptology ePrint Archive, Paper 2009/418
GMR88: GMR88:
title: "A digital signature scheme secure against adaptive chosen-message attack s." title: "A digital signature scheme secure against adaptive chosen-message attack s"
target: https://people.csail.mit.edu/silvio/Selected%20Scientific%20Papers/Digit al%20Signatures/A_Digital_Signature_Scheme_Secure_Against_Adaptive_Chosen-Message_Att ack.pdf target: https://people.csail.mit.edu/silvio/Selected%20Scientific%20Papers/Digit al%20Signatures/A_Digital_Signature_Scheme_Secure_Against_Adaptive_Chosen-Message_Att ack.pdf
date: false author:
-
fullname: Shafi Goldwasser
-
fullname: Silvio Micali
-
fullname: Ronald L. Rivest
date: April 1988
refcontent: SIAM Journal on Computing, vol. 17, no. 2, pp. 281-308
seriesinfo:
DOI: 10.1137/0217017
PQCAPI: PQCAPI:
title: "PQC - API notes" title: "PQC - API notes"
target: https://csrc.nist.gov/CSRC/media/Projects/Post-Quantum-Cryptography/docu ments/example-files/api-notes.pdf target: https://csrc.nist.gov/CSRC/media/Projects/Post-Quantum-Cryptography/docu ments/example-files/api-notes.pdf
author:
-
org: NIST
date: false date: false
RSA8HRS: RSA8HRS:
title: "How to factor 2048 bit RSA integers in 8 hours using 20 million noisy qu bits" title: "How to factor 2048 bit RSA integers in 8 hours using 20 million noisy qu bits"
target: https://arxiv.org/abs/1905.09749 target: https://arxiv.org/abs/1905.09749
date: false author:
-
fullname: Craig Gidney
-
fullname: Martin Ekera
date: 2021-04-13
refcontent: arXiv:1905.09749v3
RSA10SC: RSA10SC:
title: "Breaking RSA Encryption - an Update on the State-of-the-Art" title: "Breaking RSA Encryption - an Update on the State-of-the-Art"
target: https://www.quintessencelabs.com/blog/breaking-rsa-encryption-update-sta te-art target: https://www.quintessencelabs.com/blog/breaking-rsa-encryption-update-sta te-art
date: false author:
org: QuintessenceLabs
date: 2019-06-13
RSAShor: RSAShor:
title: "Circuit for Shor’s algorithm using 2n+3 qubits" title: "Circuit for Shor's algorithm using 2n+3 qubits"
target: https://arxiv.org/pdf/quant-ph/0205095.pdf target: https://arxiv.org/pdf/quant-ph/0205095.pdf
date: false author:
-
fullname: Stephane Beauregard
date: 2003-02-21
refcontent: arXiv:quant-ph/0205095v3
LIBOQS: LIBOQS:
title: "LibOQS - Open Quantum Safe" title: "LibOQS - Open Quantum Safe"
target: https://github.com/open-quantum-safe/liboqs target: https://github.com/open-quantum-safe/liboqs
date: false date: November 2025
refcontent: commit 97f6b86
KyberSide: KyberSide:
title: "A Side-Channel Attack on a Hardware Implementation of CRYSTALS-Kyber" title: "A Side-Channel Attack on a Hardware Implementation of CRYSTALS-Kyber"
target: https://eprint.iacr.org/2022/1452 target: https://eprint.iacr.org/2022/1452
date: false author:
-
fullname: Yanning Ji
-
fullname: Ruize Wang
-
fullname: Kalle Ngo
-
fullname: Elena Dubrova
-
fullname: Linus Backlund
date: 2022
refcontent: Cryptology ePrint Archive, Paper 2022/1452
SaberSide: SaberSide:
title: "A side-channel attack on a masked and shuffled software implementation o f Saber" title: "A side-channel attack on a masked and shuffled software implementation o f Saber"
target: https://link.springer.com/article/10.1007/s13389-023-00315-3 target: https://link.springer.com/article/10.1007/s13389-023-00315-3
date: false author:
-
fullname: Kalle Ngo
-
fullname: Elena Dubrova
-
fullname: Thomas Johansson
date: 2023-04-25
refcontent: Journal of Cryptographic Engineering, vol. 13, pp. 443-460
seriesinfo:
DOI: 10.1007/s13389-023-00315-3
SideCh: SideCh:
title: "Side-Channel Attacks on Lattice-Based KEMs Are Not Prevented by Higher-O rder Masking" title: "Side-Channel Attacks on Lattice-Based KEMs Are Not Prevented by Higher-O rder Masking"
target: https://eprint.iacr.org/2022/919 target: https://eprint.iacr.org/2022/919
date: false author:
-
fullname: Kalle Ngo
-
fullname: Ruize Wang
-
fullname: Elena Dubrova
-
fullname: Nils Paulsrud
date: 2022
refcontent: Cryptology ePrint Archive, Paper 2022/919
LatticeSide: LatticeSide:
title: "Generic Side-channel attacks on CCA-secure lattice-based PKE and KEM sch emes" title: "Generic Side-channel attacks on CCA-secure lattice-based PKE and KEM sch emes"
target: https://eprint.iacr.org/2019/948 target: https://eprint.iacr.org/2019/948
date: false author:
-
fullname: Prasanna Ravi
-
fullname: Sujoy Sinha Roy
-
fullname: Anupam Chattopadhyay
-
fullname: Shivam Bhasin
date: 2019
refcontent: Cryptology ePrint Archive, Paper 2019/948
Mitigate1: Mitigate1:
title: "POLKA: Towards Leakage-Resistant Post-Quantum CCA-Secure Public Key Encr yption" title: "POLKA: Towards Leakage-Resistant Post-Quantum CCA-Secure Public Key Encr yption"
target: https://eprint.iacr.org/2022/873 target: https://eprint.iacr.org/2022/873
date: false author:
-
fullname: Clément Hoffmann
-
fullname: Benoît Libert
-
fullname: Charles Momin
-
fullname: Thomas Peters
-
fullname: François-Xavier Standaert
date: 2022
refcontent: Cryptology ePrint Archive, Paper 2022/873
Mitigate2: Mitigate2:
title: "Leakage-Resilient Certificate-Based Authenticated Key Exchange Protocol" title: "Leakage-Resilient Certificate-Based Authenticated Key Exchange Protocol"
target: https://ieeexplore.ieee.org/document/9855226 target: https://ieeexplore.ieee.org/document/9855226
date: false author:
-
ins: T. -T. Tsai
-
ins: S. -S. Huang
-
ins: Y. -M. Tseng
-
ins: Y. -H. Chuang
-
ins: Y. -H. Hung
date: 2022
refcontent: IEEE Open Journal of the Computer Society, vol. 3, pp. 137-148
seriesinfo:
DOI: 10.1109/OJCS.2022.3198073
Mitigate3: Mitigate3:
title: "Post-Quantum Authenticated Encryption against Chosen-Ciphertext Side-Cha nnel Attacks" title: "Post-Quantum Authenticated Encryption against Chosen-Ciphertext Side-Cha nnel Attacks"
target: https://eprint.iacr.org/2022/916 target: https://eprint.iacr.org/2022/916
date: false author:
-
fullname: Melissa Azouaoui
-
fullname: Yulia Kuzovkova
-
fullname: Tobias Schneider
-
fullname: Christine van Vredendaal
date: 2022
refcontent: Cryptology ePrint Archive, Paper 2022/916
CNSA2-0: CNSA2-0:
title: "Announcing the Commercial National Security Algorithm Suite 2.0" title: "Announcing the Commercial National Security Algorithm Suite 2.0"
target: https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_AL GORITHMS.PDF target: https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_AL GORITHMS.PDF
date: false author:
-
org: NSA
date: September 2022
LattFail1: LattFail1:
title: "Decryption Failure Attacks on IND-CCA Secure Lattice-Based Schemes" title: "Decryption Failure Attacks on IND-CCA Secure Lattice-Based Schemes"
target: https://link.springer.com/chapter/10.1007/978-3-030-17259-6_19#chapter-i target: https://link.springer.com/chapter/10.1007/978-3-030-17259-6_19
nfo author:
date: false -
fullname: Jan-Pieter D'Anvers
-
fullname: Qian Guo
-
fullname: Thomas Johansson
-
fullname: Alexander Nilsson
-
fullname: Frederik Vercauteren
-
fullname: Ingrid Verbauwhede
date: 2019-04-06
refcontent: Public-Key Cryptography - PKC 2019, Lecture Notes in Computer Scienc
e, vol. 11443, pp. 565-598
seriesinfo:
DOI: 10.1007/978-3-030-17259-6_19
LattFail2: LattFail2:
title: "(One) Failure Is Not an Option: Bootstrapping the Search for Failures in Lattice-Based Encryption Schemes." title: "(One) Failure Is Not an Option: Bootstrapping the Search for Failures in Lattice-Based Encryption Schemes"
target: https://link.springer.com/chapter/10.1007/978-3-030-45727-3_1 target: https://link.springer.com/chapter/10.1007/978-3-030-45727-3_1
date: false date: 2020-05-01
author:
-
fullname: Jan-Pieter D'Anvers
-
fullname: Mélissa Rossi
-
fullname: Fernando Virdia
refcontent: Advances in Cryptology - EUROCRYPT 2020, Lecture Notes in Computer S
cience, vol. 12107, pp. 3-33
seriesinfo:
DOI: 10.1007/978-3-030-45727-3_1
BSI-PQC: BSI-PQC:
title: "Quantum-safe cryptography – fundamentals, current developments and recom mendations" title: "Quantum-safe cryptography - fundamentals, current developments and recom mendations"
target: https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Brochur e/quantum-safe-cryptography.html?nn=916626 target: https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Brochur e/quantum-safe-cryptography.html?nn=916626
date: 18.05.2022 author:
-
org: BSI
date: 2022-05-18
PQRSA: PQRSA:
title: "Post-quantum RSA" title: "Post-quantum RSA"
target: https://cr.yp.to/papers/pqrsa-20170419.pdf target: https://cr.yp.to/papers/pqrsa-20170419.pdf
date: 2017.04.19 author:
-
fullname: Daniel J. Bernstein
-
fullname: Nadia Heninger
-
fullname: Paul Lou
-
fullname: Luke Valenta
date: 2017-04-19
SP-800-56C: SP-800-56C:
title: "Recommendation for Key-Derivation Methods in Key-Establishment Schemes" title: "Recommendation for Key-Derivation Methods in Key-Establishment Schemes"
target: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Cr2. pdf target: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Cr2. pdf
date: false author:
-
fullname: Elaine Barker
-
fullname: Lily Chen
-
fullname: Richard Davis
date: August 2020
seriesinfo:
NIST SP: 800-56Cr2
DOI: 10.6028/NIST.SP.800-56Cr2
Lyu09: Lyu09:
title: "V. Lyubashevsky, “Fiat-Shamir With Aborts: Applications to Lattice and Factoring-Based Signatures“, ASIACRYPT 2009" title: "Fiat-Shamir With Aborts: Applications to Lattice and Factoring-Based Si gnatures"
target: https://www.iacr.org/archive/asiacrypt2009/59120596/59120596.pdf target: https://www.iacr.org/archive/asiacrypt2009/59120596/59120596.pdf
author:
-
fullname: Vadim Lyubashevsky
date: false date: false
refcontent: ASIACRYPT 2009
SP-1800-38C: SP-1800-38C:
title: "Migration to Post-Quantum Cryptography Quantum Readiness: Quantum-Resis tant Cryptography Technology Interoperability and Performance Report" title: "Migration to Post-Quantum Cryptography Quantum Readiness: Testing Draft Standards, Volume C: Quantum-Resistant Cryptography Technology Interoperability and Performance Report"
target: https://www.nccoe.nist.gov/sites/default/files/2023-12/pqc-migration-ni st-sp-1800-38c-preliminary-draft.pdf target: https://www.nccoe.nist.gov/sites/default/files/2023-12/pqc-migration-ni st-sp-1800-38c-preliminary-draft.pdf
date: false author:
-
fullname: William Newhouse
-
fullname: Murugiah Souppaya
-
fullname: William Barke
-
fullname: Chris Brown
-
fullname: Panos Kampanakis
-
fullname: Jim Goodman
-
fullname: Julien Prat
-
fullname: Robin Larrieu
-
fullname: John Gray
-
fullname: Mike Ounsworth
-
fullname: Cleandro Viana
-
fullname: Hubert Le Van Gong
-
fullname: Kris Kwiatkowsk
-
fullname: Anthony Hu
-
fullname: Robert Burns
-
fullname: Christian Paquin
-
fullname: Jane Gilbert
-
fullname: Gina Scinta
-
fullname: Eunkyung Kim
-
fullname: Volker Krumme
date: December 2023
seriesinfo:
NIST SP: 1800-38C
refcontent: Preliminary Draft
KEEPINGUP: KEEPINGUP:
title: "Keeping Up with the KEMs: Stronger Security Notions for KEMs and automate d analysis of KEM-based protocols" title: "Keeping Up with the KEMs: Stronger Security Notions for KEMs and automate d analysis of KEM-based protocols"
target: https://eprint.iacr.org/2023/1933 target: https://eprint.iacr.org/2023/1933
author:
-
fullname: Cas Cremers
-
fullname: Alexander Dax
-
fullname: Niklas Medinger
date: 2023
refcontent: Cryptology ePrint Archive, Paper 2023/1933
NISTFINAL: NISTFINAL:
title: "NIST Releases First 3 Finalized Post-Quantum Encryption Standards" title: "NIST Releases First 3 Finalized Post-Quantum Encryption Standards"
target: https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-final ized-post-quantum-encryption-standards target: https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-final ized-post-quantum-encryption-standards
author:
-
org: NIST
date: 2024-08-13
ANSSI: ANSSI:
title: "ANSSI views on the Post-Quantum Cryptography transition" title: "ANSSI views on the Post-Quantum Cryptography transition (2023 follow up)"
target: https://cyber.gouv.fr/sites/default/files/document/follow_up_position_pap er_on_post_quantum_cryptography.pdf target: https://cyber.gouv.fr/sites/default/files/document/follow_up_position_pap er_on_post_quantum_cryptography.pdf
author:
-
org: ANSSI
date: 2023-12-21
HQC: HQC:
title: "HQC" title: "HQC"
target: http://pqc-hqc.org/ target: http://pqc-hqc.org/
date: false
BIKE: BIKE:
title: "BIKE" title: "BIKE"
target: http://pqc-hqc.org/ target: http://pqc-hqc.org/
date: false
PQUIP-WG: PQUIP-WG:
title: Post-Quantum Use In Protocols (pquip) Working Group title: "Post-Quantum Use In Protocols (pquip)"
author:
-
org: IETF
target: https://datatracker.ietf.org/group/pquip/documents/ target: https://datatracker.ietf.org/group/pquip/documents/
date: false
OQS: OQS:
title: Open Quantum Safe Project title: "Open Quantum Safe Project"
target: https://openquantumsafe.org/ target: https://openquantumsafe.org/
date: false
CRQCThreat: CRQCThreat:
title: "CRQCThreat" title: "Landscape of Quantum Computing"
target: https://sam-jaques.appspot.com/quantum_landscape_2024 target: https://sam-jaques.appspot.com/quantum_landscape_2024
author:
-
fullname: Sam Jaques
date: false
QuantSide: QuantSide:
title: "QuantSide" title: "Exploration of Quantum Computer Power Side-Channels"
target: https://arxiv.org/pdf/2304.03315 target: https://arxiv.org/pdf/2304.03315
author:
-
fullname: Chuanqi Xu
-
fullname: Ferhat Erata
-
fullname: Jakub Szefer
date: 2023-05-09
refcontent: arXiv:2304.03315v2
AddSig: AddSig:
title: "AddSig" title: "Post-Quantum Cryptography: Additional Digital Signature Schemes"
target: https://csrc.nist.gov/Projects/pqc-dig-sig/standardization target: https://csrc.nist.gov/Projects/pqc-dig-sig/standardization
author:
-
org: NIST
date: false
BPQS: BPQS:
title: "BPQS" title: "Blockchained Post-Quantum Signatures"
target: https://eprint.iacr.org/2018/658.pdf target: https://eprint.iacr.org/2018/658
author:
-
fullname: Konstantinos Chalkias
-
fullname: James Brown
-
fullname: Mike Hearn
-
fullname: Tommy Lillehagen
-
fullname: Igor Nitto
-
fullname: Thomas Schroeter
refcontent: Cryptology ePrint Archive, Paper 2018/658
PCI: PCI:
title: "Payment Card Industry Data Security Standard" title: "Payment Card Industry Data Security Standard"
author:
-
org: PCI Security Standards Council
target: https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v4_0 _1.pdf target: https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v4_0 _1.pdf
date: false
refcontent: >
PCI DSS: v4.0.1
I-D.bonnell-lamps-chameleon-certs:
display: ENC-PAIR-CERTS
I-D.connolly-cfrg-xwing-kem:
display: X-WING
I-D.hale-mls-combiner:
display: PQ-MLS
I-D.ietf-hpke-pq:
display: PQ-HPKE
I-D.ietf-lamps-pq-composite-sigs:
display: ML-DSA-X.509
I-D.ietf-pquip-hybrid-signature-spectrums:
display: HYBRID-SIG-SPECT
I-D.ietf-pquip-pqc-hsm-constrained:
display: CONSTRAIN-DEV-PCQ
I-D.ietf-tls-hybrid-design:
display: TLS-HYB-KEY-EXCH
I-D.irtf-cfrg-bbs-signatures:
display: BBS-SIG-SCHEME
I-D.irtf-cfrg-hybrid-kems:
display: PQ-KEM
I-D.ounsworth-cfrg-kem-combiners:
display: KEM-COMBINER
--- abstract --- abstract
The advent of a cryptographically relevant quantum computer (CRQC) would render state <!-- Status of I-Ds in references section:
-of-the-art, traditional public key algorithms deployed today obsolete, as the mathem
atical assumptions underpinning their security would no longer hold. To address this, [I-D.bonnell-lamps-chameleon-certs]
protocols and infrastructure must transition to post-quantum algorithms, which are d draft-bonnell-lamps-chameleon-certs-07
esigned to resist both traditional and quantum attacks. This document explains why en IESG State: I-D Exists as of 11/26/25
gineers need to be aware of and understand post-quantum cryptography (PQC), detailing
the impact of CRQCs on existing systems and the challenges involved in transitioning [I-D.connolly-cfrg-xwing-kem]
to post-quantum algorithms. Unlike previous cryptographic updates, this shift may re draft-connolly-cfrg-xwing-kem-09
quire significant protocol redesign due to the unique properties of post-quantum algo IESG State: I-D Exists as of 11/26/25
rithms.
[I-D.hale-mls-combiner]
draft-hale-mls-combiner-01
Replaced by draft-ietf-mls-combiner
[I-D.ietf-hpke-pq]
draft-ietf-hpke-pq-03
IESG State: I-D Exists as of 11/26/25
[I-D.ietf-lamps-pq-composite-sigs]
draft-ietf-lamps-pq-composite-sigs-13
IESG state: Publication Requested as of 11/26/25
[I-D.ietf-pquip-hybrid-signature-spectrums]
draft-ietf-pquip-hybrid-signature-spectrums-07
IESG state: RFC Ed Queue as of 11/26/25
[I-D.ietf-pquip-pqc-hsm-constrained]
draft-ietf-pquip-pqc-hsm-constrained-02
IESG State: I-D Exists as of 11/26/25
[I-D.ietf-sshm-ntruprime-ssh]
draft-ietf-sshm-ntruprime-ssh-06
Published as RFC 9941
[I-D.ietf-tls-hybrid-design]
draft-ietf-tls-hybrid-design-16
IESG state: RFC Ed Queue as of 11/26/25
[I-D.irtf-cfrg-bbs-signatures]
draft-irtf-cfrg-bbs-signatures-09
IESG State: I-D Exists as of 11/26/25
[I-D.irtf-cfrg-hybrid-kems]
draft-irtf-cfrg-hybrid-kems-07
IESG State: I-D Exists as of 11/26/25
[I-D.ounsworth-cfrg-kem-combiners]
draft-ounsworth-cfrg-kem-combiners-05
IESG State: Expired as of 11/26/25
-->
<!-- [rfced] FYI - We will do the following when we convert the file to RFCXML:
a) Correct author names in reference entry for draft-ietf-pquip-pqc-hsm-constrained.
Current:
[I-D.ietf-pquip-pqc-hsm-constrained]
Reddy.K, T., Wing, D., S, B., and K. Kwiatkowski,
"Adapting Constrained Devices for Post-Quantum
Cryptography", Work in Progress, Internet-Draft, draft-
ietf-pquip-pqc-hsm-constrained-02, 18 October 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-pquip-
pqc-hsm-constrained-02>.
-->
<!-- XML for reference update (draft-ietf-pquip-pqc-hsm-constrained):
<reference anchor="I-D.ietf-pquip-pqc-hsm-constrained" target="https://datatracker.ie
tf.org/doc/html/draft-ietf-pquip-pqc-hsm-constrained-02">
<front>
<title>Adapting Constrained Devices for Post-Quantum Cryptography</title>
<author initials="T." surname="Reddy" fullname="Tirumaleswar Reddy.K">
<organization>Nokia</organization>
</author>
<author initials="D." surname="Wing" fullname="Dan Wing">
<organization>Citrix</organization>
</author>
<author initials="B." surname="Salter" fullname="Ben Salter">
<organization>UK National Cyber Security Centre</organization>
</author>
<author initials="K." surname="Kwiatkowski" fullname="Kris Kwiatkowski">
<organization>PQShield</organization>
</author>
<date month="October" day="18" year="2025" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-pquip-pqc-hsm-constrained-02"
/>
</reference>
-
-->
The advent of a cryptographically relevant quantum computer (CRQC) would render state
-of-the-art, traditional public key algorithms deployed today obsolete, as the mathem
atical assumptions underpinning their security would no longer hold. To address this,
protocols and infrastructure must transition to post-quantum algorithms, which are d
esigned to resist both traditional and quantum attacks. This document explains why en
gineers need to be aware of and understand post-quantum cryptography (PQC), and it de
tails the impact of CRQCs on existing systems and the challenges involved in transiti
oning to post-quantum algorithms. Unlike previous cryptographic updates, this shift m
ay require significant protocol redesign due to the unique properties of post-quantum
algorithms.
--- middle --- middle
# Introduction # Introduction
Quantum computing is no longer just a theoretical concept in computational science an d physics; it is now an active area of research with practical implications. Consider able research efforts and enormous corporate and government funding for the developme nt of practical quantum computing systems are currently being invested. At the time t his document is published, cryptographically relevant quantum computers (CRQCs) that can break widely used asymmetric algorithms (also known as public key algorithms) are not yet available. However, there is ongoing research and development in the field o f quantum computing, with the goal of building more powerful and scalable quantum com puters. Quantum computing is no longer just a theoretical concept in computational science an d physics; it is now an active area of research with practical implications. Consider able research efforts and enormous corporate and government funding for the developme nt of practical quantum computing systems are currently being invested. At the time t his document is published, cryptographically relevant quantum computers (CRQCs) that can break widely used asymmetric algorithms (also known as public key algorithms) are not yet available. However, there is ongoing research and development in the field o f quantum computing, with the goal of building more powerful and scalable quantum com puters.
One common myth is that quantum computers are faster than conventional CPUs and GPUs in all areas. This is not the case; much as GPUs outperform general-purpose CPUs only on specific types of problems, so will quantum computers, too, have a niche set of p roblems on which they excel. Unfortunately for cryptographers, integer factorization and discrete logarithms, the mathematical problems underpinning much of classical pub lic key cryptography, happen to fall within the niche that quantum computers are expe cted to excel at. As quantum technology advances, there is the potential for future q uantum computers to have a significant impact on current cryptographic systems. Predi cting the date of emergence of a CRQC is a challenging task, and there is ongoing unc ertainty regarding when they will become practically feasible {{CRQCThreat}}. One common myth is that quantum computers are faster than conventional CPUs and GPUs in all areas. This is not the case; much as GPUs outperform general-purpose CPUs only on specific types of problems, quantum computers also have a niche set of problems o n which they excel. Unfortunately for cryptographers, integer factorization and discr ete logarithms, the mathematical problems underpinning much of classical public key c ryptography, happen to fall within the niche in which quantum computers are expected to excel. As quantum technology advances, there is the potential for future quantum c omputers to have a significant impact on current cryptographic systems. Predicting th e date of emergence of a CRQC is a challenging task, and there is ongoing uncertainty regarding when they will become practically feasible {{CRQCThreat}}.
Extensive research has produced several post-quantum cryptographic algorithms that of fer the potential to ensure cryptography's survival in the quantum computing era. How ever, transitioning to a post-quantum infrastructure is not a straightforward task, a nd there are numerous challenges to overcome. It requires a combination of engineerin g efforts, proactive assessment and evaluation of available technologies, and a caref ul approach to product development and deployment. Extensive research has produced several post-quantum cryptographic algorithms that of fer the potential to ensure cryptography's survival in the quantum computing era. How ever, transitioning to a post-quantum infrastructure is not a straightforward task, a nd there are numerous challenges to overcome. It requires a combination of engineerin g efforts, proactive assessment and evaluation of available technologies, and a caref ul approach to product development and deployment.
PQC is sometimes referred to as "quantum-proof", "quantum-safe", or "quantum-resistan t". It is the development of cryptographic algorithms designed to secure communicatio n and data in a world where quantum computers are powerful enough to break traditiona l cryptographic systems, such as RSA (Rivest–Shamir–Adleman) and ECC (Elliptic Curve Cryptography). PQC algorithms are intended to be resistant to attacks by quantum comp uters, which use quantum-mechanical phenomena to solve mathematical problems that are infeasible for classical computers. PQC is sometimes referred to as "quantum-proof", "quantum-safe", or "quantum-resistan t". It is the development of cryptographic algorithms designed to secure communicatio n and data in a world where quantum computers are powerful enough to break traditiona l cryptographic systems, such as RSA (Rivest-Shamir-Adleman) and ECC (Elliptic Curve Cryptography). PQC algorithms are intended to be resistant to attacks by quantum comp uters, which use quantum-mechanical phenomena to solve mathematical problems that are infeasible for classical computers.
As the threat of CRQCs draws nearer, engineers responsible for designing, maintaining , and securing cryptographic systems must prepare for the significant changes that th e existence of CRQCs will bring. Engineers need to understand how to implement post-q uantum algorithms in applications, how to evaluate the trade-offs between security an d performance, and how to ensure backward compatibility with current systems where ne eded. This is not merely a one-for-one replacement of algorithms; in many cases, the shift to PQC will involve redesigning protocols and infrastructure to accommodate the significant differences in resource utilization and key sizes between traditional an d PQC algorithms. Due to the wide-ranging nature of these impacts, discussions of pro tocol changes are integrated throughout this document rather than being confined to a single section. As the threat of CRQCs draws nearer, engineers responsible for designing, maintaining , and securing cryptographic systems must prepare for the significant changes that th e existence of CRQCs will bring. Engineers need to understand how to implement post-q uantum algorithms in applications, how to evaluate the trade-offs between security an d performance, and how to ensure backward compatibility with current systems where ne eded. This is not merely a one-for-one replacement of algorithms; in many cases, the shift to PQC will involve redesigning protocols and infrastructure to accommodate the significant differences in resource utilization and key sizes between traditional an d PQC algorithms. Due to the wide-ranging nature of these impacts, discussions of pro tocol changes are integrated throughout this document rather than being confined to a single section.
This document aims to provide general guidance to engineers working on cryptographic libraries, network security, and infrastructure development, where long-term security planning is crucial. The document covers topics such as selecting appropriate PQC al gorithms, understanding the differences between PQC key encapsulation mechanisms (KEM s) and traditional Diffie-Hellman and RSA style key exchanges, and provides insights into expected key, ciphertext, and signature sizes and processing time differences be tween PQC and traditional algorithms. Additionally, it discusses the potential threat to symmetric cryptography and hash functions from CRQCs. This document aims to provide general guidance to engineers working on cryptographic libraries, network security, and infrastructure development, where long-term security planning is crucial. The document covers topics such as selecting appropriate PQC al gorithms and understanding the differences between PQC Key Encapsulation Mechanisms ( KEMs) and traditional Diffie-Hellman (DH) and RSA-style key exchanges, and it provide s insights into expected differences in keys, ciphertext, signature sizes, and proces sing times between PQC and traditional algorithms. Additionally, it discusses the pot ential threat to symmetric cryptography and hash functions from CRQCs.
It is important to remember that asymmetric algorithms (also known as public key algo rithms) are largely used for secure communications between organizations or endpoints that may not have previously interacted, so a significant amount of coordination bet ween organizations, and within and between ecosystems needs to be taken into account. Such transitions are some of the most complicated in the tech industry and will requ ire staged migrations in which upgraded agents need to co-exist and communicate with non-upgraded agents at a scale never before undertaken. It is important to remember that asymmetric algorithms (also known as public key algo rithms) are largely used for secure communications between organizations or endpoints that may not have previously interacted, so a significant amount of coordination bet ween organizations, and within and between ecosystems, needs to be taken into account . Such transitions are some of the most complicated in the tech industry and will req uire staged migrations in which upgraded agents need to coexist and communicate with non-upgraded agents at a scale never before undertaken.
The National Security Agency (NSA) of the United States released an article on future PQC algorithm requirements for US national security systems {{CNSA2-0}} based on the need to protect against deployments of CRQCs in the future. The German Federal Offic e for Information Security (BSI) has also released a PQC migration and recommendation s document {{BSI-PQC}} which largely aligns with United States National Institute of Standards and Technology (NIST) and NSA guidance, but differs in aspects such as spec ific PQC algorithm profiles. The National Security Agency (NSA) of the United States released an article on future PQC algorithm requirements for US national security systems {{CNSA2-0}} based on the need to protect against deployments of CRQCs in the future. The German Federal Offic e for Information Security (BSI) has also released a PQC migration and recommendation s document {{BSI-PQC}} that largely aligns with United States National Institute of S tandards and Technology (NIST) and NSA guidance but differs in aspects such as specif ic PQC algorithm profiles.
CRQCs pose a threat to both symmetric and asymmetric cryptographic schemes. However, the threat to asymmetric cryptography is significantly greater due to Shor's {{Shors} } algorithm, which can break widely-used public key schemes like RSA and ECC. Symmetr ic cryptography and hash functions face a lower risk from Grover's {{Grovers}} algori thm, although the impact is less severe and can typically be mitigated by doubling ke y and digest lengths where the risk applies. It is crucial for the reader to understa nd that when the word "PQC" is mentioned in the document, it means asymmetric cryptog raphy (or public key cryptography), and not any symmetric algorithms based on stream ciphers, block ciphers, hash functions, MACs, etc., which are less vulnerable to quan tum computers. This document does not cover such topics as when traditional algorithm s might become vulnerable (for that, see documents such as {{QC-DNS}} and others). CRQCs pose a threat to both symmetric and asymmetric cryptographic schemes. However, the threat to asymmetric cryptography is significantly greater due to Shor's algorith m {{Shors}}, which can break widely used public key schemes like RSA and ECC. Symmetr ic cryptography and hash functions face a lower risk from Grover's algorithm {{Grover s}}, although the impact is less severe and can typically be mitigated by doubling ke y and digest lengths where the risk applies. It is crucial for the reader to understa nd that when "PQC" is mentioned in the document, it means asymmetric cryptography (or public key cryptography) and not any symmetric algorithms based on stream ciphers, b lock ciphers, hash functions, MACs, etc., which are less vulnerable to quantum comput ers. This document does not cover topics such as when traditional algorithms might be come vulnerable (for that, see documents such as {{QC-DNS}} and others).
This document does not cover unrelated technologies like quantum key distribution (QK D) or quantum key generation, which use quantum hardware to exploit quantum effects t o protect communications and generate keys, respectively. PQC is based on conventiona l math (not on quantum mechanics) and software and can be run on any general purpose computer. This document does not cover unrelated technologies like quantum key distribution (QK D) or quantum key generation, which use quantum hardware to exploit quantum effects t o protect communications and generate keys, respectively. PQC is based on conventiona l math (not on quantum mechanics) and software, and it can be run on any general-purp ose computer.
This document does not go into the deep mathematics or technical specification of the PQC algorithms, but rather provides an overview to engineers on the current threat l andscape and the relevant algorithms designed to help prevent those threats. Also, th e cryptographic and algorithmic guidance given in this document should be taken as no n-authoritative if it conflicts with emerging and evolving guidance from the IRTF's C rypto Forum Research Group (CFRG). This document does not go into the deep mathematics or technical specification of the PQC algorithms but rather provides an overview to engineers on the current threat la ndscape and the relevant algorithms designed to help prevent those threats. Also, the cryptographic and algorithmic guidance given in this document should be taken as non -authoritative if it conflicts with emerging and evolving guidance from the IRTF's Cr ypto Forum Research Group (CFRG).
# Terminology # Terminology
Quantum computer: A computer that performs computations using quantum-mechanical phen Quantum computer:
omena such as superposition and entanglement. : A computer that performs computations using quantum-mechanical phenomena such as su
perposition and entanglement.
Physical qubit: The basic physical unit in a quantum computer, which is prone to nois Physical qubit:
e and errors. : The basic physical unit in a quantum computer, which is prone to noise and errors.
Logical qubit: A fault-tolerant qubit constructed from multiple physical qubits using Logical qubit:
quantum error correction; it is the effective unit for reliable quantum computation. : A fault-tolerant qubit constructed from multiple physical qubits using quantum erro
r correction; it is the effective unit for reliable quantum computation.
Post-Quantum Cryptography (PQC): Cryptographic algorithms designed to be secure again Post-Quantum Cryptography (PQC):
st quantum and classical attacks. : Cryptographic algorithms designed to be secure against quantum and classical attack
s.
Cryptographically Relevant Quantum Computer (CRQC): A quantum computer with sufficien Cryptographically Relevant Quantum Computer (CRQC):
t logical qubits to break traditional asymmetric cryptographic algorithms (e.g., RSA : A quantum computer with sufficient logical qubits to break traditional asymmetric c
or ECC) within a practical timeframe. ryptographic algorithms (e.g., RSA or ECC) within a practical timeframe.
Public Key Cryptography (also called Asymmetric Cryptography): A class of cryptograph Public Key Cryptography (also called Asymmetric Cryptography):
ic algorithms in which separate keys are used for encryption and decryption, or for s : A class of cryptographic algorithms in which separate keys are used for encryption
igning and verification. Throughout this document, the terms Public Key Cryptography and decryption or for signing and verification. Throughout this document, the terms P
and Asymmetric Cryptography are used interchangeably. ublic Key Cryptography and Asymmetric Cryptography are used interchangeably.
There is ongoing discussion about whether to use the term "post-quantum", "quantum re ady", "quantum resistant", or "quantum secure", to describe algorithms that resist CR QCs, and a consensus has not yet been reached. NIST has coined the term "post-quantum " to refer to the algorithms that participated in its competition-like selection proc ess; in this context, the term can be interpreted to mean "the set of algorithms that are designed to still be relevant after quantum computers exist", and not a stateme nt about their security. "Quantum resistant" or "quantum secure" is obviously the goa l of these algorithms, however some people have raised concerns that labelling a clas s of algorithms as "quantum resistant" or "quantum secure" could lead to confusion if one or more of those algorithms are later found to be insecure or to not resist quan tum computers as much as theory predicted. "Quantum ready" is often used to refer to a solution -- device, appliance, or software stack -- that has reached maturity with regards to integration of these new cryptographic algorithms. That said, the authors recognize that there is great variability in how these terms are used. This document uses any of these terms interchangeably to refer to such algorithms. There is ongoing discussion about whether to use the term "post-quantum", "quantum re ady", "quantum resistant", or "quantum secure" to describe algorithms that resist CRQ Cs, and a consensus has not yet been reached. NIST has coined the term "post-quantum" to refer to the algorithms that participated in its competition-like selection proce ss; in this context, the term can be interpreted to mean "the set of algorithms that are designed to still be relevant after quantum computers exist" and not a statement about their security. "Quantum resistant" or "quantum secure" is obviously the goal of these algorithms; however, some people have raised concerns that labeling a class of algorithms as "quantum resistant" or "quantum secure" could lead to confusion if o ne or more of those algorithms are later found to be insecure or to not resist quantu m computers as much as theory predicted. "Quantum ready" is often used to refer to a solution -- device, appliance, or software stack -- that has reached maturity with re gard to integration of these new cryptographic algorithms. That said, the authors rec ognize that there is great variability in how these terms are used. This document use s these terms interchangeably to refer to such algorithms.
The terms "current," "state-of-the-art," and "ongoing," as used in this document, ref er to work, research, investigations, deployments, or developments that are applicabl e at the time of publication. In this document, the terms "current", "state-of-the-art", and "ongoing" refer to wor k, research, investigations, deployments, or developments that are applicable at the time of publication.
# Threat of CRQCs on Cryptography # Threat of CRQCs on Cryptography
When considering the security risks associated with the ability of a quantum computer to attack traditional cryptography, it is important to distinguish between the impac t on symmetric algorithms and public key ones. Dr. Peter Shor and Dr. Lov Grover deve loped two algorithms that changed the way the world thinks of security under the pres ence of a CRQC. When considering the security risks associated with the ability of a quantum computer to attack traditional cryptography, it is important to distinguish between the impac t on symmetric algorithms and public key ones. Dr. Peter Shor and Dr. Lov Grover deve loped two algorithms that changed the way the world thinks of security under the pres ence of a CRQC.
Quantum computers are, by their nature, hybrids of classical and quantum computationa l units. For example, Shor's algorithm consists of a combination of quantum and class ical computational steps. Thus, the term "quantum adversary" should be thought of as "quantum-enhanced adversary", meaning they have access to both classical and quantum computational techniques. Quantum computers are, by their nature, hybrids of classical and quantum computationa l units. For example, Shor's algorithm consists of a combination of quantum and class ical computational steps. Thus, the term "quantum adversary" should be thought of as "quantum-enhanced adversary", meaning they have access to both classical and quantum computational techniques.
Despite that large-scale quantum computers do not yet exist to experiment on, the the oretical properties of quantum computation are very well understood. This allows eng ineers and researchers to reason about the upper limits of quantum-enhanced computati on, and indeed to design cryptographic algorithms that are resistant to any conceivab le form of quantum cryptanalysis. Although large-scale quantum computers do not yet exist to experiment on, the theoret ical properties of quantum computation are very well understood. This allows enginee rs and researchers to reason about the upper limits of quantum-enhanced computation a nd to design cryptographic algorithms that are resistant to any conceivable form of q uantum cryptanalysis.
## Symmetric Cryptography {#symmetric} ## Symmetric Cryptography {#symmetric}
For unstructured data such as symmetric encrypted data or cryptographic hashes, altho ugh CRQCs can search for specific solutions across all possible input combinations (e .g., Grover's algorithm), no quantum algorithm is known to break the underlying secur ity properties of these classes of algorithms. Symmetric-key cryptography, which incl udes keyed primitives such as block ciphers (e.g., AES) and message authentication me chanisms (e.g., HMAC-SHA256), relies on secret keys shared between the sender and rec eiver and remains secure even in a post-quantum world. Symmetric cryptography also in cludes hash functions (e.g., SHA-256) that are used for secure message digesting with out any shared key material. HMAC is a specific construction that utilizes a cryptogr aphic hash function and a secret key shared between the sender and receiver to produc e a message authentication code. For unstructured data such as symmetric encrypted data or cryptographic hashes, altho ugh CRQCs can search for specific solutions across all possible input combinations (e .g., Grover's algorithm), no quantum algorithm is known to break the underlying secur ity properties of these classes of algorithms. Symmetric-key cryptography, which incl udes keyed primitives such as block ciphers (e.g., AES) and message authentication me chanisms (e.g., HMAC-SHA256), relies on secret keys shared between the sender and rec eiver and remains secure even in a post-quantum world. Symmetric cryptography also in cludes hash functions (e.g., SHA-256) that are used for secure message digesting with out any shared key material. Hashed Message Authentication Code (HMAC) is a specific construction that utilizes a cryptographic hash function and a secret key shared betw een the sender and receiver to produce a message authentication code.
Grover's algorithm is a quantum search algorithm that provides a theoretical quadrati c speedup for searching an unstructured database, compared to traditional search algo rithms. Grover's algorithm is a quantum search algorithm that provides a theoretical quadrati c speedup for searching an unstructured database, compared to traditional search algo rithms.
This has led to the common misconception that symmetric key lengths need to be double d for quantum security. When you consider the mapping of hash values to their corresp onding hash inputs (also known as pre-image), or of ciphertext blocks to the correspo nding plaintext blocks, as an unstructured database, then Grover’s algorithm theoreti cally requires doubling the key sizes of the symmetric algorithms that are currently deployed at the time of publication to counter the quadratic speedup and maintain cur rent security level. This is because Grover’s algorithm reduces the amount of operati ons to break 128-bit symmetric cryptography to 2^{64} quantum operations, which might sound computationally feasible. However, quantum operations are fundamentally differ ent from classical ones as 2^{64} classical operations can be efficiently parallelize d, 2^{64} quantum operations must be performed serially, making them infeasible on pr actical quantum computers. This has led to the common misconception that symmetric key lengths need to be double d for quantum security. When you consider the mapping of hash values to their corresp onding hash inputs (also known as pre-image) or of ciphertext blocks to the correspon ding plaintext blocks as an unstructured database, then Grover's algorithm theoretica lly requires doubling the key sizes of the symmetric algorithms that are currently de ployed at the time of publication to counter the quadratic speedup and maintain the c urrent security level. This is because Grover's algorithm reduces the amount of opera tions to break 128-bit symmetric cryptography to 2^{64} quantum operations, which mig ht sound computationally feasible. However, quantum operations are fundamentally diff erent from classical ones, as 2^{64} classical operations can be efficiently parallel ized but 2^{64} quantum operations must be performed serially, making them infeasible on practical quantum computers.
Grover's algorithm is highly non-parallelizable and even if one deploys 2^c computati onal units in parallel to brute-force a key using Grover's algorithm, it will complet e in time proportional to 2^{(128−c)/2}, or, put simply, using 256 quantum computers will only reduce runtime by a factor of 16, 1024 quantum computers will only reduce r untime by a factor of 32 and so forth (see {{NIST}} and {{Cloudflare}}). Due to this inherent limitation, the general expert consensus is that AES-128 (Advanced Encryptio n Standard) remains secure in practice, and key sizes do not necessarily need to be d oubled. Grover's algorithm is highly non-parallelizable and even if one deploys 2^c computati onal units in parallel to brute-force a key using Grover's algorithm, it will complet e in time proportional to 2^{(128-c)/2}, or, put simply, using 256 quantum computers will only reduce runtime by a factor of 16, 1024 quantum computers will only reduce r untime by a factor of 32, and so forth (see {{NIST}} and {{Cloudflare}}). Due to this inherent limitation, the general expert consensus is that AES-128 remains secure in practice and key sizes do not necessarily need to be doubled.
It would be natural to ask whether future research will develop a superior algorithm that could outperform Grover's algorithm in the general case. However, Christof Zalka has shown that Grover's algorithm achieves the best possible complexity for this typ e of search, meaning no significantly faster quantum approach is expected {{Grover-se arch}} It would be natural to ask whether future research will develop a superior algorithm that could outperform Grover's algorithm in the general case. However, Christof Zalka has shown that Grover's algorithm achieves the best possible complexity for this typ e of search, meaning no significantly faster quantum approach is expected {{Grover-Se arch}}.
Finally, in their evaluation criteria for PQC, NIST is assessing the security levels <!-- [rfced] "CNSA 2.0" is a suite of algorithms from the NSA, not an
of proposed post-quantum algorithms by comparing them against the equivalent traditio organization. The organization is the National Security Agency (NSA). May we
nal and quantum security of AES-128, AES-192, and AES-256. This indicates that NIST i update the sentence as follows to clarify?
s confident in the stable security properties of AES, even in the presence of both tr
aditional and quantum attacks. As a result, 128-bit algorithms can be considered quan Current:
tum-safe for the foreseeable future. However, for compliance purposes, some organizat However, for compliance purposes, some organizations, such as the French
ions, such as the French National Agency for the Security of Information Systems (ANS National Agency for the Security of Information Systems (ANSSI) {{ANSSI}} and
SI) {{ANSSI}} and CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) {{CNSA2 CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) {{CNSA2-0}},
-0}}, recommend the use of AES-256. recommend the use of AES-256.
Perhaps:
However, for compliance purposes, some organizations, such as the French
National Agency for the Security of Information Systems (ANSSI) {{ANSSI}} and the
National Security Agency (NSA) {{CNSA2-0}}, recommend the use of AES-256.
-->
Finally, in their evaluation criteria for PQC, NIST is assessing the security levels
of proposed post-quantum algorithms by comparing them against the equivalent traditio
nal and quantum security of AES-128, AES-192, and AES-256. This indicates that NIST i
s confident in the stable security properties of AES, even in the presence of both tr
aditional and quantum attacks. As a result, 128-bit algorithms can be considered quan
tum-safe for the foreseeable future. However, for compliance purposes, some organizat
ions, such as the French National Agency for the Security of Information Systems (ANS
SI) {{ANSSI}} and Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) {{CNSA2
-0}}, recommend the use of AES-256.
0}}, recommend the use of AES-256.
## Asymmetric Cryptography ## Asymmetric Cryptography
“Shor’s algorithm” efficiently solves the integer factorization problem (and the rela ted discrete logarithm problem), which underpin the foundations of the vast majority of public key cryptography that the world uses today. This implies that, if a CRQC is developed, today’s public key algorithms (e.g., RSA, Diffie-Hellman and elliptic cur ve cryptography, as well as less commonly-used variants such as ElGamal {{RFC6090}} a nd Schnorr signatures {{RFC8235}}) and protocols would need to be replaced by algorit hms and protocols that can offer cryptanalytic resistance against CRQCs. Note that Sh or’s algorithm cannot run solely on a classical computer, it requires a CRQC. "Shor's algorithm" efficiently solves the integer factorization problem (and the rela ted discrete logarithm problem), which underpin the foundations of the vast majority of public key cryptography that the world uses today. This implies that, if a CRQC is developed, today's public key algorithms (e.g., RSA, Diffie-Hellman, and ECC, as wel l as less commonly used variants such as ElGamal {{RFC6090}} and Schnorr signatures { {RFC8235}}) and protocols would need to be replaced by algorithms and protocols that can offer cryptanalytic resistance against CRQCs. Note that Shor's algorithm cannot r un solely on a classical computer; it requires a CRQC.
For example, studies show that, if a CRQC existed, it could break RSA-2048 in hours o r even seconds depending on assumptions about error correction {{RSAShor}}{{RSA8HRS}} {{RSA10SC}}. While such machines are purely theoretical at the time of writing, this illustrates the eventual vulnerability of RSA to CRQCs. For example, studies show that, if a CRQC existed, it could break RSA-2048 in hours o r even seconds depending on assumptions about error correction {{RSAShor}} {{RSA8HRS} } {{RSA10SC}}. While such machines are purely theoretical at the time of writing, thi s illustrates the eventual vulnerability of RSA to CRQCs.
For structured data such as public keys and signatures, CRQCs can fully solve the und erlying hard problems used in traditional cryptography (see Shor's algorithm). Becaus e an increase in the size of the key-pair would not provide a secure solution (short of RSA keys that are many gigabytes in size {{PQRSA}}), a complete replacement of the algorithm is needed. Therefore, post-quantum public key cryptography must rely on pr oblems that are different from the ones used in traditional public key cryptography ( i.e., the integer factorization problem, the finite-field discrete logarithm problem, and the elliptic-curve discrete logarithm problem). For structured data such as public keys and signatures, CRQCs can fully solve the und erlying hard problems used in traditional cryptography (see Shor's algorithm). Becaus e an increase in the size of the key pair would not provide a secure solution (short of RSA keys that are many gigabytes in size {{PQRSA}}), a complete replacement of the algorithm is needed. Therefore, post-quantum public key cryptography must rely on pr oblems that are different from the ones used in traditional public key cryptography ( i.e., the integer factorization problem, the finite-field discrete logarithm problem, and the elliptic-curve discrete logarithm problem).
## Quantum Side-channel Attacks ## Quantum Side-Channel Attacks
Cryptographic side-channel attacks exploit physical implementations, such as timing, power consumption, or electromagnetic leakage to recover secret keys. Cryptographic side-channel attacks exploit physical implementations (such as timing, power consumption, or electromagnetic leakage) to recover secret keys.
The field of cryptographic side-channel attacks potentially stands to gain a boost in attacker power once cryptanalytic techniques can be enhanced with quantum computatio n techniques {{QuantSide}}. While a full discussion of quantum side-channel technique s is beyond the scope of this document, implementers of cryptographic hardware should be aware that current best-practices for side-channel resistance may not be sufficie nt against quantum adversaries. The field of cryptographic side-channel attacks potentially stands to gain a boost in attacker power once cryptanalytic techniques can be enhanced with quantum computatio n techniques {{QuantSide}}. While a full discussion of quantum side-channel technique s is beyond the scope of this document, implementers of cryptographic hardware should be aware that current best practices for side-channel resistance may not be sufficie nt against quantum adversaries.
# Traditional Cryptographic Primitives that Could Be Replaced by PQC <!-- [rfced] We slightly rephrased the following to avoid repetition of "hence"
(i.e., made new sentence and replaced the first "hence" with "Because of
this"). Please review and let us know any concerns.
Any asymmetric cryptographic algorithm based on integer factorization, finite field d Original:
iscrete logarithms, or elliptic curve discrete logarithms will be vulnerable to attac Similar to key agreement, signatures also depend on a public-private
ks using Shor's algorithm on a CRQC. This document focuses on the principal functions key pair based on the same mathematics as for key agreement and key transport,
of asymmetric cryptography: and hence a break in existing public key cryptography will also affect
traditional digital signatures, hence the importance of developing
post-quantum digital signatures.
* Key agreement and key transport: Key agreement schemes, typically referred to as Di Updated:
ffie-Hellman (DH) or Elliptic Curve Diffie-Hellman (ECDH), as well as key transport, Similar to key agreement, signatures also depend on a public-private
typically using RSA encryption, are used to establish a shared cryptographic key for key pair based on the same mathematics as for key agreement and key transport.
secure communication. They are one of the mechanisms that can be replaced by PQC, as Because of this, a break in existing public key cryptography will also affect
they are based on existing public key cryptography and are therefore vulnerable to Sh traditional digital signatures, hence the importance of developing
or's algorithm. A CRQC can employ Shor's algorithm to efficiently find the prime fact post-quantum digital signatures.
ors of a large public key (in the case of RSA), which in turn can be exploited to der -->
ive the private key. In the case of Diffie-Hellman, a CRQC has the potential to calcu
late the discrete logarithm of the (short or long-term) Diffie-Hellman public key. Th
is, in turn, would reveal the secret required to derive the symmetric encryption key.
* Digital signatures: Digital signature schemes are used to authenticate the identity of a sender, detect unauthorized modifications to data, and underpin trust in a syst em. Similar to key agreement, signatures also depend on a public-private key pair bas ed on the same mathematics as for key agreement and key transport, and hence a break in existing public key cryptography will also affect traditional digital signatures, hence the importance of developing post-quantum digital signatures. # Traditional Cryptographic Primitives That Could Be Replaced by PQC
* BBS signatures: BBS (Boneh-Boyen-Shacham) signatures are a privacy-preserving signa ture scheme that offers zero-knowledge proof-like properties by allowing selective di sclosure of specific signed attributes without revealing the entire set of signed dat a. The security of BBS signatures relies on the hardness of the discrete logarithm pr oblem, making them vulnerable to Shor's algorithm. A CRQC can break the data authenti city security property of BBS but not the data confidentiality (Section 6.9 of {{?I-D .irtf-cfrg-bbs-signatures}}). Any asymmetric cryptographic algorithm based on integer factorization, finite field d iscrete logarithms, or elliptic-curve discrete logarithms will be vulnerable to attac ks using Shor's algorithm on a CRQC. This document focuses on the principal functions of asymmetric cryptography:
* Content encryption: Content encryption typically refers to the encryption of the da Key agreement and key transport:
ta using symmetric key algorithms, such as AES, to ensure confidentiality. The threat : Key agreement schemes, typically referred to as Diffie-Hellman (DH) or Elliptic Cur
to symmetric cryptography is discussed in {{symmetric}}. ve Diffie-Hellman (ECDH), as well as key transport, typically using RSA encryption, a
re used to establish a shared cryptographic key for secure communication. They are on
e of the mechanisms that can be replaced by PQC, as they are based on existing public
key cryptography and are therefore vulnerable to Shor's algorithm. A CRQC can employ
Shor's algorithm to efficiently find the prime factors of a large public key (in the
case of RSA), which, in turn, can be exploited to derive the private key. In the cas
e of DH, a CRQC has the potential to calculate the discrete logarithm of the (short-
or long-term) DH public key. This, in turn, would reveal the secret required to deriv
e the symmetric encryption key.
Digital signatures:
: Digital signature schemes are used to authenticate the identity of a sender, detect
unauthorized modifications to data, and underpin trust in a system. Similar to key a
greement, signatures also depend on a public-private key pair based on the same mathe
matics as for key agreement and key transport. Because of this, a break in existing p
ublic key cryptography will also affect traditional digital signatures, hence the imp
ortance of developing post-quantum digital signatures.
Boneh-Boyen-Shacham (BBS) signatures:
: BBS signatures are a privacy-preserving signature scheme that offers zero-knowledge
proof-like properties by allowing selective disclosure of specific signed attributes
without revealing the entire set of signed data. The security of BBS signatures reli
es on the hardness of the discrete logarithm problem, making them vulnerable to Shor'
s algorithm. A CRQC can break the data authenticity security property of BBS but not
the data confidentiality ({{Section 6.9 of I-D.irtf-cfrg-bbs-signatures}}).
Content encryption:
: Content encryption typically refers to the encryption of the data using symmetric k
ey algorithms, such as AES, to ensure confidentiality. The threat to symmetric crypto
graphy is discussed in {{symmetric}}.
# NIST PQC Algorithms # NIST PQC Algorithms
At time of writing, NIST have standardized three PQC algorithms, with more expected t o be standardised in the future ({{NISTFINAL}}). These algorithms are not necessarily drop-in replacements for traditional asymmetric cryptographic algorithms. For instan ce, RSA {{RSA}} and ECC {{RFC6090}} can be used as both a key encapsulation method (K EM) and as a signature scheme, whereas there is currently no post-quantum algorithm t hat can perform both functions. When upgrading protocols, it is important to replace the existing use of traditional algorithms with either a PQC KEM or a PQC signature m ethod, depending on how the traditional algorithm was previously being used. Addition ally, KEMs, as described in {{KEMs}}, present a different API than either key agreeme nt or key transport primitives. As a result, they may require protocol-level or appli cation-level changes in order to be incorporated. At the time of writing, NIST has standardized three PQC algorithms, with more expecte d to be standardized in the future (see {{NISTFINAL}}). These algorithms are not nece ssarily drop-in replacements for traditional asymmetric cryptographic algorithms. For instance, RSA {{RSA}} and ECC {{RFC6090}} can be used as both a key encapsulation me thod (KEM) and a signature scheme, whereas there is currently no post-quantum algori thm that can perform both functions. When upgrading protocols, it is important to rep lace the existing use of traditional algorithms with either a PQC KEM or a PQC signat ure method, depending on how the traditional algorithm was previously being used. Add itionally, KEMs, as described in {{KEMs}}, present a different API than either key ag reement or key transport primitives. As a result, they may require protocol-level or application-level changes in order to be incorporated.
## NIST Candidates Selected for Standardization ## NIST Candidates Selected for Standardization
<!-- [rfced] In Sections 5.1.1, 5.1.2, and 6.1, may we update the lists to
better indicate the term being defined? We suggest placing the term rather
than the citation before the colon. See the suggested text in a), b), and c)
below.
We also have some additional questions regarding Section 5.1.2:
- How should "FN" in "FN-DSA" be expanded? Perhaps as "Fast-Fourier Transform
over NTRU-Lattice-Based Digital Signature Algorithm"?
- The FN-DSA entry includes pointers to Sections 8.1 and 10.2, but ML-DSA and
SLH-DSA are also mentioned in those setions. Should the pointers to Sections
8.1 and 10.2 apply to all entries?
- We do not see "FN-DSA" mentioned in the URL listed for [FN-DSA]. Please
review. Also, should this reference be to FIPS 206, or should the relationship
between FIPS 206 and Fast Fourier/Falcon be explained for the reader? It seems
that FIPS 206 is still in draft form.
a) Section 5.1.1
Original
* [ML-KEM]: Module-Lattice-based Key-Encapsulation Mechanism
Standard (FIPS-203).
* [HQC]: Hamming Quasi-Cyclic coding algorithm which is based on the
hardness of the syndrome decoding problem for quasi-cyclic
concatenated Reed-Muller and Reed-Solomon (RMRS) codes in the
Hamming metric. Reed-Muller (RM) codes are a class of block
error-correcting codes commonly used in wireless and deep-space
communications, while Reed-Solomon (RS) codes are widely used to
detect and correct multiple-bit errors. HQC has been selected as
part of the NIST post-quantum cryptography project but has not yet
been standardized.
Perhaps:
ML-KEM: Module-Lattice-Based Key Encapsulation Mechanism. See
FIPS 203 [ML-DSA].
HQC: Hamming Quasi-Cyclic. See [HQC]. The coding algorithm based on the
hardness of the syndrome decoding problem for quasi-cyclic
concatenated Reed-Muller and Reed-Solomon (RMRS) codes in the
Hamming metric. Reed-Muller (RM) codes are a class of block
error-correcting codes commonly used in wireless and deep-space
communications, while Reed-Solomon (RS) codes are widely used to
detect and correct multiple-bit errors. HQC has been selected as
part of the NIST post-quantum cryptography project but has not yet
been standardized.
b) Section 5.1.2
Original:
* [ML-DSA]: Module-Lattice-Based Digital Signature Standard (FIPS-
204).
* [SLH-DSA]: Stateless Hash-Based Digital Signature (FIPS-205).
* [FN-DSA]: FN-DSA is a lattice signature scheme (FIPS-206)
(Section 8.1 and Section 10.2).
Perhaps:
ML-DSA: Module-Lattice-Based Digital Signature Algorithm. See FIPS
204 [ML-DSA].
SLH-DSA: Stateless Hash-Based Digital Signature Algorithm. See FIPS
205 [SLH-DSA].
FN-DSA: Fast-Fourier Transform over NTRU-Lattice-Based Digital
Signature Algorithm. See FIPS 206 [FN-DSA].
For more information about these, see Sections 8.1 and 10.2.
c) Section 6.1
Original:
* [FrodoKEM]: Key Encapsulation mechanism based on the hardness of
learning with errors in algebraically unstructured lattices.
* [ClassicMcEliece]: Based on the hardness of syndrome decoding of
Goppa codes. Goppa codes are a class of error-correcting codes
that can correct a certain number of errors in a transmitted
message. The decoding problem involves recovering the original
message from the received noisy codeword.
* [NTRU]: Key encapsulation mechanism based on the "N-th degree
Truncated polynomial Ring Units" (NTRU) lattices. Variants
include Streamlined NTRU Prime (sntrup761), which is leveraged for
use in SSH [I-D.ietf-sshm-ntruprime-ssh].
Perhaps:
FrodoKEM: KEM based on the hardness of learning with errors in
algebraically unstructured lattices. See [FrodoKEM].
Classic McEliece: KEM based on the hardness of syndrome decoding of
Goppa codes. Goppa codes are a class of error-correcting codes
that can correct a certain number of errors in a transmitted
message. The decoding problem involves recovering the original
message from the received noisy codeword. See [ClassicMcEliece].
NTRU: KEM based on the "N-th degree Truncated polynomial Ring
Units" (NTRU) lattices. Variants include Streamlined NTRU Prime
(sntrup761), which is leveraged for use in SSH [RFC9941]. See [NTRU].
-->
### PQC Key Encapsulation Mechanisms (KEMs) ### PQC Key Encapsulation Mechanisms (KEMs)
* {{ML-KEM}}: Module-Lattice-based Key-Encapsulation Mechanism Standard (FIPS-203). {{ML-KEM}}:
* {{HQC}}: Hamming Quasi-Cyclic coding algorithm which is based on the hardness of th : Module-Lattice-Based Key-Encapsulation Mechanism Standard (FIPS 203).
e syndrome decoding problem for quasi-cyclic concatenated Reed-Muller and Reed-Solomo
n (RMRS) codes in the Hamming metric. Reed-Muller (RM) codes are a class of block err {{HQC}}:
or-correcting codes commonly used in wireless and deep-space communications, while Re : Hamming Quasi-Cyclic coding algorithm, which is based on the hardness of the syndro
ed-Solomon (RS) codes are widely used to detect and correct multiple-bit errors. HQC me decoding problem for quasi-cyclic concatenated Reed-Muller and Reed-Solomon (RMRS)
has been selected as part of the NIST post-quantum cryptography project but has not y codes in the Hamming metric. Reed-Muller (RM) codes are a class of block error-corre
et been standardized. cting codes commonly used in wireless and deep-space communications, while Reed-Solom
on (RS) codes are widely used to detect and correct multiple-bit errors. HQC has been
selected as part of the NIST post-quantum cryptography project but has not yet been
standardized.
### PQC Signatures ### PQC Signatures
* {{ML-DSA}}: Module-Lattice-Based Digital Signature Standard (FIPS-204). {{ML-DSA}}:
* {{SLH-DSA}}: Stateless Hash-Based Digital Signature (FIPS-205). : Module-Lattice-Based Digital Signature Standard (FIPS 204).
* {{FN-DSA}}: FN-DSA is a lattice signature scheme (FIPS-206) ({{lattice-based}} and
{{sig-scheme}}). {{SLH-DSA}}:
: Stateless Hash-Based Digital Signature (FIPS 205).
{{FN-DSA}}:
: FN-DSA is a lattice signature scheme (FIPS 206) (see Sections {{lattice-based}}{: f
ormat="counter"} and {{sig-scheme}}{: format="counter"}).
# ISO Candidates Selected for Standardization # ISO Candidates Selected for Standardization
At the time of writing, ISO has selected three PQC KEM algorithms as candidates for s tandardization, which are mentioned in the following subsection. At the time of writing, ISO has selected three PQC KEM algorithms as candidates for s tandardization; these are mentioned in the following subsection.
## PQC Key Encapsulation Mechanisms (KEMs) ## PQC Key Encapsulation Mechanisms (KEMs)
* {{FrodoKEM}}: Key Encapsulation mechanism based on the hardness of learning with er
rors in algebraically unstructured lattices. {{FrodoKEM}}:
* {{ClassicMcEliece}}: Based on the hardness of syndrome decoding of Goppa codes. Gop : KEM based on the hardness of learning with errors in algebraically unstructured lat
pa codes are a class of error-correcting codes that can correct a certain number of e tices.
rrors in a transmitted message. The decoding problem involves recovering the original
message from the received noisy codeword. {{ClassicMcEliece}}:
* {{NTRU}}: Key encapsulation mechanism based on the "N-th degree Truncated polynomia : KEM based on the hardness of syndrome decoding of Goppa codes. Goppa codes are a cl
l Ring Units" (NTRU) lattices. Variants include Streamlined NTRU Prime (sntrup761), w ass of error-correcting codes that can correct a certain number of errors in a transm
hich is leveraged for use in SSH {{?I-D.ietf-sshm-ntruprime-ssh}}. itted message. The decoding problem involves recovering the original message from the
received noisy codeword.
{{NTRU}}:
: KEM based on the "N-th degree Truncated polynomial Ring Units" (NTRU) lattices. Var
iants include Streamlined NTRU Prime (sntrup761), which is leveraged for use in SSH {
{?RFC9941}}.
# Timeline for Transition {#timeline} # Timeline for Transition {#timeline}
The timeline, and driving motivation for transition differs slightly between data con fidentiality (e.g., encryption) and data authentication (e.g., signature) use-cases. The timeline and driving motivation for transition differ slightly between data confi dentiality (e.g., encryption) and data authentication (e.g., signature) use cases.
For data confidentiality, one is concerned with the so-called "harvest now, decrypt l ater" (HNDL) attack where a malicious actor with adequate resources can launch an att ack to store sensitive encrypted data today that they hope to decrypt once a CRQC is available. This implies that, every day, sensitive encrypted data is susceptible to t he attack by not implementing quantum-safe strategies, as it corresponds to data poss ibly being deciphered in the future. For data confidentiality, one is concerned with the so-called "harvest now, decrypt l ater" (HNDL) attack where a malicious actor with adequate resources can launch an att ack to store sensitive encrypted data today that they hope to decrypt once a CRQC is available. This implies that, every day, sensitive encrypted data is susceptible to t he attack by not implementing quantum-safe strategies, as it corresponds to data poss ibly being deciphered in the future.
For authentication, it is often the case that signatures have a very short lifetime b etween signing and verifying (such as during a TLS handshake) but some authentication use-cases do require long lifetimes, such as signing firmware or software that will be active for decades, signing legal documents, or signing certificates that will be embedded into hardware devices such as smartcards. Even for short-lived signatures us e cases, the infrastructure often relies on long-lived root keys which can be difficu lt to update or replace on in-field devices. For authentication, it is often the case that signatures have a very short lifetime b etween signing and verifying (such as during a TLS handshake), but some authenticatio n use cases do require long lifetimes, such as signing firmware or software that will be active for decades, signing legal documents, or signing certificates that will be embedded into hardware devices such as smart cards. Even for short-lived signature u se cases, the infrastructure often relies on long-lived root keys, which can be diffi cult to update or replace on in-field devices.
~~~~~ aasvg ~~~~ aasvg
+------------------------+----------------------------+ +------------------------+----------------------------+
| | | | | |
| y | x | | y | x |
+------------------------+----------+-----------------+ +------------------------+----------+-----------------+
| | <---------------> | | <--------------->
| z | Security gap | z | Security gap
+-----------------------------------+ +-----------------------------------+
~~~~~ ~~~~
{: #Mosca title="Mosca model"} {: #Mosca title="Mosca Model"}
These challenges are illustrated nicely by the so-called Mosca model discussed in {{T hreat-Report}}. In {{Mosca}}, "x" denotes the time that systems and data need to rema in secure, "y" the number of years to fully migrate to a PQC infrastructure, and "z" the time until a CRQC that can break current cryptography is available. The model ass umes either that encrypted data can be intercepted and stored before the migration is completed in "y" years, or that signatures will still be relied upon for "x" years a fter their creation. This data remains vulnerable for the complete "x" years of their lifetime, thus the sum "x+y" gives us an estimate of the full timeframe that data re main insecure. The model essentially asks how one is preparing IT systems during thos e "y" years (in other words, how one can minimize those "y" years) to minimize the tr ansition phase to a PQC infrastructure and hence minimize the risks of data being exp osed in the future. These challenges are illustrated nicely by the so-called Mosca model discussed in {{T hreat-Report}}. In {{Mosca}}, "x" denotes the time that systems and data need to rema in secure, "y" the number of years to fully migrate to a PQC infrastructure, and "z" the time until a CRQC that can break current cryptography is available. The model ass umes either that encrypted data can be intercepted and stored before the migration is completed in "y" years, or that signatures will still be relied upon for "x" years a fter their creation. This data remains vulnerable for the complete "x" years of their lifetime; thus, the sum "x+y" gives us an estimate of the full timeframe that data r emains insecure. The model essentially asks how one is preparing IT systems during th ose "y" years (in other words, how one can minimize those "y" years) to minimize the transition phase to a PQC infrastructure and hence minimize the risks of data being e xposed in the future.
Finally, other factors that could accelerate the introduction of a CRQC should not be under-estimated, like for example faster-than-expected advances in quantum computing and more efficient versions of Shor’s algorithm requiring fewer qubits. Innovation o ften comes in waves, so it is to the industry’s benefit to remain vigilant and prepar e as early as possible. Bear in mind also that while the industry tracks advances fro m public research institutions such as universities and companies that publish their results, there is also a great deal of large-budget quantum research being conducted privately by various national interests. Therefore, the true state of quantum compute r advancement is likely several years ahead of the publicly available research at the date this is published. Finally, other factors that could accelerate the introduction of a CRQC should not be underestimated, for example, faster-than-expected advances in quantum computing and more efficient versions of Shor's algorithm requiring fewer qubits. Innovation often comes in waves, so it is to the industry's benefit to remain vigilant and prepare as early as possible. Also, bear in mind that while the industry tracks advances from pu blic research institutions such as universities and companies that publish their resu lts, there is also a great deal of large-budget quantum research being conducted priv ately by various national interests. Therefore, the true state of quantum computer ad vancement is likely several years ahead of the publicly available research at the dat e this document is published.
Organizations should also consider carefully and honestly what their migration timeli ne "y" actually is. If you think only of the time between receiving a patch from your technology vendor, and rolling that patch out, then "y" might seem as short as a few weeks. However, this represents the minority of migration cases; more often, a PQC m igration will involve at least some amount of hardware replacement. For example, perf ormance-sensitive applications will need CPUs with PQC hardware acceleration. Securit y-sensitive applications will need PQC TPMs, TEEs, Secure Enclaves, and other cryptog raphic co-processors. Smartcard applications will require replacement of the cards as well as of the readers which can come in many form-factors: tap-for-entry door and t urnstile readers, PIN pad machines, laptops with built-in smartcard readers, and many others. Organizations should also carefully and honestly consider what their migration timeli ne "y" actually is. If you only think of the time between receiving a patch from your technology vendor and rolling that patch out, then "y" might seem as short as a few weeks. However, this represents the minority of migration cases; more often, a PQC mi gration will involve at least some amount of hardware replacement. For example, perfo rmance-sensitive applications will need CPUs with PQC hardware acceleration. Security -sensitive applications will need PQC TPMs, Trusted Execution Environments (TEEs), se cure enclaves, and other cryptographic co-processors. Smart card applications will re quire replacement of the cards and readers. The readers can come in many form factors : tap-for-entry door and turnstile readers, PIN pad machines, laptops with built-in s mart card readers, and many others.
Included in "y" is not only the deployment time, but also preparation time: integrati on, testing, auditing, and re-certification of cryptographic environments. Consider a lso upstream effects that contribute to "y", including lead-times for your vendors to produce PQC-ready products, which may itself include auditing and certification dela ys, time for regulating bodies to adopt PQC policies, time for auditors to become fam iliar with the new requirements, etc. If you measure the full migration time "y" from when your vendors begin implementing PQC functionality, to when you switch off your last non-PQC-capable device, then "y" can be quite long; likely measured in years for even most moderately-sized organizations, this long tail should not discourage early action. Included in "y" is not only the deployment time but also the preparation time: integr ation, testing, auditing, and recertification of cryptographic environments. Also con sider upstream effects that contribute to "y", including lead times for vendors to pr oduce PQC-ready products, which may itself include auditing and certification delays, time for regulating bodies to adopt PQC policies, time for auditors to become famili ar with the new requirements, etc. If you measure the full migration time "y" from wh en your vendors begin implementing PQC functionality to when you switch off your last non-PQC-capable device, then "y" can be quite long, likely measured in years for eve n most moderately sized organizations. This long tail should not discourage early act ion.
Organizations responsible for protecting long-lived sensitive data or operating criti cal infrastructure will need to begin transitioning immediately, particularly in scen arios where data is vulnerable to HNDL attacks. PQ/T {{PQT}} or PQ key exchange is re latively self-contained, typically requiring changes only to the cryptographic librar y (e.g., OpenSSL). In contrast, migrating to post-quantum or PQ/T digital signatures involves broader ecosystem changes, including updates to certificates, CAs, Certifica te Management Protocols, HSMs, and trust anchors. Organizations responsible for protecting long-lived sensitive data or operating criti cal infrastructure will need to begin transitioning immediately, particularly in scen arios where data is vulnerable to HNDL attacks. Post-quantum and traditional (PQ/T) { {PQT}} or PQ key exchange is relatively self-contained, typically requiring changes o nly to the cryptographic library (e.g., OpenSSL). In contrast, migrating to post-quan tum or PQ/T digital signatures involves broader ecosystem changes, including updates to certificates, certificate authorities (CAs), Certificate Management Protocols, HSM s, and trust anchors.
Starting early with hybrid key exchange deployments allows organizations to gain oper ational experience, while prototyping and planning for PQ/T or PQ digital signature i ntegration helps identify ecosystem-wide impacts early. This phased approach reduces long-term migration risks and ensures readiness for more complex updates. Starting early with hybrid key exchange deployments allows organizations to gain oper ational experience, while prototyping and planning for PQ/T or PQ digital signature i ntegration helps identify ecosystem-wide impacts early. This phased approach reduces long-term migration risks and ensures readiness for more complex updates.
# PQC Categories # PQC Categories
The post-quantum cryptographic schemes standardized by NIST can be categorized into t hree main groups: lattice-based, hash-based, and code-based. Other approaches, such a s isogeny-based, multivariate-based, and MPC-in-the-Head-based cryptography, are also being explored in research and standardization efforts. In addition, NIST issued a c all for additional digital signature proposals to expand the set of post-quantum sign atures under evaluation {{AddSig}}. The post-quantum cryptographic schemes standardized by NIST can be categorized into t hree main groups: lattice-based, hash-based, and code-based. Other approaches, such a s isogeny-based, multivariate-based, and MPC-in-the-Head-based cryptography, are also being explored in research and standardization efforts. In addition, NIST issued a c all for additional digital signature proposals to expand the set of post-quantum sign atures under evaluation {{AddSig}}.
## Lattice-Based Public Key Cryptography {#lattice-based} ## Lattice-Based Public Key Cryptography {#lattice-based}
Lattice-based public key cryptography leverages the simple construction of lattices ( i.e., a regular collection of points in a Euclidean space that are evenly spaced) to create "trapdoor" problems. These problems are efficient to compute if you possess th e secret information but challenging to compute otherwise. Examples of such problems include the shortest vector, closest vector, short integer solution, learning with er rors, module learning with errors, and learning with rounding problems. All of these problems feature strong proofs for worst-to-average case reduction, effectively relat ing the hardness of the average case to the worst case. Lattice-based public key cryptography leverages the simple construction of lattices ( i.e., a regular collection of points in a Euclidean space that are evenly spaced) to create "trapdoor" problems. These problems are efficient to compute if you possess th e secret information but challenging to compute otherwise. Examples of such problems include the shortest vector, closest vector, short integer solution, learning with er rors, module learning with errors, and learning with rounding problems. All of these problems feature strong proofs for worst-to-average case reduction, effectively relat ing the hardness of the average case to the worst case.
Lattice-based public keys and signatures are larger than those of classical schemes s uch as RSA or ECC, but typically by less than an order of magnitude for public keys ( about 6–10×) and by roughly one to two orders of magnitude for signatures (about 10–1 00×), rather than by several orders of magnitude, making them the best available cand idates for general-purpose use such as replacing the use of RSA in PKIX certificates. Lattice-based public keys and signatures are larger than those of classical schemes s uch as RSA or ECC, but typically by less than an order of magnitude for public keys ( about 6-10x) and by roughly one to two orders of magnitude for signatures (about 10-1 00x) rather than by several orders of magnitude, making them the best available candi dates for general-purpose use, such as replacing the use of RSA in PKIX certificates.
Examples of this class of algorithms include ML-KEM, FN-DSA, ML-DSA and FrodoKEM. Examples of this class of algorithms include ML-KEM, FN-DSA, ML-DSA, and FrodoKEM.
It is noteworthy that lattice-based encryption schemes require a rounding step during decryption which has a non-zero probability of "rounding the wrong way" and leading to a decryption failure, meaning that valid encryptions are decrypted incorrectly. Ho wever, the parameters of NIST PQC candidates are carefully chosen so that the probabi lity of such a failure is cryptographically negligible, far lower than the probabilit y of random transmission errors and implementation bugs. In practical terms, these ra re decryption failures can be treated the same way as any fatal transport error: both sides simply perform a fresh KEM operation, generating a new ciphertext and shared s ecret. It is noteworthy that lattice-based encryption schemes require a rounding step during decryption, which has a non-zero probability of "rounding the wrong way" and leading to a decryption failure, meaning that valid encryptions are decrypted incorrectly. H owever, the parameters of NIST PQC candidates are carefully chosen so that the probab ility of such a failure is cryptographically negligible, far lower than the probabili ty of random transmission errors and implementation bugs. In practical terms, these r are decryption failures can be treated the same way as any fatal transport error: Bot h sides simply perform a fresh KEM operation, generating a new ciphertext and shared secret.
In cryptanalysis, an oracle refers to a system that an attacker can query to learn wh ether decryption succeeded or failed. If such an oracle exists, an attacker could sig nificantly reduce the security of lattice-based schemes that have a relatively high f ailure rate. However, for most of the NIST PQC proposals, the number of required orac le queries to force a decryption failure is above practical limits, as has been shown in {{LattFail1}}. More recent works have improved upon the results in {{LattFail1}}, showing that the cost of searching for additional failing ciphertexts after one or m ore have already been found, can be sped up dramatically {{LattFail2}}. Nevertheless, at the time this document is published, the PQC candidates by NIST are considered se cure under these attacks and constant monitoring as cryptanalysis research is ongoing . In cryptanalysis, an oracle refers to a system that an attacker can query to learn wh ether decryption succeeded or failed. If such an oracle exists, an attacker could sig nificantly reduce the security of lattice-based schemes that have a relatively high f ailure rate. However, for most of the NIST PQC proposals, the number of required orac le queries to force a decryption failure is above practical limits, as shown in {{Lat tFail1}}. More recent works have improved upon the results in {{LattFail1}}, showing that the cost of searching for additional failing ciphertexts after one or more have already been found can be sped up dramatically {{LattFail2}}. Nevertheless, at the ti me this document is published, the PQC candidates by NIST are considered secure under these attacks, and constant monitoring as cryptanalysis research is ongoing.
## Hash-Based Public Key Cryptography {#hash-based} ## Hash-Based Public Key Cryptography {#hash-based}
Hash based PKC has been around since the 1970s, when it was developed by Lamport and Merkle. It is used to create digital signature algorithms and its security is based o n the security of the underlying cryptographic hash function. Many variants of hash-b ased signatures (HBS) have been developed since the 70s including the recent XMSS {{R FC8391}}, HSS/LMS {{RFC8554}} or BPQS {{BPQS}} schemes. Unlike many other digital sig nature techniques, most hash-based signature schemes are stateful, which means that s igning necessitates the update and careful tracking of the state of the secret key. P roducing multiple signatures using the same secret key state results in loss of secur ity and may ultimately enable signature forgery attacks against that key. Hash-based Public Key Cryptography (PKC) has been around since the 1970s, when it was developed by Lamport and Merkle. It is used to create digital signature algorithms, and its security is based on the security of the underlying cryptographic hash functi on. Many variants of hash-based signatures (HBSs) have been developed since the 1970s , including the recent XMSS {{RFC8391}}, HSS/LMS {{RFC8554}}, or BPQS {{BPQS}} scheme s. Unlike many other digital signature techniques, most hash-based signature schemes are stateful, which means that signing necessitates the update and careful tracking o f the state of the secret key. Producing multiple signatures using the same secret ke y state results in loss of security and may ultimately enable signature forgery attac ks against that key.
Stateful hash-based signatures with long service lifetimes require additional operati onal complexity compared with other signature types. For example, consider a 20-year root key; there is an expectation that 20 years is longer than the expected lifetime of the hardware that key is stored on, and therefore the key will need to be migrated to new hardware at some point. Disaster-recovery scenarios where the primary node fa ils without warning can be similarly tricky. This requires careful operational and co mpliance consideration to ensure that no private key state can be reused across the m igration or disaster recovery event. One approach for avoiding these issues is to onl y use stateful HBS for short-term use cases that do not require horizontal scaling, f or example signing a batch of firmware images and then retiring the signing key. Stateful hash-based signatures with long service lifetimes require additional operati onal complexity compared to other signature types. For example, consider a 20-year ro ot key; there is an expectation that 20 years is longer than the expected lifetime of the hardware that key is stored on, so the key will need to be migrated to new hardw are at some point. Disaster-recovery scenarios where the primary node fails without w arning can be similarly tricky. This requires careful operational and compliance cons ideration to ensure that no private key state can be reused across the migration or d isaster recovery event. One approach for avoiding these issues is to only use statefu l HBSs for short-term use cases that do not require horizontal scaling, for example, signing a batch of firmware images and then retiring the signing key.
The SLH-DSA algorithm, which was standardized by NIST, leverages the HORST (hash to o btain random subset with trees) technique and remains the only standardized hash base d signature scheme that is stateless, thus avoiding the complexities associated with state management. SLH-DSA is an advancement on SPHINCS which reduces the signature si zes in SPHINCS and makes it more compact. The SLH-DSA algorithm, which was standardized by NIST, leverages the HORST (Hash to O btain Random Subset with Trees) technique and remains the only standardized hash base d signature scheme that is stateless, thus avoiding the complexities associated with state management. SLH-DSA is an advancement on SPHINCS that reduces the signature siz es in SPHINCS and makes it more compact.
## Code-Based Public Key Cryptography {#code-based} ## Code-Based Public Key Cryptography {#code-based}
This area of cryptography started in the 1970s and 80s based on the seminal work of M cEliece and Niederreiter which focuses on the study of cryptosystems based on error-c orrecting codes. Some popular error correcting codes include Goppa codes (used in McE liece cryptosystems), encoding and decoding syndrome codes used in Hamming quasi-cycl ic (HQC), or quasi-cyclic moderate density parity check (QC-MDPC) codes. This area of cryptography started in the 1970s and 1980s and was based on the seminal work of McEliece and Niederreiter, which focuses on the study of cryptosystems based on error-correcting codes. Some popular error-correcting codes include Goppa codes ( used in McEliece cryptosystems), encoding and decoding syndrome codes used in HQC, or quasi-cyclic moderate density parity check (QC-MDPC) codes.
Examples include all the unbroken NIST Round 4 finalists: Classic McEliece, HQC (sele Examples include all the unbroken NIST Round 4 finalists: Classic McEliece, HQC (sele
cted by NIST for standardization), and {{BIKE}}. cted by NIST for standardization), and BIKE {{BIKE}}.
<!-- [rfced] Please review the following sentence. The expansion of "KEM
encapsulation" would be "key encapsulation mechanism encapsulation" if it were
left as is. Is this correct? Or may we update as follows to avoid repetition?
Current:
The KEM encapsulation results in a fixed-length symmetric key that
can be used with a symmetric algorithm, typically a block cipher, in one of
two different ways:
Perhaps:
The KEM results in a fixed-length symmetric key that can be used with
a symmetric algorithm, typically a block cipher, in one of two different ways:
-->
# KEMs {#KEMs} # KEMs {#KEMs}
A Key Encapsulation Mechanism (KEM) is a cryptographic technique used for securely ex changing symmetric key material between two parties over an insecure channel. It is c ommonly used in hybrid encryption schemes, where a combination of asymmetric (public key) and symmetric encryption is employed. The KEM encapsulation results in a fixed-l ength symmetric key that can be used with a symmetric algorithm, typically a block ci pher, in one of two different ways: A Key Encapsulation Mechanism (KEM) is a cryptographic technique used for securely ex changing symmetric key material between two parties over an insecure channel. It is c ommonly used in hybrid encryption schemes where a combination of asymmetric (public k ey) and symmetric encryption is employed. The KEM encapsulation results in a fixed-le ngth symmetric key that can be used with a symmetric algorithm, typically a block cip her, in one of two different ways:
* Derive a data encryption key (DEK) to encrypt the data * To derive a data encryption key (DEK) to encrypt the data
* Derive a key encryption key (KEK) used to wrap a DEK * To derive a key encryption key (KEK) used to wrap a DEK
These techniques are often referred to as "hybrid public key encryption (HPKE)" {{!RF C9180}} mechanism. These techniques are often referred to as the Hybrid Public Key Encryption (HPKE) {{! RFC9180}} mechanism.
The term "encapsulation" is chosen intentionally to indicate that KEM algorithms beha ve differently at the API level from the key agreement or key encipherment / key tran sport mechanisms that are in use today. Key agreement schemes imply that both parties contribute a public / private key pair to the exchange, while key encipherment / key transport schemes imply that the symmetric key material is chosen by one party and " encrypted" or "wrapped" for the other party. KEMs, on the other hand, behave accordin g to the following API primitives {{PQCAPI}}: The term "encapsulation" is chosen intentionally to indicate that KEM algorithms beha ve differently at the API level from the key agreement or key encipherment and key tr ansport mechanisms that are in use today. Key agreement schemes imply that both parti es contribute a public-private key pair to the exchange, while key encipherment and k ey transport schemes imply that the symmetric key material is chosen by one party and "encrypted" or "wrapped" for the other party. KEMs, on the other hand, behave accord ing to the following API primitives {{PQCAPI}}:
* def kemKeyGen() -> (pk, sk) * def kemKeyGen() -> (pk, sk)
* def kemEncaps(pk) -> (ss, ct) * def kemEncaps(pk) -> (ss, ct)
* def kemDecaps(ct, sk) -> ss * def kemDecaps(ct, sk) -> ss
where `pk` is the public key, `sk` is the secret key, `ct` is the ciphertext represen ting an encapsulated key, and `ss` is the shared secret. The following figure illustr ates a sample flow of a KEM-based key exchange: where `pk` is the public key, `sk` is the secret key, `ct` is the ciphertext represen ting an encapsulated key, and `ss` is the shared secret. The following figure illustr ates a sample flow of a KEM-based key exchange:
~~~~~ aasvg ~~~~ aasvg
+---------+ +---------+ +---------+ +---------+
| Client | | Server | | Client | | Server |
+---------+ +---------+ +---------+ +---------+
+----------------------+ | | +----------------------+ | |
| pk, sk = kemKeyGen() |-| | | pk, sk = kemKeyGen() |-| |
+----------------------+ | | +----------------------+ | |
| | | |
| pk | | pk |
|---------->| |---------->|
| | +-----------------------+ | | +-----------------------+
| |-| ss, ct = kemEncaps(pk)| | |-| ss, ct = kemEncaps(pk)|
| | +-----------------------+ | | +-----------------------+
| | | |
| ct | | ct |
|<----------| |<----------|
+------------------------+ | | +------------------------+ | |
| ss = kemDecaps(ct, sk) |-| | | ss = kemDecaps(ct, sk) |-| |
+------------------------+ | | +------------------------+ | |
| | | |
~~~~~ ~~~~
{: #tab-kem-ke title="KEM based key exchange"} {: #tab-kem-ke title="KEM-Based Key Exchange"}
## Authenticated Key Exchange ## Authenticated Key Exchange
Authenticated Key Exchange (AKE) with KEMs where both parties contribute a KEM public key to the overall session key is interactive as described in Section 9.4 of {{?RFC9 528}}. However, single-sided KEM, such as when one peer has a KEM key in a certificat e and the other peer wants to encrypt for it (as in S/MIME or OpenPGP email), can be achieved using non-interactive HPKE {{RFC9180}}. The following figure illustrates the Diffie-Hellman (DH) Key exchange: <!-- [rfced] May we update the title of Figure 4 as follows?
~~~~~ aasvg Original:
Figure 4: Diffie-Hellman based AKE and NIKE simultaneously
Perhaps:
Figure 4: Simultaneous DH-Based AKE and NIKE
-->
Authenticated Key Exchange (AKE) with KEMs where both parties contribute a KEM public
key to the overall session key is interactive as described in {{Section 9.4 of ?RFC9
528}}. However, a single-sided KEM, such as when one peer has a KEM key in a certific
ate and the other peer wants to encrypt for it (as in S/MIME or OpenPGP email), can b
e achieved using non-interactive HPKE {{RFC9180}}. The following figure illustrates t
he DH Key exchange:
~~~~ aasvg
+---------+ +---------+ +---------+ +---------+
| Client | | Server | | Client | | Server |
+---------+ +---------+ +---------+ +---------+
+-----------------------+ | | +-----------------------+ | |
| Long-term client key: | | | | Long-term client key: | | |
| sk1, pk1 |-| | | sk1, pk1 |-| |
+-----------------------+ | | +-----------------------+ | |
| | | |
| pk1 | | pk1 |
|---------->| |---------->|
skipping to change at line 513 skipping to change at line 1163
+-------------------------+ | | +-------------------------+ | |
| ss = KeyEx(pk2, sk1) | | | | ss = KeyEx(pk2, sk1) | | |
| encryptContent(ss) |-| | | encryptContent(ss) |-| |
+-------------------------+ | | +-------------------------+ | |
| encrypted | | encrypted |
| content | | content |
|---------->| |---------->|
| | +------------------------+ | | +------------------------+
| | | decryptContent(ss) | | | | decryptContent(ss) |
| | +------------------------+ | | +------------------------+
~~~~~ ~~~~
{: #tab-dh-ake title="Diffie-Hellman based AKE"} {: #tab-dh-ake title="DH-Based AKE"}
What's important to note about the sample flow above is that the shared secret `ss` i s derived using key material from both the Client and the Server, which classifies it as an AKE. There is another property of a key exchange, called Non-Interactive Key E xchange (NIKE) which refers to whether the sender can compute the shared secret `ss` and encrypt content without requiring active interaction (an exchange of network mess ages) with the recipient. {{tab-dh-ake}} shows a Diffie-Hellman key exchange which is an AKE, since both parties are using long-term keys which can have established trust (for example, via certificates), but it is not a NIKE, since the client needs to wai t for the network interaction to receive the receiver's public key `pk2` before it ca n compute the shared secret `ss` and begin content encryption. However, a DH key exch ange can be an AKE and a NIKE at the same time if the receiver's public key is known to the sender in advance, and many Internet protocols rely on this property of DH-bas ed key exchanges. <!-- [rfced] Figure 4 is not referred to in the text. May we update this sentence as shown below?
~~~~~ aasvg Original:
However, a DH key exchange can be an AKE and a NIKE at
the same time if the receiver's public key is known to the sender in
advance, and many Internet protocols rely on this property of DH-
based key exchanges.
Perhaps:
However, a DH key exchange can be an AKE and a NIKE at
the same time if the receiver's public key is known to the sender in
advance (see Figure 4), and many Internet protocols rely on this property of DH-
based key exchanges.
-->
In the sample flow above, it is important to note that the shared secret `ss` is deri
ved using key material from both the client and the server, which classifies it as an
AKE. There is another property of a key exchange, called Non-Interactive Key Exchang
e (NIKE), that refers to whether the sender can compute the shared secret `ss` and e
ncrypt content without requiring active interaction (an exchange of network messages)
with the recipient. {{tab-dh-ake}} shows a DH key exchange, which is an AKE since bo
th parties are using long-term keys that can have established trust (for example, via
certificates), but it is not a NIKE since the client needs to wait for the network i
nteraction to receive the receiver's public key `pk2` before it can compute the share
d secret `ss` and begin content encryption. However, a DH key exchange can be an AKE
and a NIKE at the same time if the receiver's public key is known to the sender in ad
vance, and many Internet protocols rely on this property of DH-based key exchanges.
~~~~ aasvg
+---------+ +---------+ +---------+ +---------+
| Client | | Server | | Client | | Server |
+---------+ +---------+ +---------+ +---------+
+-----------------------+ | | +-----------------------+ | |
| Long-term client key: | | | | Long-term client key: | | |
| sk1, pk1 |-| | | sk1, pk1 |-| |
| Long-term server key: | | | | Long-term server key: | | |
| pk2 | | | | pk2 | | |
| ss = KeyEx(pk2, sk1) | | | | ss = KeyEx(pk2, sk1) | | |
| encryptContent(ss) |-| | | encryptContent(ss) |-| |
skipping to change at line 541 skipping to change at line 1206
| pk1, | | pk1, |
| encrypted | | encrypted |
| content | | content |
|---------->| |---------->|
| | +------------------------+ | | +------------------------+
| |-| Long-term server key: | | |-| Long-term server key: |
| | | sk2, pk2 | | | | sk2, pk2 |
| | | ss = KeyEx(pk1, sk2) | | | | ss = KeyEx(pk1, sk2) |
| | | decryptContent(ss) | | | | decryptContent(ss) |
| | +------------------------+ | | +------------------------+
~~~~~ ~~~~
{: #tab-dh-ake-nike title="Diffie-Hellman based AKE and NIKE simultaneously"} {: #tab-dh-ake-nike title="DH-Based AKE and NIKE Simultaneously"}
The complication with KEMs is that a KEM `Encaps()` is non-deterministic; it involves randomness chosen by the sender of that message. Therefore, in order to perform an A KE, the client must wait for the server to generate the needed randomness and perform `Encaps()` against the client key, which necessarily requires a network round-trip. Therefore, a KEM-based protocol can either be an AKE or a NIKE, but cannot be both at the same time. Consequently, certain Internet protocols will necessitate a redesign to accommodate this distinction, either by introducing extra network round-trips or b y making trade-offs in security properties. The complication with KEMs is that a KEM `Encaps()` is non-deterministic; it involves randomness chosen by the sender of that message. Therefore, in order to perform an A KE, the client must wait for the server to generate the needed randomness and perform `Encaps()` against the client key, which necessarily requires a network round-trip. Therefore, a KEM-based protocol can either be an AKE or a NIKE, but it cannot be both at the same time. Consequently, certain Internet protocols will necessitate a redesi gn to accommodate this distinction, either by introducing extra network round trips o r by making trade-offs in security properties.
~~~~~ aasvg <!-- [rfced] In Figure 5, please review the second box on the left side of the
diagram. There seems to be an extra "-|", and the box is not closed. Would you
like to make any updates here? Please check out the suggested update in these
test files and let us know your thoughts:
https://www.rfc-editor.org/authors/rfc9958-TEST.md
https://www.rfc-editor.org/authors/rfc9958-TEST.txt
https://www.rfc-editor.org/authors/rfc9958-TEST.html
-->
~~~~ aasvg
+---------+ +---------+ +---------+ +---------+
| Client | | Server | | Client | | Server |
+---------+ +---------+ +---------+ +---------+
+------------------------+ | | +------------------------+ | |
| pk1, sk1 = kemKeyGen() |-| | | pk1, sk1 = kemKeyGen() |-| |
+------------------------+ | | +------------------------+ | |
| | | |
|pk1 | |pk1 |
|---------->| |---------->|
| | +--------------------------+ | | +--------------------------+
skipping to change at line 575 skipping to change at line 1250
| ss2, ct2 = kemEncaps(pk2)| | | ss2, ct2 = kemEncaps(pk2)| |
| ss = Combiner(ss1, ss2)| | | | ss = Combiner(ss1, ss2)| | |
+------------------------+ | | +------------------------+ | |
| | | |
|ct2 | |ct2 |
|---------->| |---------->|
| | +--------------------------+ | | +--------------------------+
| |-| ss2 = kemDecaps(ct2, sk2)| | |-| ss2 = kemDecaps(ct2, sk2)|
| | | ss = Combiner(ss1, ss2) | | | | ss = Combiner(ss1, ss2) |
| | +--------------------------+ | | +--------------------------+
~~~~~ ~~~~
{: #tab-kem-ake title="KEM based AKE"} {: #tab-kem-ake title="KEM-Based AKE"}
Here, `Combiner(ss1, ss2)`, often referred to as a KEM Combiner, is a cryptographic c onstruction that takes in two shared secrets and returns a single combined shared sec ret. The simplest combiner is concatenation `ss1 || ss2`, but combiners can vary in c omplexity depending on the cryptographic properties required. For example, if the com bination should preserve IND-CCA2 {{INDCCA2}} of either input even if the other is ch osen maliciously, then a more complex construct is required. Another consideration fo r combiner design is so-called "binding properties" introduced in {{KEEPINGUP}}, whic h may require the ciphertexts and recipient public keys to be included in the combine r. KEM combiner security analysis becomes more complicated in hybrid settings where t he two KEMs represent different algorithms, for example, where one is ML-KEM and the other is ECDH. For a more thorough discussion of KEM combiners, see {{KEEPINGUP}}, {{ ?I-D.draft-ounsworth-cfrg-kem-combiners}}, and {{?I-D.irtf-cfrg-hybrid-kems}}. In the figure above, `Combiner(ss1, ss2)`, often referred to as a KEM combiner, is a cryptographic construction that takes in two shared secrets and returns a single comb ined shared secret. The simplest combiner is concatenation `ss1 || ss2`, but combiner s can vary in complexity depending on the cryptographic properties required. For exam ple, if the combination should preserve IND-CCA2 (see {{INDCCA2}}) of either input, e ven if the other is chosen maliciously, then a more complex construct is required. An other consideration for combiner design is the so-called "binding properties" introdu ced in {{KEEPINGUP}}, which may require the ciphertexts and recipient public keys to be included in the combiner. KEM combiner security analysis becomes more complicated in hybrid settings where the two KEMs represent different algorithms, for example, wh ere one is ML-KEM and the other is ECDH. For a more thorough discussion of KEM combin ers, see {{KEEPINGUP}}, {{I-D.ounsworth-cfrg-kem-combiners}}, and {{I-D.irtf-cfrg-hyb rid-kems}}.
## Security Properties of KEMs ## Security Properties of KEMs
The security properties described in this section (IND-CCA2 and binding) are not an e xhaustive list of all possible KEM security considerations. They were selected becaus e they are fundamental to evaluating KEM suitability in protocol design and are commo nly discussed in current PQC work. The security properties described in this section (IND-CCA2 and binding) are not an e xhaustive list of all possible KEM security considerations. They were selected becaus e they are fundamental to evaluating KEM suitability in protocol design and are commo nly discussed in current PQC work.
### IND-CCA2 {#INDCCA2} ### IND-CCA2 {#INDCCA2}
IND-CCA2 (INDistinguishability under adaptive Chosen-Ciphertext Attack) is an advance d security notion for encryption schemes. It ensures the confidentiality of the plain text and resistance against chosen-ciphertext attacks. An appropriate definition of I ND-CCA2 security for KEMs can be found in {{CS01}} and {{BHK09}}. ML-KEM {{ML-KEM}} a nd Classic McEliece provide IND-CCA2 security. IND-CCA2 (INDistinguishability under adaptive Chosen-Ciphertext Attack) is an advance d security notion for encryption schemes. It ensures the confidentiality of the plain text and resistance against chosen-ciphertext attacks. An appropriate definition of I ND-CCA2 security for KEMs can be found in {{CS01}} and {{BHK09}}. ML-KEM {{ML-KEM}} a nd Classic McEliece provide IND-CCA2 security.
Understanding IND-CCA2 security is essential for individuals involved in designing or implementing cryptographic systems and protocols in order to evaluate the strength o f the algorithm, assess its suitability for specific use cases, and ensure that data confidentiality and security requirements are met. Understanding IND-CCA2 security is generally not necessary for developers migrating to using an IETF-vetted key establi shment method (KEM) within a given protocol or flow. IND-CCA2 is a widely accepted se curity notion for public key encryption mechanisms, making it suitable for a broad ra nge of applications. When an IETF specification defines a new KEM, its security consi derations should fully describe the relevant cryptographic properties, including IND- CCA2. Understanding IND-CCA2 security is essential for individuals involved in designing or implementing cryptographic systems and protocols in order to evaluate the strength o f the algorithm, assess its suitability for specific use cases, and ensure that data confidentiality and security requirements are met. Understanding IND-CCA2 security is generally not necessary for developers migrating to using an IETF-vetted key establi shment method (KEM) within a given protocol or flow. IND-CCA2 is a widely accepted se curity notion for public key encryption mechanisms, making it suitable for a broad ra nge of applications. When an IETF specification defines a new KEM, its security consi derations should fully describe the relevant cryptographic properties, including IND- CCA2.
### Binding ### Binding
KEMs also have an orthogonal set of properties to consider when designing protocols a round them: binding {{KEEPINGUP}}. This can be "ciphertext binding", "public key bind ing", "context binding", or any other property that is important to not be substitute d between KEM invocations. In general, a KEM is considered to bind a certain value if substitution of that value by an attacker will necessarily result in a different sha red secret being derived. As an example, if an attacker can construct two different c iphertexts which will decapsulate to the same shared secret; or can construct a ciphe rtext which will decapsulate to the same shared secret under two different public key s, or can substitute whole KEM exchanges from one session into another, then the cons truction is not ciphertext binding, public key binding, or context binding respective ly. Similarly, protocol designers may wish to bind protocol state information such as a transaction ID or nonce so that attempts to replay ciphertexts from one session in side a different session will be blocked at the cryptographic level because the serve r derives a different shared secret and is thus is unable to decrypt the content. KEMs also have an orthogonal set of properties to consider when designing protocols a round them: binding {{KEEPINGUP}}. This can be "ciphertext binding", "public key bind ing", "context binding", or any other property that is important to not be substitute d between KEM invocations. In general, a KEM is considered to bind a certain value if substitution of that value by an attacker will necessarily result in a different sha red secret being derived. As an example, if an attacker can construct two different c iphertexts that will decapsulate to the same shared secret, can construct a ciphertex t that will decapsulate to the same shared secret under two different public keys, or can substitute whole KEM exchanges from one session into another, then the construct ion is not ciphertext binding, public key binding, or context binding, respectively. Similarly, protocol designers may wish to bind protocol state information such as a t ransaction ID or nonce so that attempts to replay ciphertexts from one session inside a different session will be blocked at the cryptographic level because the server de rives a different shared secret and is thus is unable to decrypt the content.
The solution to binding is generally achieved at the protocol design level: It is rec <!-- [rfced] Will readers understand what "it" in the phrase "pass it through"
ommended to avoid using the KEM output shared secret directly without integrating it refers to here? Does "it" refer to "KEMs", "secrets", or something else?
into an appropriate protocol. While KEM algorithms provide key secrecy, they do not i
nherently ensure source authenticity, protect against replay attacks, or guarantee fr Original:
eshness. These security properties should be addressed by incorporating the KEM into Even though modern KEMs such as ML-KEM produce full-
a protocol that has been analyzed for such protections. Even though modern KEMs such entropy shared secrets, it is still advisable for binding reasons to
as ML-KEM produce full-entropy shared secrets, it is still advisable for binding reas pass it through a key derivation function (KDF) and also include all
ons to pass it through a key derivation function (KDF) and also include all values th values that you wish to bind; then finally you will have a shared
at you wish to bind; then finally you will have a shared secret that is safe to use a secret that is safe to use at the protocol level.
t the protocol level. -->
The solution to binding is generally achieved at the protocol design level: It is rec
ommended to avoid using the KEM output shared secret directly without integrating it
into an appropriate protocol. While KEM algorithms provide key secrecy, they do not i
nherently ensure source authenticity, protect against replay attacks, or guarantee fr
eshness. These security properties should be addressed by incorporating the KEM into
a protocol that has been analyzed for such protections. Even though modern KEMs such
as ML-KEM produce full-entropy shared secrets, it is still advisable for binding reas
ons to pass it through a key derivation function (KDF) and also include all values th
at you wish to bind; then, you will have a shared secret that is safe to use at the p
rotocol level.
## HPKE {#hpke} ## HPKE {#hpke}
Modern cryptography has long used the notion of "hybrid encryption" where an asymmetr ic algorithm is used to establish a key, and then a symmetric algorithm is used for b ulk content encryption. The previous sections explained important security properties of KEMs, such as IND-CCA2 security and binding, and emphasized that these properties must be supported by proper protocol design. One widely deployed scheme that achieve s this is HPKE (Hybrid Public Key Encryption) {{RFC9180}}. Modern cryptography has long used the notion of "hybrid encryption" where an asymmetr ic algorithm is used to establish a key and then a symmetric algorithm is used for bu lk content encryption. The previous sections explained important security properties of KEMs, such as IND-CCA2 security and binding, and emphasized that these properties must be supported by proper protocol design. One widely deployed scheme that achieves this is Hybrid Public Key Encryption (HPKE) {{RFC9180}}.
HPKE (hybrid public key encryption) {{RFC9180}} works with a combination of KEMs, KDF s and AEAD (authenticated encryption with additional data) schemes. HPKE includes thr ee authenticated variants, including one that authenticates possession of a pre-share d key and two optional ones that authenticate possession of a key encapsulation mecha nism (KEM) private key. HPKE can be extended to support hybrid post-quantum KEM {{?I- D.ietf-hpke-pq}}. ML-KEM does not support the static-ephemeral key exchange that allo ws HPKE based on DH based KEMs and its optional authenticated modes as discussed in s ection 1.5 of {{?I-D.draft-connolly-cfrg-xwing-kem}}. HPKE {{RFC9180}} works with a combination of KEMs, KDFs, and Authenticated Encryption with Associated Data (AEAD) schemes. HPKE includes three authenticated variants, inc luding one that authenticates possession of a pre-shared key and two optional ones th at authenticate possession of a KEM private key. HPKE can be extended to support hybr id post-quantum KEM {{I-D.ietf-hpke-pq}}. ML-KEM does not support the static-ephemera l key exchange that allows HPKE that is based on DH-based KEMs and its optional authe nticated modes as discussed in {{Section 1.5 of I-D.connolly-cfrg-xwing-kem}}.
# PQC Signatures # PQC Signatures
Any digital signature scheme that provides a construction defining security under a p ost-quantum setting falls under this category of PQC signatures. Any digital signature scheme that provides a construction defining security under a p ost-quantum setting falls under this category of PQC signatures.
## Security Properties of PQC Signatures ## Security Properties of PQC Signatures
### EUF-CMA and SUF-CMA ### EUF-CMA and SUF-CMA
EUF-CMA (existential unforgeability under chosen message attack) {{GMR88}} is a secur ity notion for digital signature schemes. It guarantees that an adversary, even with access to a signing oracle, cannot forge a valid signature for an arbitrary message. EUF-CMA provides strong protection against forgery attacks, ensuring the integrity an d authenticity of digital signatures by preventing unauthorized modifications or frau dulent signatures. ML-DSA, FN-DSA, and SLH-DSA provide EUF-CMA security. EUF-CMA (existential unforgeability under chosen message attack) {{GMR88}} is a secur ity notion for digital signature schemes. It guarantees that an adversary, even with access to a signing oracle, cannot forge a valid signature for an arbitrary message. EUF-CMA provides strong protection against forgery attacks, ensuring the integrity an d authenticity of digital signatures by preventing unauthorized modifications or frau dulent signatures. ML-DSA, FN-DSA, and SLH-DSA provide EUF-CMA security.
SUF-CMA (strong unforgeability under chosen message attack) builds upon EUF-CMA by re quiring that an adversary cannot produce a different valid signature for a message th at has already been signed by the signing oracle. Like EUF-CMA, SUF-CMA provides robu st assurances for digital signature schemes, further enhancing their security posture . ML-DSA, FN-DSA, and SLH-DSA also achieve SUF-CMA security. SUF-CMA (strong unforgeability under chosen message attack) builds upon EUF-CMA by re quiring that an adversary cannot produce a different valid signature for a message th at has already been signed by the signing oracle. Like EUF-CMA, SUF-CMA provides robu st assurances for digital signature schemes, further enhancing their security posture . ML-DSA, FN-DSA, and SLH-DSA also achieve SUF-CMA security.
Understanding EUF-CMA and SUF-CMA security is essential for designing or implementing cryptographic systems in order to ensure the security, reliability, and robustness o f digital signature schemes. These notions allow for informed decision-making, vulner ability analysis, compliance with standards, and designing systems that provide stron g protection against forgery attacks. For developers migrating to using an IETF-vette d PQC signature scheme within a given protocol or flow, a deep understanding of EUF-C MA and SUF-CMA security may not be necessary, as the schemes vetted by IETF adhere to these stringent security standards. Understanding EUF-CMA and SUF-CMA security is essential for designing or implementing cryptographic systems in order to ensure the security, reliability, and robustness o f digital signature schemes. These notions allow for informed decision making, vulner ability analysis, compliance with standards, and designing systems that provide stron g protection against forgery attacks. For developers migrating to an IETF-vetted PQC signature scheme within a given protocol or flow, a deep understanding of EUF-CMA and SUF-CMA security may not be necessary, as the schemes vetted by IETF adhere to these stringent security standards.
EUF-CMA and SUF-CMA are considered strong security benchmarks for public key signatur e algorithms, making them suitable for most applications. IETF specification authors should include all security concerns in the "Security Considerations" section of the relevant RFC and should not assume that implementers are experts in cryptographic the ory. EUF-CMA and SUF-CMA are considered strong security benchmarks for public key signatur e algorithms, making them suitable for most applications. Authors of IETF specificati ons should include all security concerns in the "Security Considerations" section of the relevant RFC and should not assume that implementers are experts in cryptographic theory.
## Details of FN-DSA, ML-DSA, and SLH-DSA {#sig-scheme} ## Details of FN-DSA, ML-DSA, and SLH-DSA {#sig-scheme}
ML-DSA {{ML-DSA}} is a digital signature algorithm based on the hardness of lattice p roblems over module lattices (i.e., the Module Learning with Errors problem (MLWE)). The design of the algorithm is based on the "Fiat-Shamir with Aborts" {{Lyu09}} frame work introduced by Lyubashevsky, that leverages rejection sampling to render lattice- based Fiat-Shamir (FS) schemes compact and secure. ML-DSA uses uniformly-distributed random number sampling over small integers to compute coefficients in error vectors, which makes the scheme easier to implement compared with FN-DSA {{FN-DSA}} which uses Gaussian-distributed numbers, necessitating the need to use floating point arithmeti c during signature generation. ML-DSA {{ML-DSA}} is a digital signature algorithm based on the hardness of lattice p roblems over module lattices (i.e., the Module Learning with Errors (MLWE) problem). The design of the algorithm is based on the "Fiat-Shamir with Aborts" {{Lyu09}} frame work introduced by Lyubashevsky that leverages rejection sampling to render lattice-b ased Fiat-Shamir (FS) schemes compact and secure. ML-DSA uses uniformly distributed r andom number sampling over small integers to compute coefficients in error vectors, w hich makes the scheme easier to implement compared to FN-DSA {{FN-DSA}}, which uses Gaussian-distributed numbers, necessitating the need to use floating-point arithmetic during signature generation.
ML-DSA offers both deterministic and randomized signing and is instantiated with 3 pa rameter sets providing different security levels. Security properties of ML-DSA are d iscussed in Section 9 of {{!I-D.ietf-lamps-dilithium-certificates}}. ML-DSA offers both deterministic and randomized signing and is instantiated with thre e parameter sets providing different security levels. Security properties of ML-DSA a re discussed in {{Section 9 of !RFC9881}}.
FN-DSA {{FN-DSA}} is based on the GPV hash-and-sign lattice-based signature framework introduced by Gentry, Peikert, and Vaikuntanathan, which is a framework that require s a certain class of lattices and a trapdoor sampler technique. FN-DSA {{FN-DSA}} is based on the GPV hash-and-sign lattice-based signature framework introduced by Gentry, Peikert, and Vaikuntanathan, which is a framework that require s a certain class of lattices and a trapdoor sampler technique.
The main design principle of FN-DSA is compactness, i.e., it was designed in a way th at achieves minimal total memory bandwidth requirement (the sum of the signature size plus the public key size). This is possible due to the compactness of NTRU lattices. FN-DSA also offers very efficient signing and verification procedures. The main pote ntial downsides of FN-DSA refer to the non-triviality of its algorithms and the need for floating point arithmetic support in order to support Gaussian-distributed random number sampling where the other lattice schemes use the less efficient but easier to support uniformly-distributed random number sampling. The main design principle of FN-DSA is compactness, i.e., it was designed in a way th at achieves minimal total memory bandwidth requirement (the sum of the signature size plus the public key size). This is possible due to the compactness of NTRU lattices. FN-DSA also offers very efficient signing and verification procedures. The main pote ntial downsides of FN-DSA refer to the non-triviality of its algorithms and the need for floating-point arithmetic support in order to support Gaussian-distributed random number sampling where the other lattice schemes use the less efficient but easier to support uniformly distributed random number sampling.
Implementers of FN-DSA need to be aware that FN-DSA signing is highly susceptible to <!-- [rfced] Will readers know what "NIST's report" is here? Would a citation
side-channel attacks, unless constant-time 64-bit floating-point operations are used. be helpful? If so, please provide the appropriate reference entry.
This requirement is extremely platform-dependent, as noted in NIST's report.
The performance characteristics of ML-DSA and FN-DSA may differ based on the specific Original:
implementation and hardware platform. Generally, ML-DSA is known for its relatively This requirement is extremely
fast signature generation, while FN-DSA can provide more efficient signature verifica platform-dependent, as noted in NIST's report.
tion. The choice may depend on whether the application requires more frequent signatu -->
re generation or signature verification (See {{LIBOQS}}). For further clarity on the
sizes and security levels, please refer to the tables in {{RecSecurity}} and {{Compar Implementers of FN-DSA need to be aware that FN-DSA signing is highly susceptible to
isons}}. side-channel attacks unless constant-time 64-bit floating-point operations are used.
This requirement is extremely platform-dependent, as noted in NIST's report.
The performance characteristics of ML-DSA and FN-DSA may differ based on the specific
implementation and hardware platform. Generally, ML-DSA is known for its relatively
fast signature generation, while FN-DSA can provide more efficient signature verifica
tion. The choice may depend on whether the application requires more frequent signatu
re generation or signature verification (see {{LIBOQS}}). For further clarity on the
sizes and security levels, please refer to the tables in Sections {{RecSecurity}}{: f
ormat="counter"} and {{Comparisons}}{: format="counter"}.
SLH-DSA {{SLH-DSA}} utilizes the concept of stateless hash-based signatures, where ea ch signature is unique and unrelated to any previous signature (as discussed in {{has h-based}}). This property eliminates the need for maintaining state information durin g the signing process. SLH-DSA was designed to sign up to 2^64 messages under a given key pair, and it offers three security levels. The parameters for each of the securi ty levels were chosen to provide 128 bits of security, 192 bits of security, and 256 bits of security. SLH-DSA offers smaller public key sizes, larger signature sizes, sl ower signature generation, and slower verification when compared to ML-DSA and FN-DSA . SLH-DSA does not introduce a new hardness assumption beyond those inherent to the u nderlying hash functions. It builds upon established foundations in cryptography, mak ing it a reliable and robust digital signature scheme for a post-quantum world. SLH-DSA {{SLH-DSA}} utilizes the concept of stateless hash-based signatures, where ea ch signature is unique and unrelated to any previous signature (as discussed in {{has h-based}}). This property eliminates the need for maintaining state information durin g the signing process. SLH-DSA was designed to sign up to 2^64 messages under a given key pair, and it offers three security levels. The parameters for each of the securi ty levels were chosen to provide 128 bits of security, 192 bits of security, and 256 bits of security. SLH-DSA offers smaller public key sizes, larger signature sizes, sl ower signature generation, and slower verification when compared to ML-DSA and FN-DSA . SLH-DSA does not introduce a new hardness assumption beyond those inherent to the u nderlying hash functions. It builds upon established foundations in cryptography, mak ing it a reliable and robust digital signature scheme for a post-quantum world.
All of these algorithms, ML-DSA, FN-DSA, and SLH-DSA include two signature modes: pur e mode, where the entire content is signed directly, and pre-hash mode, where a diges t of the content is signed. All of these algorithms (ML-DSA, FN-DSA, and SLH-DSA) include two signature modes: pu re mode, where the entire content is signed directly, and pre-hash mode, where a dige st of the content is signed.
## Details of XMSS and LMS ## Details of XMSS and LMS
The eXtended Merkle Signature Scheme (XMSS) {{RFC8391}} and Hierarchical Signature Sc heme (HSS) / Leighton-Micali Signature (LMS) {{RFC8554}} are stateful hash-based sign ature schemes, where the secret key state changes over time. In both schemes, reusing a secret key state compromises cryptographic security guarantees. The eXtended Merkle Signature Scheme (XMSS) {{RFC8391}} and Hierarchical Signature Sc heme (HSS) / Leighton-Micali Signature (LMS) {{RFC8554}} are stateful hash-based sign ature schemes, where the secret key state changes over time. In both schemes, reusing a secret key state compromises cryptographic security guarantees.
XMSS and LMS can be used for signing a potentially large but fixed number of messages and the number of signing operations depends upon the size of the tree. XMSS and LMS provide cryptographic digital signatures without relying on the conjectured hardness of mathematical problems, instead leveraging the properties of cryptographic hash fu nctions. Multi-tree XMSS and LMS (i.e., XMSS-MT and HSS, respectively) use a hyper-tr ee based hierarchical approach with a Merkle tree at each level of the hierarchy. {{R FC8391}} describes both single-tree and multi-tree variants of XMSS, while {{RFC8554} } describes the Leighton-Micali One-Time Signature (LM-OTS) system as well as the LMS and HSS N-time signature systems. Comparison of XMSS and LMS is discussed in Section 10 of {{RFC8554}}. XMSS and LMS can be used for signing a potentially large but fixed number of messages , and the number of signing operations depends upon the size of the tree. XMSS and LM S provide cryptographic digital signatures without relying on the conjectured hardnes s of mathematical problems, instead leveraging the properties of cryptographic hash f unctions. Multi-tree XMSS and LMS (i.e., XMSS-MT and HSS, respectively) use a hyper-t ree-based hierarchical approach with a Merkle tree at each level of the hierarchy. {{ RFC8391}} describes both single-tree and multi-tree variants of XMSS, while {{RFC8554 }} describes the Leighton-Micali One-Time Signature (LM-OTS) system as well as the LM S and HSS N-time signature systems. Comparison of XMSS and LMS is discussed in {{Sect ion 10 of RFC8554}}.
The number of tree layers in multi-tree XMSS and HSS provides a trade-off between sig nature size on the one side and key generation and signing speed on the other side. I ncreasing the number of layers reduces key generation time exponentially and signing time linearly at the cost of increasing the signature size linearly. HSS allows for c ustomization of each subtree whereas XMSS-MT does not, electing instead to use the sa me structure for each subtree. The number of tree layers in multi-tree XMSS and HSS provides a trade-off between sig nature size on the one side and key generation and signing speed on the other side. I ncreasing the number of layers reduces key generation time exponentially and signing time linearly at the cost of increasing the signature size linearly. HSS allows for c ustomization of each subtree, whereas XMSS-MT does not, electing instead to use the s ame structure for each subtree.
Due to the complexities described above, the XMSS and LMS are not a suitable replacem ent for traditional signature schemes like RSA or ECDSA. Applications that expect a l ong lifetime of a signature, like firmware update or secure boot, are typical use cas es where those schemes can be successfully applied. Due to the complexities described above, XMSS and LMS are not suitable replacements f or traditional signature schemes like RSA or ECDSA. Applications that expect a long l ifetime of a signature, like firmware update or secure boot, are typical use cases wh ere those schemes can be successfully applied.
### LMS Key and Signature Sizes ### LMS Key and Signature Sizes
The LMS scheme is characterized by four distinct parameter sets: the underlying hash function (SHA2-256 or SHAKE-256), the length of the digest (24 or 32 bytes), the LMS tree height parameter that controls a maximal number of signatures that the private k ey can produce, and the width of the Winternitz coefficients (see {{RFC8554}}, sectio n 4.1) that can be used to trade-off signing time for signature size. Parameters can be mixed, providing 80 possible parameterizations of the scheme. The LMS scheme is characterized by four distinct parameter sets: the underlying hash function (SHA2-256 or SHAKE-256), the length of the digest (24 or 32 bytes), the LMS tree height parameter that controls a maximal number of signatures that the private k ey can produce, and the width of the Winternitz coefficients (see {{RFC8554, Section 4.1}}) that can be used to trade-off signing time for signature size. Parameters can be mixed, providing 80 possible parameterizations of the scheme.
The public (PK) and private (SK) key size depends on the length of the digest (M). Th e signature size depends on the digest, the Winternitz parameter (W), the LMS tree he ight (H), and the length of the digest. The table below provides key and signature si zes for parameterization with the digest size M=32 of the scheme. The public (PK) and private (SK) key size depends on the length of the digest (M). Th e signature size depends on the digest, the Winternitz parameter (W), the LMS tree he ight (H), and the length of the digest. The table below provides key and signature si zes for parameterization with the digest size M=32 of the scheme.
| PK | SK | W | H=5 | H=10 | H=15 | H=20 | H=25 | | PK | SK | W | H=5 | H=10 | H=15 | H=20 | H=25 |
|----|----|---|------|------|------|------|------| |----|----|---|------|------|------|------|------|
| 56 | 52 | 1 | 8684 | 8844 | 9004 | 9164 | 9324 | | 56 | 52 | 1 | 8684 | 8844 | 9004 | 9164 | 9324 |
| 56 | 52 | 2 | 4460 | 4620 | 4780 | 4940 | 5100 | | 56 | 52 | 2 | 4460 | 4620 | 4780 | 4940 | 5100 |
| 56 | 52 | 4 | 2348 | 2508 | 2668 | 2828 | 2988 | | 56 | 52 | 4 | 2348 | 2508 | 2668 | 2828 | 2988 |
| 56 | 52 | 8 | 1292 | 1452 | 1612 | 1772 | 1932 | | 56 | 52 | 8 | 1292 | 1452 | 1612 | 1772 | 1932 |
## Hash-then-Sign ## Hash-then-Sign
Within the hash-then-sign paradigm, the message is hashed before signing it. By pre-h ashing, the onus of resistance to existential forgeries becomes heavily reliant on th e collision-resistance of the hash function in use. The hash-then-sign paradigm has t he ability to improve application performance by reducing the size of signed messages that need to be transmitted between application and cryptographic module, and making the signature size predictable and manageable. As a corollary, hashing remains manda tory even for short messages and assigns a further computational requirement onto the verifier. This makes the performance of hash-then-sign schemes more consistent, but not necessarily more efficient. Within the hash-then-sign paradigm, the message is hashed before signing it. By pre-h ashing, the onus of resistance to existential forgeries becomes heavily reliant on th e collision-resistance of the hash function in use. The hash-then-sign paradigm has t he ability to improve application performance by reducing the size of signed messages that need to be transmitted between application and cryptographic module and making the signature size predictable and manageable. As a corollary, hashing remains mandat ory even for short messages and assigns a further computational requirement onto the verifier. This makes the performance of hash-then-sign schemes more consistent, but n ot necessarily more efficient.
Using a hash function to produce a fixed-size digest of a message ensures that the si gnature is compatible with a wide range of systems and protocols, regardless of the s pecific message size or format. Crucially for hardware security modules, Hash-then-Si gn also significantly reduces the amount of data that needs to be transmitted and pro cessed by a Hardware Security Module (HSM). Consider scenarios such as a networked HS M located in a different data center from the calling application or a smart card con nected over a USB interface. In these cases, streaming a message that is megabytes or gigabytes long can result in notable network latency, on-device signing delays, or e ven depletion of available on-device memory. Using a hash function to produce a fixed-size digest of a message ensures that the si gnature is compatible with a wide range of systems and protocols, regardless of the s pecific message size or format. Crucially for hardware security modules, Hash-then-Si gn also significantly reduces the amount of data that needs to be transmitted and pro cessed by a Hardware Security Module (HSM). Consider scenarios such as a networked HS M located in a different data center from the calling application or a smart card con nected over a USB interface. In these cases, streaming a message that is megabytes or gigabytes long can result in notable network latency, on-device signing delays, or e ven depletion of available on-device memory.
Note that the vast majority of Internet protocols that sign large messages already pe rform some form of content hashing at the protocol level, so this tends to be more of a concern with proprietary cryptographic protocols, and protocols from non-IETF stan dards bodies. Protocols like TLS 1.3 and DNSSEC use the Hash-then-Sign paradigm. In T LS 1.3 {{RFC8446}} CertificateVerify messages, the content that is covered under the signature includes the transcript hash output (Section 4.4.1 of {{RFC8446}}), while D NSSEC {{RFC4034}} uses it to provide origin authentication and integrity assurance se rvices for DNS data. Similarly, the Cryptographic Message Syntax (CMS) {{?RFC5652}} i ncludes a mandatory message digest step before invoking the signature algorithm. Note that the vast majority of Internet protocols that sign large messages already pe rform some form of content hashing at the protocol level, so this tends to be more of a concern with proprietary cryptographic protocols and protocols from non-IETF stand ards bodies. Protocols like TLS 1.3 and DNSSEC use the Hash-then-Sign paradigm. In TL S 1.3 {{RFC8446}} CertificateVerify messages, the content that is covered under the s ignature includes the transcript hash output ({{Section 4.4.1 of RFC8446}}) while DNS SEC {{RFC4034}} uses it to provide origin authentication and integrity assurance serv ices for DNS data. Similarly, the Cryptographic Message Syntax (CMS) {{?RFC5652}} inc ludes a mandatory message digest step before invoking the signature algorithm.
In the case of ML-DSA, it internally incorporates the necessary hash operations as pa rt of its signing algorithm. ML-DSA directly takes the original message, applies a ha sh function internally, and then uses the resulting hash value for the signature gene ration process. In the case of SLH-DSA, it internally performs randomized message com pression using a keyed hash function that can process arbitrary length messages. In t he case of FN-DSA, the SHAKE-256 hash function is used as part of the signature proce ss to derive a digest of the message being signed. In the case of ML-DSA, it internally incorporates the necessary hash operations as pa rt of its signing algorithm. ML-DSA directly takes the original message, applies a ha sh function internally, and then uses the resulting hash value for the signature gene ration process. In the case of SLH-DSA, it internally performs randomized message com pression using a keyed hash function that can process arbitrary length messages. In t he case of FN-DSA, the SHAKE-256 hash function is used as part of the signature proce ss to derive a digest of the message being signed.
Therefore, ML-DSA, FN-DSA, and SLH-DSA offer enhanced security over the traditional H ash-then-Sign paradigm because by incorporating dynamic key material into the message digest, a pre-computed hash collision on the message to be signed no longer yields a signature forgery. Applications requiring the performance and bandwidth benefits of Hash-then-Sign may still pre-hash at the protocol level prior to invoking ML-DSA, FN- DSA, or SLH-DSA, but protocol designers should be aware that doing so re-introduces t he weakness that hash collisions directly yield signature forgeries. Signing the full un-digested message is recommended where applications can tolerate it. Therefore, ML-DSA, FN-DSA, and SLH-DSA offer enhanced security over the traditional H ash-then-Sign paradigm because, by incorporating dynamic key material into the messag e digest, a pre-computed hash collision on the message to be signed no longer yields a signature forgery. Applications requiring the performance and bandwidth benefits of Hash-then-Sign may still pre-hash at the protocol level prior to invoking ML-DSA, FN -DSA, or SLH-DSA, but protocol designers should be aware that doing so reintroduces t he weakness that hash collisions directly yield signature forgeries. Signing the full un-digested message is recommended where applications can tolerate it.
# NIST Recommendations for Security / Performance Tradeoffs {#RecSecurity} # NIST Recommendations for Security and Performance Trade-offs {#RecSecurity}
This information is a re-print of information provided in the NIST PQC project {{NIST }} as of the time this document is published. The Table 2 denotes the five security l evels provided by NIST for PQC algorithms. Neither NIST nor the IETF make any specifi c recommendations about which security level to use. In general, protocols will inclu de algorithm choices at multiple levels so that users can choose the level appropriat e to their policies and data classification, similar to how organizations today choos e which size of RSA key to use. The security levels are defined as requiring computat ional resources comparable to or greater than an attack on AES (128, 192 and 256) and SHA2/SHA3 algorithms, i.e., exhaustive key recovery for AES and optimal collision se arch for SHA2/SHA3. This information is a reprint of information provided in the NIST PQC project {{NIST} } as of the time this document is published. {{security-levels-table}} denotes the fi ve security levels provided by NIST for PQC algorithms. Neither NIST nor the IETF mak es any specific recommendations about which security level to use. In general, protoc ols will include algorithm choices at multiple levels so that users can choose the le vel appropriate to their policies and data classification, similar to how organizatio ns today choose which size of RSA key to use. The security levels are defined as requ iring computational resources comparable to or greater than an attack on AES (128, 19 2, and 256) and SHA2/SHA3 algorithms, i.e., exhaustive key recovery for AES and optim al collision search for SHA2/SHA3.
| PQ Security Level | AES/SHA(2/3) hardness | PQC Algorithm | | PQ Security Level | AES/SHA(2/3) hardness | PQC Algorithm |
| ----------------- | ----------------------------------------------- | ------------- --------------------------------------------- | | ----------------- | ----------------------------------------------- | ------------- --------------------------------------------- |
| 1 | AES-128 (exhaustive key recovery) | ML-KEM-51 2, FN-DSA-512, SLH-DSA-SHA2/SHAKE-128f/s | | 1 | AES-128 (exhaustive key recovery) | ML-KEM-51 2, FN-DSA-512, SLH-DSA-SHA2/SHAKE-128f/s |
| 2 | SHA-256/SHA3-256 (collision search) | ML-DSA-44 | | 2 | SHA-256/SHA3-256 (collision search) | ML-DSA-44 |
| 3 | AES-192 (exhaustive key recovery) | ML-KEM-76 8, ML-DSA-65, SLH-DSA-SHA2/SHAKE-192f/s | | 3 | AES-192 (exhaustive key recovery) | ML-KEM-76 8, ML-DSA-65, SLH-DSA-SHA2/SHAKE-192f/s |
| 4 | SHA-384/SHA3-384 (collision search) | No algorithm tested at this level | | 4 | SHA-384/SHA3-384 (collision search) | No algorithm tested at this level |
| 5 | AES-256 (exhaustive key recovery) | ML-KEM-1024, FN-DSA-1024, ML-DSA-87, SLH-DSA-SHA2/SHAKE-256f/s | | 5 | AES-256 (exhaustive key recovery) | ML-KEM-1024, FN-DSA-1024, ML-DSA-87, SLH-DSA-SHA2/SHAKE-256f/s |
{: #security-levels-table}
The SLH-DSA-x-yf/s "f/s" in the above table denotes whether SLH-DSA is using SHAKE or SHA-2 as an underlying hash function "x" and whether it is the fast (f) or small (s) version for "y" bit AES security level. Refer to {{?I-D.ietf-lamps-cms-sphincs-plus} } for further details on SLH-DSA algorithms. The SLH-DSA-x-yf/s "f/s" in the above table denotes whether SLH-DSA is using SHAKE or SHA-2 as an underlying hash function "x" and whether it is the fast (f) or small (s) version for "y" bit AES security level. Refer to {{?RFC9814}} for further details on SLH-DSA algorithms.
The following table compares the signature sizes for different SLH-DSA algorithm cate gories at equivalent security levels, using the "simple" version. The categories incl ude "(f)" for fast signature generation, and "(s)" for smaller signature size and fas ter verification, although with slower signature generation. Both SHA-256 and SHAKE-2 56 parameterizations produce the same signature sizes and are therefore included toge ther in the table. The following table compares the signature sizes for different SLH-DSA algorithm cate gories at equivalent security levels using the "simple" version. The categories inclu de "f" for fast signature generation and "s" for smaller signature size and faster ve rification, although with slower signature generation. Both SHA-256 and SHAKE-256 par ameterizations produce the same signature sizes and are therefore included together i n the table.
| PQ Security Level | Algorithm | Public key size (in bytes) | Private key size (in b ytes) | Signature size (in bytes) | | PQ Security Level | Algorithm | Public key size (in bytes) | Private key size (in b ytes) | Signature size (in bytes) |
| ------------------ | --------------------------------- | -------------------------- - | --------------------------- | ------------------------------------ | | ------------------ | --------------------------------- | -------------------------- - | --------------------------- | ------------------------------------ |
| 1 | SLH-DSA-{SHA2,SHAKE}-128f | 32 | 64 | 17088 | | 1 | SLH-DSA-{SHA2,SHAKE}-128f | 32 | 64 | 17088 |
| 1 | SLH-DSA-{SHA2,SHAKE}-128s | 32 | 64 | 7856 | | 1 | SLH-DSA-{SHA2,SHAKE}-128s | 32 | 64 | 7856 |
| 3 | SLH-DSA-{SHA2,SHAKE}-192f | 48 | 96 | 35664 | | 3 | SLH-DSA-{SHA2,SHAKE}-192f | 48 | 96 | 35664 |
| 3 | SLH-DSA-{SHA2,SHAKE}-192s | 48 | 96 | 16224 | | 3 | SLH-DSA-{SHA2,SHAKE}-192s | 48 | 96 | 16224 |
| 5 | SLH-DSA-{SHA2,SHAKE}-256f | 64 | 128 | 49856 | | 5 | SLH-DSA-{SHA2,SHAKE}-256f | 64 | 128 | 49856 |
| 5 | SLH-DSA-{SHA2,SHAKE}-256s | 64 | 128 | 29792 | | 5 | SLH-DSA-{SHA2,SHAKE}-256s | 64 | 128 | 29792 |
skipping to change at line 709 skipping to change at line 1404
| ------------------ | -------------------------- | --------------------------- | --- ------------------------ | ------------------------------------ | | ------------------ | -------------------------- | --------------------------- | --- ------------------------ | ------------------------------------ |
| 1 | ML-KEM-512 | 800 | 1632 | 768 | | 1 | ML-KEM-512 | 800 | 1632 | 768 |
| 1 | FN-DSA-512 | 897 | 1281 | 666 | | 1 | FN-DSA-512 | 897 | 1281 | 666 |
| 2 | ML-DSA-44 | 1312 | 2560 | 2420 | | 2 | ML-DSA-44 | 1312 | 2560 | 2420 |
| 3 | ML-KEM-768 | 1184 | 2400 | 1088 | | 3 | ML-KEM-768 | 1184 | 2400 | 1088 |
| 3 | ML-DSA-65 | 1952 | 4032 | 3309 | | 3 | ML-DSA-65 | 1952 | 4032 | 3309 |
| 5 | FN-DSA-1024 | 1793 | 2305 | 1280 | | 5 | FN-DSA-1024 | 1793 | 2305 | 1280 |
| 5 | ML-KEM-1024 | 1568 | 3168 | 1588 | | 5 | ML-KEM-1024 | 1568 | 3168 | 1588 |
| 5 | ML-DSA-87 | 2592 | 4896 | 4627 | | 5 | ML-DSA-87 | 2592 | 4896 | 4627 |
# Comparing PQC KEMs/Signatures vs. Traditional KEMs (KEXs)/Signatures {#Comparisons} <!-- [rfced] We note that the title of Section 12 contains the only
abbreviation of KEX in the document. May we rephrase the section title as
follows? Or should "(KEXs)" be left here as is?
This section provides two tables for comparison of different KEMs and signatures resp Original:
ectively, in the traditional and post-quantum scenarios. These tables focus on the se Comparing PQC KEMs/Signatures vs. Traditional KEMs (KEXs)/Signatures
cret key sizes, public key sizes, and ciphertext/signature sizes for the PQC algorith
ms and their traditional counterparts of similar security levels.
The first table compares traditional vs. PQC KEMs in terms of security, public and pr Perhaps:
ivate key sizes, and ciphertext sizes. Comparing PQC KEMs/Signatures and Traditional KEMs/Signatures
-->
# Comparing PQC KEMs/Signatures and Traditional KEMs (KEXs)/Signatures {#Comparisons}
This section provides two tables for comparison of different KEMs and signatures, res
pectively, in the traditional and post-quantum scenarios. These tables focus on the s
ecret key sizes, public key sizes, and ciphertext/signature sizes for the PQC algorit
hms and their traditional counterparts of similar security levels.
The first table compares traditional and PQC KEMs in terms of security, public and pr
ivate key sizes, and ciphertext sizes.
| PQ Security Level | Algorithm | Public key size (in bytes) | Priv ate key size (in bytes) | Ciphertext size (in bytes) | | PQ Security Level | Algorithm | Public key size (in bytes) | Priv ate key size (in bytes) | Ciphertext size (in bytes) |
| ----------------- | -------------------------- | --------------------------- | ---- ----------------------- | ------------------------------------ | | ----------------- | -------------------------- | --------------------------- | ---- ----------------------- | ------------------------------------ |
| Traditional | P256_HKDF_SHA-256 | 65 | 32 | 65 | | Traditional | P256_HKDF_SHA-256 | 65 | 32 | 65 |
| Traditional | P521_HKDF_SHA-512 | 133 | 66 | 133 | | Traditional | P521_HKDF_SHA-512 | 133 | 66 | 133 |
| Traditional | X25519_HKDF_SHA-256 | 32 | 32 | 32 | | Traditional | X25519_HKDF_SHA-256 | 32 | 32 | 32 |
| 1 | ML-KEM-512 | 800 | 1632 | 768 | | 1 | ML-KEM-512 | 800 | 1632 | 768 |
| 3 | ML-KEM-768 | 1184 | 2400 | 1088 | | 3 | ML-KEM-768 | 1184 | 2400 | 1088 |
| 5 | ML-KEM-1024 | 1568 | 3168 | 1568 | | 5 | ML-KEM-1024 | 1568 | 3168 | 1568 |
The next table compares traditional vs. PQC signature schemes in terms of security, p ublic, private key sizes, and signature sizes. The next table compares traditional and PQC signature schemes in terms of security, p ublic, private key sizes, and signature sizes.
| PQ Security Level | Algorithm | Public key size (in bytes) | Priv ate key size (in bytes) | Signature size (in bytes) | | PQ Security Level | Algorithm | Public key size (in bytes) | Priv ate key size (in bytes) | Signature size (in bytes) |
| ----------------- | -------------------------- | --------------------------- | ---- ----------------------- | ------------------------------------ | | ----------------- | -------------------------- | --------------------------- | ---- ----------------------- | ------------------------------------ |
| Traditional | RSA2048 | 256 | 256 | 256 | | Traditional | RSA2048 | 256 | 256 | 256 |
| Traditional | ECDSA-P256 | 64 | 32 | 64 | | Traditional | ECDSA-P256 | 64 | 32 | 64 |
| 1 | FN-DSA-512 | 897 | 1281 | 666 | | 1 | FN-DSA-512 | 897 | 1281 | 666 |
| 2 | ML-DSA-44 | 1312 | 2560 | 2420 | | 2 | ML-DSA-44 | 1312 | 2560 | 2420 |
| 3 | ML-DSA-65 | 1952 | 4032 | 3309 | | 3 | ML-DSA-65 | 1952 | 4032 | 3309 |
| 5 | FN-DSA-1024 | 1793 | 2305 | 1280 | | 5 | FN-DSA-1024 | 1793 | 2305 | 1280 |
| 5 | ML-DSA-87 | 2592 | 4896 | 4627 | | 5 | ML-DSA-87 | 2592 | 4896 | 4627 |
As is clear from the above table, PQC KEMs and signature schemes typically have signi ficantly larger keys and ciphertexts/signatures than their traditional counterparts. These increased key and signatures sizes could introduce problems in protocols. As an example, IKEv2 uses UDP as the transport for its messages. One challenge with integr ating a PQC KEM into IKEv2 is that IKE fragmentation cannot be utilized in the initia l IKE_SA_INIT exchange. To address this issue, {{!RFC9242}} introduces a solution by defining a new exchange called the "Intermediate Exchange" which can be fragmented us ing the IKE fragmentation mechanism. {{!RFC9370}} then uses this Intermediate Exchang e to carry out the PQC key exchange after the initial IKEv2 exchange and before the I KE_AUTH exchange. Another example from {{SP-1800-38C}} section 6.3.3 shows that incre ased key and signature sizes cause protocol key exchange messages to span more networ k packets, therefore it results in a higher total loss probability per packet. In los sy network conditions, this may increase the latency of the key exchange. As is clear from the above table, PQC KEMs and signature schemes typically have signi ficantly larger keys and ciphertexts/signatures than their traditional counterparts. These increased key and signatures sizes could introduce problems in protocols. As an example, the Internet Key Exchange Protocol Version 2 (IKEv2) uses UDP as the transp ort protocol for its messages. One challenge with integrating a PQC KEM into IKEv2 is that IKE fragmentation cannot be utilized in the initial IKE_SA_INIT exchange. To ad dress this issue, {{!RFC9242}} introduces a solution by defining a new exchange calle d the "Intermediate Exchange", which can be fragmented using the IKE fragmentation me chanism. {{!RFC9370}} then uses this Intermediate Exchange to carry out the PQC key e xchange after the initial IKEv2 exchange and before the IKE_AUTH exchange. Another ex ample from Section 6.3.3 of {{SP-1800-38C}} shows that increased key and signature si zes cause protocol key exchange messages to span more network packets, which results in a higher total loss probability per packet. In lossy network conditions, this may increase the latency of the key exchange.
# Post-Quantum and Traditional Hybrid Schemes {#PQT} # Post-Quantum and Traditional (PQ/T) Hybrid Schemes {#PQT}
The migration to PQC is unique in the history of modern digital cryptography in that neither the traditional algorithms nor the post-quantum algorithms are fully trusted to protect data for the required lifetimes. The traditional algorithms, such as RSA a nd ECDH, will fall to quantum cryptanalysis, while the post-quantum algorithms face u ncertainty about the underlying mathematics, compliance issues, unknown vulnerabiliti es, and hardware and software implementations that have not had sufficient maturing t ime to rule out traditional cryptanalytic attacks and implementation bugs. The migration to PQC is unique in the history of modern digital cryptography in that neither the traditional algorithms nor the post-quantum algorithms are fully trusted to protect data for the required lifetimes. The traditional algorithms, such as RSA a nd ECDH, will fall to quantum cryptanalysis, while the post-quantum algorithms face u ncertainty about the underlying mathematics, compliance issues, unknown vulnerabiliti es, and hardware and software implementations that have not had sufficient maturing t ime to rule out traditional cryptanalytic attacks and implementation bugs.
During the transition from traditional to post-quantum algorithms, there may be a des ire or a requirement for protocols that use both algorithm types. {{?I-D.ietf-pquip-p qt-hybrid-terminology}} defines the terminology for the post-quantum and traditional (PQ/T) hybrid schemes. During the transition from traditional to post-quantum algorithms, there may be a des ire or a requirement for protocols that use both algorithm types. {{?RFC9794}} define s the terminology for PQ/T hybrid schemes.
## PQ/T Hybrid Confidentiality ## PQ/T Hybrid Confidentiality
The PQ/T Hybrid Confidentiality property can be used to mitigate both "harvest now, d ecrypt now" and HNDL attacks described in {{timeline}}. If the PQ portion were to hav e a flaw, the traditional (T) algorithm, which is secure against today’s attackers, p revents immediate decryption ("harvest now, decrypt now"). If the T algorithm is brok en in the future by CRQCs, the PQ portion, assuming it remains secure, prevents later decryption ("harvest now, decrypt later"). A hybrid construction therefore provides confidentiality as long as at least one component remains secure. Two types of hybrid key agreement schemes are discussed below. The PQ/T Hybrid Confidentiality property can be used to mitigate both "harvest now, d ecrypt now" and HNDL attacks described in {{timeline}}. If the PQ portion were to hav e a flaw, the traditional (T) algorithm, which is secure against today's attackers, p revents immediate decryption ("harvest now, decrypt now"). If the T algorithm is brok en in the future by CRQCs, the PQ portion, assuming it remains secure, prevents later decryption (i.e., HNDL). A hybrid construction therefore provides confidentiality as long as at least one component remains secure. Two types of hybrid key agreement sch emes are discussed below.
* Concatenated hybrid key agreement scheme: The final shared secret that will be used Concatenated hybrid key agreement scheme:
as an input of the key derivation function is the result of the concatenation of the : The final shared secret that will be used as an input of the key derivation functio
secrets established with each key agreement scheme. For example, in {{?I-D.ietf-tls- n is the result of the concatenation of the secrets established with each key agreeme
hybrid-design}}, the client uses the TLS supported groups extension to advertise supp nt scheme. For example, in {{I-D.ietf-tls-hybrid-design}}, the client uses the TLS su
ort for a PQ/T hybrid scheme, and the server can select this group if it supports the pported groups extension to advertise support for a PQ/T hybrid scheme, and the serve
scheme. The hybrid-aware client and server establish a hybrid secret by concatenatin r can select this group if it supports the scheme. The hybrid-aware client and server
g the two shared secrets, which is used as the shared secret in the existing TLS 1.3 establish a hybrid secret by concatenating the two shared secrets, which is used as
key schedule. the shared secret in the existing TLS 1.3 key schedule.
* Cascaded hybrid key agreement scheme: The final shared secret is computed by applyi Cascaded hybrid key agreement scheme:
ng as many iterations of the key derivation function as the number of key agreement s : The final shared secret is computed by applying as many iterations of the key deriv
chemes composing the hybrid key agreement scheme. For example, {{?RFC9370}} extends t ation function as the number of key agreement schemes composing the hybrid key agreem
he Internet Key Exchange Protocol Version 2 (IKEv2) to allow one or more PQC algorith ent scheme. For example, {{?RFC9370}} extends IKEv2 to allow one or more PQC algorith
ms in addition to the traditional algorithm to derive the final IKE SA keys using the ms in addition to the traditional algorithm to derive the final IKE Security Associat
cascade method as explained in Section 2.2.2 of {{?RFC9370}}. ion (SA) keys using the cascade method as explained in {{Section 2.2.2 of ?RFC9370}}.
Various instantiations of these two types of hybrid key agreement schemes have been e xplored. One must be careful when selecting which hybrid scheme to use. The chosen sc heme for protocols like TLS 1.3 {{?I-D.ietf-tls-hybrid-design}} has IND-CCA2 robustne ss. That is, IND-CCA2 security is guaranteed for the scheme as long as at least one o f the component algorithms is IND-CCA2 secure. Various instantiations of these two types of hybrid key agreement schemes have been e xplored. One must be careful when selecting which hybrid scheme to use. The chosen sc heme for protocols like TLS 1.3 {{I-D.ietf-tls-hybrid-design}} has IND-CCA2 robustnes s. That is, IND-CCA2 security is guaranteed for the scheme as long as at least one of the component algorithms is IND-CCA2 secure.
## PQ/T Hybrid Authentication ## PQ/T Hybrid Authentication
The PQ/T hybrid authentication property provides resilience against catastrophic brea ks or unforeseen vulnerabilities in PQC algorithms, allowing systems additional time to stabilize before migrating fully to pure PQ deployments. The PQ/T hybrid authentication property provides resilience against catastrophic brea ks or unforeseen vulnerabilities in PQC algorithms, allowing systems additional time to stabilize before migrating fully to pure PQ deployments.
This property ensures authentication using a PQ/T hybrid scheme, as long as at least one component algorithm remains secure. For example, a PQ/T hybrid certificate {{?I-D .ietf-lamps-pq-composite-sigs}} can be employed to facilitate a PQ/T hybrid authentic ation protocol. However, a PQ/T hybrid authentication protocol does not need to use a PQ/T hybrid certificate; separate certificates could be used for individual componen t algorithms {{?I-D.ietf-lamps-cert-binding-for-multi-auth}}. When separate certifica tes are used, it may be possible for attackers to take them apart or put them togethe r in unexpected ways, including enabling cross-protocol attacks. The exact risks this presents are highly dependent on the protocol and use case, so a full security analy sis is needed. Best practices for ensuring that pairs of certificates are only used a s intended are discussed in more detail in {{COMPOSITE}} and {{REUSE}} of this docume nt. This property ensures authentication using a PQ/T hybrid scheme as long as at least o ne component algorithm remains secure. For example, a PQ/T hybrid certificate {{I-D.i etf-lamps-pq-composite-sigs}} can be employed to facilitate a PQ/T hybrid authenticat ion protocol. However, a PQ/T hybrid authentication protocol does not need to use a P Q/T hybrid certificate; separate certificates could be used for individual component algorithms {{?RFC9763}}. When separate certificates are used, it may be possible for attackers to take them apart or put them together in unexpected ways, including enabl ing cross-protocol attacks. The exact risks this presents are highly dependent on the protocol and use case, so a full security analysis is needed. Best practices for ens uring that pairs of certificates are only used as intended are discussed in more deta il in Sections {{COMPOSITE}}{: format="counter"} and {{REUSE}}{: format="counter"} of this document.
The frequency and duration of system upgrades and the time when CRQCs will become wid ely available need to be weighed to determine whether and when to support the PQ/T Hy brid Authentication property. The frequency and duration of system upgrades and the time when CRQCs will become wid ely available need to be weighed to determine whether and when to support the PQ/T Hy brid Authentication property.
## Hybrid Cryptographic Algorithm Combinations: Considerations and Approaches ## Hybrid Cryptographic Algorithm Combinations: Considerations and Approaches
### Hybrid Cryptographic Combinations ### Hybrid Cryptographic Combinations
It is also possible to use more than two algorithms together in a hybrid scheme, with various methods for combining them. For post-quantum transition purposes, the combin ation of a post-quantum algorithm with a traditional algorithm is the most straightfo rward and recommended. The use of multiple post-quantum algorithms with different mat hematical bases has also been considered. Combining algorithms in a way that requires both to be used together ensures stronger security, while combinations that do not r equire both will sacrifice security but offer other benefits like backwards compatibi lity and crypto agility. Including a traditional key alongside a post-quantum key oft en has minimal bandwidth impact. It is also possible to use more than two algorithms together in a hybrid scheme, with various methods for combining them. For post-quantum transition purposes, the combin ation of a post-quantum algorithm with a traditional algorithm is the most straightfo rward and recommended. The use of multiple post-quantum algorithms with different mat hematical bases has also been considered. Combining algorithms in a way that requires both to be used together ensures stronger security, while combinations that do not r equire both will sacrifice security but offer other benefits like backwards compatibi lity and crypto agility. Including a traditional key alongside a post-quantum key oft en has minimal bandwidth impact.
### Composite Keys in Hybrid Schemes {#COMPOSITE} ### Composite Keys in Hybrid Schemes {#COMPOSITE}
When combining keys in an "and" mode, it may make more sense to consider them to be a single composite key, instead of two keys. This generally requires fewer changes to various components of PKI ecosystems, many of which are not prepared to deal with two keys or dual signatures. To those protocol- or application-layer parsers, a "composi te" algorithm composed of two "component" algorithms is simply a new algorithm, and s upport for adding new algorithms generally already exists. Treating multiple "compone nt" keys as a single "composite" key also has security advantages such as preventing cross-protocol reuse of the individual component keys and guarantees about revoking o r retiring all component keys together at the same time, especially if the composite is treated as a single object all the way down into the cryptographic module. When combining keys in an "and" mode, it may make more sense to consider them to be a single composite key instead of two keys. This generally requires fewer changes to v arious components of PKI ecosystems, many of which are not prepared to deal with two keys or dual signatures. To those protocol- or application-layer parsers, a "composit e" algorithm composed of two "component" algorithms is simply a new algorithm, and su pport for adding new algorithms generally already exists. Treating multiple "componen t" keys as a single "composite" key also has security advantages, such as preventing cross-protocol reuse of the individual component keys and guarantees about revoking o r retiring all component keys together at the same time, especially if the composite is treated as a single object all the way down into the cryptographic module.
All that needs to be done is to standardize the formats of how the two keys from the two algorithms are combined into a single data structure, and how the two resulting s ignatures or KEMs are combined into a single signature or KEM. The answer can be as s imple as concatenation, if the lengths are fixed or easily determined. At the time th is document is published, security research is ongoing as to the security properties of concatenation-based composite signatures and KEMs vs. more sophisticated signature and KEM combiners, and in which protocol contexts those simpler combiners are suffic ient. All that needs to be done is to standardize the formats of how the two keys from the two algorithms are combined into a single data structure and how the two resulting si gnatures or KEMs are combined into a single signature or KEM. The answer can be as si mple as concatenation if the lengths are fixed or easily determined. At the time this document is published, security research is ongoing as to the security properties of concatenation-based composite signatures and KEMs versus more sophisticated signatur e and KEM combiners and protocol contexts in which those simpler combiners are suffic ient.
One last consideration is the specific pairs of algorithms that can be combined. A re cent trend in protocols is to only allow a small number of "known good" configuration s that make sense, often referred to in cryptography as a "ciphersuite", instead of a llowing arbitrary combinations of individual configuration choices that may interact in dangerous ways. The current consensus is that the same approach should be followed for combining cryptographic algorithms, and that "known good" pairs should be explic itly listed ("explicit composite"), instead of just allowing arbitrary combinations o f any two cryptographic algorithms ("generic composite"). One last consideration is the specific pairs of algorithms that can be combined. A re cent trend in protocols is to only allow a small number of "known good" configuration s that make sense, often referred to in cryptography as a "ciphersuite", instead of a llowing arbitrary combinations of individual configuration choices that may interact in dangerous ways. The current consensus is that the same approach should be followed for combining cryptographic algorithms and that "known good" pairs should be explici tly listed ("explicit composite") instead of just allowing arbitrary combinations of any two cryptographic algorithms ("generic composite").
The same considerations apply when using multiple certificates to transport a pair of related keys for the same subject. Exactly how two certificates should be managed in order to avoid some of the pitfalls mentioned above is still an active area of inves tigation. Using two certificates keeps the certificate tooling simple and straightfor ward, but in the end simply moves the problems with requiring that both certs are int ended to be used as a pair, must produce two signatures which must be carried separat ely, and both must validate, to the certificate management layer, where addressing th ese concerns in a robust way can be difficult. The same considerations apply when using multiple certificates to transport a pair of related keys for the same subject. Exactly how two certificates should be managed in order to avoid some of the pitfalls mentioned above is still an active area of inves tigation. Using two certificates keeps the certificate tooling simple and straightfor ward, but in the end, simply moves the problems with requiring that both certificates are intended to be used as a pair, must produce two signatures that must be carried separately, and both must validate, to the certificate management layer, where addres sing these concerns in a robust way can be difficult.
At least one scheme has been proposed that allows the pair of certificates to exist a At least one scheme has been proposed that allows the pair of certificates to exist a
s a single certificate when being issued and managed, but dynamically split into indi s a single certificate when being issued and managed but dynamically split into indiv
vidual certificates when needed ({{?I-D.draft-bonnell-lamps-chameleon-certs}}). idual certificates when needed (see {{I-D.bonnell-lamps-chameleon-certs}}).
<!-- [rfced] This sentence is difficult to follow, especially the phrase "with
requiring...must validate". How may we revise for clarity?
Current:
Using two certificates keeps the certificate tooling simple and
straightforward, but in the end simply moves the problems with
requiring that both certs are intended to be used as a pair, must
produce two signatures that must be carried separately, and both
must validate, to the certificate management layer, where addressing
these concerns in a robust way can be difficult.
Perhaps:
Using two certificates keeps the certificate tooling simple and
straightforward, but in the end, this simply moves problems (i.e., problems with
the requirement that both certificates be used as a pair, that
two signatures that must be carried separately, and that both
validate) to the certificate management layer, where addressing
these concerns in a robust way can be difficult.
-->
<!-- [rfced] Will readers understand "hybrids" and "a hybrid" in these
sentences? The document discusses "hybrid keys", "hybrid schemes", "hybrid
settings", etc.
Original:
However, key reuse becomes a large security problem within hybrids.
...
Therefore, it is recommended that
implementers either reuse the entire hybrid key as a whole, or
perform fresh key generation of all component keys per usage, and
must not take an existing key and reuse it as a component of a
hybrid.
...
Another potential application of hybrids bears mentioning, even
though it is not directly PQC-related. That is using hybrids to
navigate inter-jurisdictional cryptographic connections.
...
If "and" mode hybrids become standardized for the reasons mentioned
above,
-->
### Key Reuse in Hybrid Schemes {#REUSE} ### Key Reuse in Hybrid Schemes {#REUSE}
An important security note, particularly when using hybrid signature keys, but also t o a lesser extent hybrid KEM keys, is key reuse. In traditional cryptography, problem s can occur with so-called "cross-protocol attacks" when the same key can be used for multiple protocols; for example signing TLS handshakes and signing S/MIME emails. Wh ile it is not best-practice to reuse keys within the same protocol, for example using the same key for multiple S/MIME certificates for the same user, it is not generally catastrophic for security. However, key reuse becomes a large security problem withi n hybrids. An important security note, particularly when using hybrid signature keys, but also t o a lesser extent hybrid KEM keys, is key reuse. In traditional cryptography, problem s can occur with so-called "cross-protocol attacks" when the same key can be used for multiple protocols; for example, signing TLS handshakes and signing S/MIME emails. W hile it is not best practice to reuse keys within the same protocol, e.g., using the same key for multiple S/MIME certificates for the same user, it is not generally cata strophic for security. However, key reuse becomes a large security problem within hyb rids.
Consider an \{RSA, ML-DSA\} hybrid key where the RSA key also appears within a single -algorithm certificate. In this case, an attacker could perform a "stripping attack" where they take some piece of data signed with the \{RSA, ML-DSA\} key, remove the ML -DSA signature and present the data as if it was intended for the RSA only certificat e. This leads to a set of security definitions called "non-separability properties", which refers to how well the signature scheme resists various complexities of downgra de / stripping attacks {{?I-D.draft-ietf-pquip-hybrid-signature-spectrums}}. Therefor e, it is recommended that implementers either reuse the entire hybrid key as a whole, or perform fresh key generation of all component keys per usage, and must not take a n existing key and reuse it as a component of a hybrid. Consider an \{RSA, ML-DSA\} hybrid key where the RSA key also appears within a single -algorithm certificate. In this case, an attacker could perform a "stripping attack" where they take some piece of data signed with the \{RSA, ML-DSA\} key, remove the ML -DSA signature, and present the data as if it was intended for the RSA only certifica te. This leads to a set of security definitions called "non-separability properties", which refers to how well the signature scheme resists various complexities of downgr ade/stripping attacks {{I-D.ietf-pquip-hybrid-signature-spectrums}}. Therefore, it is recommended that implementers either reuse the entire hybrid key as a whole or perfo rm fresh key generation of all component keys per usage, and must not take an existin g key and reuse it as a component of a hybrid.
### Future Directions and Ongoing Research ### Future Directions and Ongoing Research
Many aspects of hybrid cryptography are still under investigation. LAMPS WG at IETF i s actively exploring the security properties of these combinations, and future standa rds will reflect the evolving consensus on these issues. Many aspects of hybrid cryptography are still under investigation. The LAMPS Working Group at IETF is actively exploring the security properties of these combinations, an d future standards will reflect the evolving consensus on these issues.
# Impact on Constrained Devices and Networks # Impact on Constrained Devices and Networks
PQC algorithms generally have larger keys, ciphertext, and signature sizes than tradi <!-- [rfced] Please review the parenthetical here. Is the intent of "(e.g.,
tional public key algorithms. This has particular impact on constrained devices that LAKE, Core)" to be "(e.g., in the LAKE and CoRE Working Groups)"?
operate with limited data rates. In the IoT space, these constraints have historicall
y driven significant optimization efforts in the IETF (e.g., LAKE, CoRE) to adapt sec
urity protocols to resource-constrained environments.
As the transition to PQC progresses, these environments will face similar challenges. Original:
Larger message sizes can increase handshake latency, raise energy consumption, and r In the IoT space, these constraints have historically driven
equire fragmentation logic. Work is ongoing in the IETF to study how PQC can be deplo significant optimization efforts in the IETF (e.g., LAKE, CoRE) to
yed in constrained devices (see {{?I-D.ietf-pquip-pqc-hsm-constrained}}). adapt security protocols to resource-constrained environments.
Perhaps:
In the IoT space, these constraints have historically driven
significant optimization efforts in the IETF (e.g., in the LAKE and CoRE
Working Groups) to
adapt security protocols to resource-constrained environments.
-->
PQC algorithms generally have larger keys, ciphertext, and signature sizes than tradi
tional public key algorithms. This has particular impact on constrained devices that
operate with limited data rates. In the Internet of Things (IoT) space, these constra
ints have historically driven significant optimization efforts in the IETF (e.g., LAK
E and CoRE) to adapt security protocols to resource-constrained environments.
As the transition to PQC progresses, these environments will face similar challenges.
Larger message sizes can increase handshake latency, raise energy consumption, and r
equire fragmentation logic. Work is ongoing in the IETF to study how PQC can be deplo
yed in constrained devices (see {{I-D.ietf-pquip-pqc-hsm-constrained}}).
# Security Considerations # Security Considerations
## Cryptanalysis ## Cryptanalysis
Traditional cryptanalysis exploits weaknesses in algorithm design, mathematical vulne rabilities, or implementation flaws, that are exploitable with classical (i.e. non-qu antum) hardware, whereas quantum cryptanalysis harnesses the power of CRQCs to solve specific mathematical problems more efficiently. Another form of quantum cryptanalysi s is "quantum side-channel" attacks. In such attacks, a device under threat is direct ly connected to a quantum computer, which then injects entangled or superimposed data streams to exploit hardware that lacks protection against quantum side-channels. Bot h pose threats to the security of cryptographic algorithms, including those used in P QC. Developing and adopting new cryptographic algorithms resilient against these thre ats is crucial for ensuring long-term security in the face of advancing cryptanalysis techniques. Traditional cryptanalysis exploits weaknesses in algorithm design, mathematical vulne rabilities, or implementation flaws that are exploitable with classical (i.e., non-qu antum) hardware, whereas quantum cryptanalysis harnesses the power of CRQCs to solve specific mathematical problems more efficiently. Quantum side-channel attacks are ano ther form of quantum cryptanalysis. In such attacks, a device under threat is directl y connected to a quantum computer, which then injects entangled or superimposed data streams to exploit hardware that lacks protection against quantum side channels. Both pose threats to the security of cryptographic algorithms, including those used in PQ C. It is crucial to develop and adopt new cryptographic algorithms resilient against these threats to ensure long-term security in the face of advancing cryptanalysis tec hniques.
Recent attacks on the side-channel implementations using deep learning based power an alysis have also shown that one needs to be cautious while implementing the required PQC algorithms in hardware. Two of the most recent works include one attack on ML-KEM {{KyberSide}} and one attack on Saber {{SaberSide}}. An evolving threat landscape po ints to the fact that lattice based cryptography is indeed more vulnerable to side-ch annel attacks as in {{SideCh}}, {{LatticeSide}}. Consequently, there were some mitiga tion techniques for side channel attacks that have been proposed as in {{Mitigate1}}, {{Mitigate2}}, and {{Mitigate3}}. Recent attacks on the side-channel implementations using deep learning-based power an alysis have also shown that one needs to be cautious while implementing the required PQC algorithms in hardware. Two of the most recent works include one attack on ML-KEM {{KyberSide}} and one attack on Saber {{SaberSide}}. An evolving threat landscape po ints to the fact that lattice-based cryptography is indeed more vulnerable to side-ch annel attacks as in {{SideCh}} and {{LatticeSide}}. Consequently, some mitigation tec hniques for side-channel attacks have been proposed; see {{Mitigate1}}, {{Mitigate2}} , and {{Mitigate3}}.
## Cryptographic Agility ## Cryptographic Agility
Cryptographic agility is recommended for both traditional and quantum cryptanalysis a s it enables organizations to adapt to emerging threats, adopt stronger algorithms, c omply with standards, and plan for long-term security in the face of evolving cryptan alytic techniques and the advent of CRQCs. Cryptographic agility is recommended for both traditional and quantum cryptanalysis a s it enables organizations to adapt to emerging threats, adopt stronger algorithms, c omply with standards, and plan for long-term security in the face of evolving cryptan alytic techniques and the advent of CRQCs.
Several PQC schemes are available that need to be tested; cryptography experts around the world are pushing for the best possible solutions, and the first standards that will ease the introduction of PQC are being prepared. It is of paramount importance a nd a call for imminent action for organizations, bodies, and enterprises to start eva luating their cryptographic agility, assess the complexity of implementing PQC into t heir products, processes, and systems, and develop a migration plan that achieves the ir security goals to the best possible extent. Several PQC schemes are available that need to be tested; cryptography experts around the world are pushing for the best possible solutions, and the first standards that will ease the introduction of PQC are being prepared. This is of paramount importance and is a call for imminent action for organizations, bodies, and enterprises to star t evaluating their cryptographic agility, assess the complexity of implementing PQC i nto their products, processes, and systems, and develop a migration plan that achieve s their security goals to the best possible extent.
An important and often overlooked step in achieving cryptographic agility is maintain ing a cryptographic inventory. Modern software stacks incorporate cryptography in num erous places, making it challenging to identify all instances. Therefore, cryptograph ic agility and inventory management take two major forms: First, application develope rs responsible for software maintenance should actively search for instances of hard- coded cryptographic algorithms within applications. When possible, they should design the choice of algorithm to be dynamic, based on application configuration. Second, a dministrators, policy officers, and compliance teams should take note of any instance s where an application exposes cryptographic configurations. These instances should b e managed either through organization-wide written cryptographic policies or automate d cryptographic policy systems. An important and often overlooked step in achieving cryptographic agility is maintain ing a cryptographic inventory. Modern software stacks incorporate cryptography in num erous places, making it challenging to identify all instances. Therefore, cryptograph ic agility and inventory management take two major forms. First, application develope rs responsible for software maintenance should actively search for instances of hard- coded cryptographic algorithms within applications. When possible, they should design the choice of algorithm to be dynamic, based on application configuration. Second, a dministrators, policy officers, and compliance teams should take note of any instance s where an application exposes cryptographic configurations. These instances should b e managed through either organization-wide written cryptographic policies or automate d cryptographic policy systems.
Numerous commercial solutions are available for both detecting hard-coded cryptograph ic algorithms in source code and compiled binaries, as well as providing cryptographi c policy management control planes for enterprise and production environments. Numerous commercial solutions are available for detecting hard-coded cryptographic al gorithms in source code and compiled binaries, as well as providing cryptographic pol icy management control planes for enterprise and production environments.
## Jurisdictional Fragmentation ## Jurisdictional Fragmentation
Another potential application of hybrids bears mentioning, even though it is not dire ctly PQC-related. That is using hybrids to navigate inter-jurisdictional cryptographi c connections. Traditional cryptography is already fragmented by jurisdiction: consid er that while most jurisdictions support Elliptic Curve Diffie-Hellman, those in the United States will prefer the NIST curves while those in Germany will prefer the Brai npool curves. China, Russia, and other jurisdictions have their own national cryptogr aphy standards. This situation of fragmented global cryptography standards is unlikel y to improve with PQC. If "and" mode hybrids become standardized for the reasons ment ioned above, then one could imagine leveraging them to create "ciphersuites" in which a single cryptographic operation simultaneously satisfies the cryptographic requirem ents of both endpoints. Another potential application of hybrids bears mentioning, even though it is not dire ctly related to PQC: using hybrids to navigate inter-jurisdictional cryptographic con nections. Traditional cryptography is already fragmented by jurisdiction. Consider th at while most jurisdictions support ECDH, those in the United States will prefer the NIST curves while those in Germany will prefer the Brainpool curves. China, Russia, a nd other jurisdictions have their own national cryptography standards. This situation of fragmented global cryptography standards is unlikely to improve with PQC. If "and " mode hybrids become standardized for the reasons mentioned above, then one could im agine leveraging them to create ciphersuites in which a single cryptographic operatio n simultaneously satisfies the cryptographic requirements of both endpoints.
## Hybrid Key Exchange and Signatures: Bridging the Gap Between Post-Quantum and Trad itional Cryptography ## Hybrid Key Exchange and Signatures: Bridging the Gap Between PQ/T Cryptography
Post-quantum algorithms selected for standardization are relatively new and they have not been subject to the same depth of study as traditional algorithms. PQC implement ations will also be new and therefore more likely to contain implementation bugs than the battle-tested crypto implementations that are relied on today. In addition, cert ain deployments may need to retain traditional algorithms due to regulatory constrain ts, for example FIPS {{SP-800-56C}} or PCI compliance {{PCI}}. Hybrid key exchange is recommended to enhance security against the "harvest now, decrypt later" attack. Add itionally, hybrid signatures provide for time to react in the case of the announcemen t of a devastating attack against any one algorithm, while not fully abandoning tradi tional cryptosystems. Post-quantum algorithms selected for standardization are relatively new and have not been subject to the same depth of study as traditional algorithms. PQC implementation s will also be new and therefore more likely to contain implementation bugs than the battle-tested crypto implementations that are relied on today. In addition, certain d eployments may need to retain traditional algorithms due to regulatory constraints, e .g., FIPS {{SP-800-56C}} or Payment Card Industry (PCI) compliance {{PCI}}. Hybrid ke y exchange is recommended to enhance security against the HNDL attack. Additionally, hybrid signatures provide for time to react in the case of the announcement of a deva stating attack against any one algorithm, while not fully abandoning traditional cryp tosystems.
Hybrid key exchange performs both a classical and a post-quantum key exchange in para llel. It provides security redundancy against potential weaknesses in PQC algorithms, allows for a gradual transition of trust in PQC algorithms, and, in backward-compati ble designs, enables gradual adoption without breaking compatibility with existing sy stems. For instance, in TLS 1.3, a hybrid key exchange can combine a widely supported classical algorithm, such as X25519, with a post-quantum algorithm like ML-KEM. This allows legacy clients to continue using the classical algorithm while enabling upgra ded clients to proceed with hybrid key exchange. In contrast, overhead-spreading hybr id designs focus on reducing the PQ overhead. For example, approaches like those desc ribed in {{?I-D.hale-mls-combiner}} amortize PQ costs by selectively applying PQ upda tes in key exchange processes, allowing systems to balance security and efficiency. T his strategy ensures a post-quantum secure channel while keeping the overhead managea ble, making it particularly suitable for constrained environments. Hybrid key exchange performs both a classical and a post-quantum key exchange in para llel. It provides security redundancy against potential weaknesses in PQC algorithms, allows for a gradual transition of trust in PQC algorithms, and, in backward-compati ble designs, enables gradual adoption without breaking compatibility with existing sy stems. For instance, in TLS 1.3, a hybrid key exchange can combine a widely supported classical algorithm, such as X25519, with a post-quantum algorithm like ML-KEM. This allows legacy clients to continue using the classical algorithm while enabling upgra ded clients to proceed with hybrid key exchange. In contrast, overhead-spreading hybr id designs focus on reducing the PQ overhead. For example, approaches like those desc ribed in {{I-D.hale-mls-combiner}} amortize PQ costs by selectively applying PQ updat es in key exchange processes, allowing systems to balance security and efficiency. Th is strategy ensures a post-quantum secure channel while keeping the overhead manageab le, making it particularly suitable for constrained environments.
While some hybrid key exchange options introduce additional computational and bandwid th overhead, the impact of traditional key exchange algorithms (e.g., key size) is ty pically small, helping to keep the overall increase in resource usage manageable for most systems. In highly constrained environments, however, those hybrid key exchange protocols may be impractical due to their higher resource requirements compared to pu re post-quantum or traditional key exchange approaches. However, some hybrid key exch ange designs distribute the PQC overhead, making them more suitable for constrained e nvironments. The choice of hybrid key exchange design depends on the specific system requirements and use case, so the appropriate approach may vary. While some hybrid key exchange options introduce additional computational and bandwid th overhead, the impact of traditional key exchange algorithms (e.g., key size) is ty pically small, helping to keep the overall increase in resource usage manageable for most systems. In highly constrained environments, however, those hybrid key exchange protocols may be impractical due to their higher resource requirements compared to pu re post-quantum or traditional key exchange approaches. However, some hybrid key exch ange designs distribute the PQC overhead, making them more suitable for constrained e nvironments. The choice of hybrid key exchange design depends on the specific system requirements and use case, so the appropriate approach may vary.
## Caution: Ciphertext commitment in KEM vs. DH ## Caution: Ciphertext Commitment in KEM vs. DH
The ciphertext generated by a KEM is not necessarily directly linked to the shared se cret it produces. KEMs allow for multiple ciphertexts to encapsulate the same shared secret, which enables flexibility in key management without enforcing a strict one-to -one correspondence between ciphertexts and shared secrets. This allows for secret re use across different recipients, sessions, or operational contexts without the need f or new secrets for each use, simplifying key distribution and reducing computational overhead. In contrast, cryptographic schemes like Diffie-Hellman inherently link the public key to the derived shared secret, meaning any change in the public key results in a different shared secret. The ciphertext generated by a KEM is not necessarily directly linked to the shared se cret it produces. KEMs allow for multiple ciphertexts to encapsulate the same shared secret, which enables flexibility in key management without enforcing a strict one-to -one correspondence between ciphertexts and shared secrets. This allows for secret re use across different recipients, sessions, or operational contexts without the need f or new secrets for each use, simplifying key distribution and reducing computational overhead. In contrast, cryptographic schemes like Diffie-Hellman inherently link the public key to the derived shared secret, meaning any change in the public key results in a different shared secret.
# IANA Considerations # IANA Considerations
This document has no IANA considerations. This document has no IANA actions.
# Further Reading & Resources # Further Reading and Resources
A good book on modern cryptography is Serious Cryptography, 2nd Edition, by Jean-Phil ippe Aumasson, ISBN 9781718503847. A good book on modern cryptography is "Serious Cryptography, 2nd Edition" by Jean-Phi lippe Aumasson {{Serious-Crypt}}.
The Open Quantum Safe (OQS) Project {{OQS}} is an open-source project that aims to su pport the transition to quantum-resistant cryptography. The Open Quantum Safe (OQS) Project {{OQS}} is an open-source project that aims to su pport the transition to quantum-resistant cryptography.
The IETF's PQUIP Working Group {{PQUIP-WG}} maintains a list of PQC-related protocol work within the IETF. The IETF's PQUIP Working Group {{PQUIP-WG}} maintains a list of PQC-related protocol work within the IETF.
--- back --- back
<!-- [rfced] References
a) FYI - We note that draft-hale-mls-combiner-01 has been replaced with
draft-ietf-mls-combiner-02. Should this reference entry be updated
accordingly? Note that the title has changed.
Original:
[I-D.hale-mls-combiner]
Joël, Hale, B., Mularczyk, M., and X. Tian, "Flexible
Hybrid PQ MLS Combiner", Work in Progress, Internet-Draft,
draft-hale-mls-combiner-01, 26 September 2024,
<https://datatracker.ietf.org/doc/html/draft-hale-mls-
combiner-01>.
Perhaps:
[PQ-MLS]
Tian, X., Hale, B., Mularczyk, M., and J. Alwen, "Amortized
PQ MLS Combiner", Work in Progress, Internet-Draft,
draft-ietf-mls-combiner-02, 20 October 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-mls-combiner-02>.
b) The URLs in both of the following reference entries point to the same
URL. Should the URL for [BIKE] be updated to something else? We do not see
BIKE mentioned at this URL. Note that we found the following page for BIKE
(Bit Flipping Key Encapsulation): https://bikesuite.org/.
Current:
[BIKE] "BIKE", <http://pqc-hqc.org/>.
...
[HQC] "HQC", <http://pqc-hqc.org/>.
Perhaps (update URL for [BIKE]):
[BIKE] "BIKE", <https://bikesuite.org/>.
...
[HQC] "HQC", <http://pqc-hqc.org/>.
c) We updated many of the reference entries in the references section to
include titles, URLs, and additional publication information that may be
helpful for future readers. Please review and let us know if you have any
concerns or corrections.
-->
# Acknowledgements # Acknowledgements
{:numbered="false"} {:numbered="false"}
This document leverages text from an earlier draft by Paul Hoffman. Thanks to Dan Win g, Florence D, Thom Wiggers, Sophia Grundner-Culemann, Panos Kampanakis, Ben S, Sofia Celi, Melchior Aelmans, Falko Strenzke, Deirdre Connolly, Hani Ezzadeen, Britta Hale , Scott Rose, Hilarie Orman, Thomas Fossati, Roman Danyliw, Mike Bishop, Mališa Vučin ić, Éric Vyncke, Deb Cooley, Dirk Von Hugo and Daniel Van Geest for the discussion, r eview and comments. <!-- [rfced] Acknowledgements:
In particular, the authors would like to acknowledge the contributions to this docume a) Would you like the cite the draft here? If so, please provide the
nt by Kris Kwiatkowski. draftstring so we can create a reference entry.
Original:
This document leverages text from an earlier draft by Paul Hoffman.
b) Would you like to include a surname for "Florence D" and "Ben S" rather
than just an initial? If so, please provide the surnames.
Original:
This document leverages text from an earlier draft by Paul Hoffman.
Thanks to Dan Wing, Florence D, Thom Wiggers, Sophia Grundner-
Culemann, Panos Kampanakis, Ben S, Sofia Celi, Melchior Aelmans,
Falko Strenzke, Deirdre Connolly, Hani Ezzadeen, Britta Hale, Scott
Rose, Hilarie Orman, Thomas Fossati, Roman Danyliw, Mike Bishop,
Mališa Vučinić, Éric Vyncke, Deb Cooley, Dirk Von Hugo and Daniel Van
Geest for the discussion, review, and comments.
-->
This document leverages text from an earlier Internet-Draft by {{{Paul Hoffman}}}. Th
anks to {{{Dan Wing}}}, {{{Florence D}}}, {{{Thom Wiggers}}}, {{{Sophia Grundner-Cule
mann}}}, {{{Panos Kampanakis}}}, {{{Ben S}}}, {{{Sofia Celi}}}, {{{Melchior Aelmans}}
}, {{{Falko Strenzke}}}, {{{Deirdre Connolly}}}, {{{Hani Ezzadeen}}}, {{{Britta Hale}
}}, {{{Scott Rose}}}, {{{Hilarie Orman}}}, {{{Thomas Fossati}}}, {{{Roman Danyliw}}},
{{{Mike Bishop}}}, {{{Mališa Vučinić}}}, {{{Éric Vyncke}}}, {{{Deb Cooley}}}, {{{Dir
k Von Hugo}}}, and {{{Daniel Van Geest}}} for the discussion, review and comments.
In particular, the authors would like to acknowledge the contributions to this docume
nt by {{{Kris Kwiatkowski}}}.
<!-- [rfced] Would you like to make use of <sup> for superscript in this
document? In the HTML and PDF, it appears as superscript. In the text output,
<sup> generates a^b, which was used in the original document. (Note that if
you would like to use <sup>, we will make the update once the file is
converted to RFCXML.)
Instances in document:
2^{64}
2^c
2^{(128−c)/2}
2^64
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers. For example,
please consider whether "tradition" should be updated for clarity. While the
NIST website
<https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-librar
y/nist-technical-series-publications-author-instructions#table1>
indicates that this term is potentially biased, it is also ambiguous.
"Tradition" is a subjective term, as it is not the same for everyone. -->
<!-- [rfced] Abbreviations
a) We note that KEM is expanded in the following ways in this document:
key encapsulation mechanism (KEM)
key encapsulation method (KEM)
key establishment method (KEM)
Should the latter two (one instance each) be updated to "key encapsulation
mechanism (KEM)" (most common in document) or simply "KEM" (as the
abbreviation was already expanded)? Or should these be handled in some other
way so that the expansion of KEM is consistent in the document?
b) How should "MAC" be expanded? As "Media Access Control (MAC)", "Message
Authentication Code (MAC)", or something else?
Original:
It is crucial for the reader to understand that when
the word "PQC" is mentioned in the document, it means asymmetric
cryptography (or public key cryptography), and not any symmetric
algorithms based on stream ciphers, block ciphers, hash functions,
MACs, etc., which are less vulnerable to quantum computers.
c) We have updated the expansion for "AEAD" below as follows. Please review
and let us know any objections.
Original:
HPKE [RFC9180] works with a combination of KEMs, KDFs, and
authenticated encryption with additional data (AEAD) schemes.
Current:
HPKE [RFC9180] works with a combination of KEMs, KDFs, and
Authenticated Encryption with Associated Data (AEAD) schemes.
d) How should "BIKE" be expanded? As "Bit Flipping Key Encapsulation"?
Original:
Examples include all the unbroken NIST Round 4 finalists: Classic
McEliece, HQC (selected by NIST for standardization), and [BIKE].
e) We have added expansions for the following abbreviations upon first
use per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
Security Association (SA)
Trusted Execution Environments (TEEs)
Hash to Obtain Random Subset with Trees (HORST)
Hashed Message Authentication Code (HMAC)
Internet of Things (IoT)
Payment Card Industry (PCI)
-->
<!-- [rfced] We see both of the following forms used in the document. Should
these be uniform? If so, please let us know which form is preferred.
hash-then-sign
Hash-then-Sign
-->
 End of changes. 217 change blocks. 
313 lines changed or deleted 1139 lines changed or added

This html diff was produced by rfcdiff 1.48.