--- breaks: false disqus: hackmd tags: Meeting Notes, OpenSSL, PQC keywords: - post-quantum crypto - quantum-safe crypto lintConfig: MD024: false --- # PQC/QSC Talking points [![hackmd-github-sync-badge](https://hackmd.io/n51fZMwFTaKBqPJwGazeAA/badge)](https://hackmd.io/n51fZMwFTaKBqPJwGazeAA) [TOC] ## NIST :us: 3rd round selection - [Announcement][NIST:PQC:R3End:Announcement] - [Report][NIST:PQC:R3End:Report] ### Key agreement (KEM) - Selected for standardization: - **CRYSTALS-KYBER** (lattice-based) > NIST negotiated with several third parties to enter into various > agreements to overcome potential adoption challenges posed by third-party > patents. > NIST expects to execute the various agreements prior to publishing the > standard. ==If the agreements are not executed by the end of 2022, NIST > may consider selecting **NTRU** instead of **KYBER**.== > > (pg. 18, [NIST IR 8413][NIST:PQC:R3End:Report]) - Advanced to Round 4: - **BIKE** (code-based) - **Classic McEliece** (code-based) - **HQC** (code-based) - **SIKE** (isogeny-based) Some warning/caveats related specifically to lattice-based crypto: - <https://ntruprime.cr.yp.to/warnings.html> - <https://ntruprime.cr.yp.to/latticerisks-20211031.pdf> ### Signatures - Selected for standardization: - **CRYSTALS-Dilithium** (lattice-based) - **Falcon** (lattice-based) - **SPHINCS+** (hash-based) - Announced a further **call for proposals** for _Digital Signature Algorithms with Short Signatures and Fast Verification_ - See <https://csrc.nist.gov/News/2022/pqc-candidates-to-be-standardized-and-round-4#new-call> #### NIST and Stateful hash-based signatures - [SP 800-208 (_Recommendation for Stateful Hash-Based Signature Schemes_)][NIST:HashSignatures] - [**LMS**][IETF:RFC:LMS] - [**XMSS**][IETF:RFC:XMSS] - OpenSSL API? ## BSI :de: recommendations [Migration to Post Quantum Cryptography (Recommendations for action by the BSI)][BSI:PQC:Recommendations] ### Key agreement (KEM) - **FrodoKEM** (lattice-based) - **Classic McEliece** (code-based) ### Signatures - Hash-based signatures for firmware updates (**LMS**/**XMSS**) - No explicit recommendation for other long-term signatures/certificates, yet ## ANSSI :fr: recommendations - <https://www.ssi.gouv.fr/en/publication/anssi-views-on-the-post-quantum-cryptography-transition/> - no specific algorithm selection, yet ## ENISA :flag-eu: recommendations - <https://www.enisa.europa.eu/publications/post-quantum-cryptography-current-state-and-quantum-mitigation> - no specific algorithm selection, yet - pretty much following NIST PQC process ## ETSI :flag-eu: migration strategies - [TR 103 619 V1.1.1 (2020-07)](https://www.etsi.org/deliver/etsi_tr/103600_103699/103619/01.01.01_60/tr_103619v010101p.pdf) - <https://www.etsi.org/newsroom/press-releases/1805-2020-08-etsi-releases-migration-strategies-and-recommendations-for-quantum-safe-schemes> - [ETSI Quantum-Safe Cryptography (QSC) working group](https://www.etsi.org/technologies/quantum-safe-cryptography) ## Misc ### Notable efforts - <https://github.com/open-quantum-safe/oqs-provider> ### Challenges - How to deal with hybrid schemes? - Individual dedicated hybrid primitives or programmatic combination? - What will hybryd signatures look like for X.509/Certificates? - PQ algs and ids for X.509: <https://datatracker.ietf.org/doc/draft-massimo-lamps-pq-sig-certificates/> - TLS changes - Do we have hardcoded maximum sizes for signatures/ciphertexts in `libssl` that could block providers? - Transparent (hybrid) KEM integration in TLS 1.3: <https://datatracker.ietf.org/doc/html/draft-ietf-tls-hybrid-design-04> - Variants like KEMTLS? - Delegated credentials for TLS - <https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-15> - <https://blog.cloudflare.com/keyless-delegation/> - <https://blog.mozilla.org/security/2019/11/01/validating-delegated-credentials-for-tls-in-firefox/> - ECH (Encrypted Client Hello) encapsulation alternatives? - <https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-14> - <https://blog.cloudflare.com/encrypted-client-hello/> - Limits of `libssl`/Provider pluggability - Pluggable Signatures: <https://github.com/openssl/openssl/issues/10512> - Pluggable TLS extensions? - Patents/Licenses > In addition, NIST has engaged with third parties that own various patents > directed to cryptography, and NIST acknowledges cooperation of ISARA, > Philippe Gaborit, Carlos Aguilar Melchor, the laboratory XLIM, the French > National Center for Scientific Research (CNRS), the University of Limoges, > and Dr. Jintai Ding. > NIST and these third parties are finalizing agreements such that the patents > owned by the third parties will not be asserted against implementers (or > end-users) of a standard for the selected cryptographic algorithm. NIST > appreciates the efforts of those who helped obtain this outcome and the > cooperation of the third parties. > > (pg. 17, [NIST IR 8413][NIST:PQC:R3End:Report]) - <https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/eZBzr4fgYMI> - <https://blog.cr.yp.to/20220129-plagiarism.html> - What are `PKCS#11` standardization plans for PQ/hybrid support? - `PKCS#11` `KEM` API? - how should they inform our Provider/Core API? ### More reading - <https://blog.cloudflare.com/nist-post-quantum-surprise/> --- [NIST:PQC:R3End:Report]: <https://csrc.nist.gov/publications/detail/nistir/8413/final> "NIST IR 8413 — Status Report on the Third Round of the NIST Post-Quantum Cryptography Standardization Process" [NIST:PQC:R3End:Announcement]: <https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/G0DoD7lkGPk/m/f3Hl0sh3AgAJ> "Announcement: The End of the 3rd Round - the First PQC Algorithms to be Standardized" [NIST:HashSignatures]: <https://csrc.nist.gov/publications/detail/sp/800-208/final> "SP 800-208 — Recommendation for Stateful Hash-Based Signature Schemes" [BSI:PQC:Recommendations]: <https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Crypto/Migration_to_Post_Quantum_Cryptography.html?nn=433196> "Migration to PQC — Recommendations for action by the BSI" [IETF:RFC:LMS]: <https://datatracker.ietf.org/doc/html/rfc8554> "IETF RFC 8554: Leighton-Micali Hash-Based Signatures" [IETF:RFC:XMSS]: <https://datatracker.ietf.org/doc/html/rfc8391> "IETF RFC 8391: XMSS: eXtended Merkle Signature Scheme"