# Roadmap Request: Post Quantum Cryptography **URL:** \ **Category:** Feature Requests\ **Created:** [December 31, 2024, 4:18pm UTC](https://community.letsencrypt.org/t/roadmap-request-post-quantum-cryptography/231143 "2024-12-31T16:18:42Z")\ **Posts on this page:** 14\ **Page:** 1
**Author:** ![AnAnonName](https://avatars.discourse-cdn.com/v4/letter/a/85e7bf/32.png) [@AnAnonName](https://community.letsencrypt.org/u/AnAnonName)\ **Post date:** [December 31, 2024, 4:18pm UTC](https://community.letsencrypt.org/t/roadmap-request-post-quantum-cryptography/231143/1 "2024-12-31T16:18:42Z")
NIST has made progress in Post Quantum Cryptography since discussed here: > [@Preparing for quantum safe crypto systems](https://community.letsencrypt.org/t/preparing-for-quantum-safe-crypto-systems/204611): > > D… - Cloudflare has a TLS hybrid implementation!: [https://pq.cloudflareresearch.com](https://pq.cloudflareresearch.com) - A recent Cloudflare blog post: [A look at the latest post-quantum signature standardization candidates](https://blog.cloudflare.com/another-look-at-pq-signatures/) - Google: [https://cloud.google.com/security/resources/post-quantum-cryptography](https://cloud.google.com/security/resources/post-quantum-cryptography) - AniInteresting Google podcast: [EP164 Quantum Computing: Understanding the (very serious) Threat and Post-Quantum Cryptography](https://cloud.withgoogle.com/cloudsecurity/podcast/ep164-quantum-computing-understanding-the-very-serious-threat-and-post-quantum-cryptography) - Another Cloudflare blog post on **new** NIST standards: [https://blog.cloudflare.com/nists-first-post-quantum-standards](https://blog.cloudflare.com/nists-first-post-quantum-standards) - A separate project in the space: [PQConnect: Cryptography](https://www.pqconnect.net/crypto.html) So NIST, Google, Apple, Cloudflare, and others are taking this seriously. A lot of folks look to LetsEncrypt to be a leader here. The standards may change, but it's prudent to be up-to-date. Thank you for your consideration for the roadmap! ---
**Author:** ![Bruce5051](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/bruce5051/32/76576_2.png) [@Bruce5051](https://community.letsencrypt.org/u/Bruce5051)\ **Post date:** [December 31, 2024, 5:51pm UTC](https://community.letsencrypt.org/t/roadmap-request-post-quantum-cryptography/231143/2 "2024-12-31T17:51:29Z")
Hi @AnAnonName, There has been some discussion on the forum here - [Preparing for quantum safe crypto systems - #6 by Nummer378](https://community.letsencrypt.org/t/preparing-for-quantum-safe-crypto-systems/204611/6) - [Policy on Issuance Chain Changes - #10 by mcpherrinm](https://community.letsencrypt.org/t/policy-on-issuance-chain-changes/223073/10) - [What is the roadmap for intermediate certificates with 3072bit RSA or EC 384bit (tightened BSI regulations)? - #8 by mcpherrinm](https://community.letsencrypt.org/t/what-is-the-roadmap-for-intermediate-certificates-with-3072bit-rsa-or-ec-384bit-tightened-bsi-regulations/215296/8) - [Future of cross signed roots - #4 by mcpherrinm](https://community.letsencrypt.org/t/future-of-cross-signed-roots/213705/4) - [TLS 1.2 and TLS 1.3 need Curve25519 and Curve448 SSL certificates - #4 by mcpherrinm](https://community.letsencrypt.org/t/tls-1-2-and-tls-1-3-need-curve25519-and-curve448-ssl-certificates/200775/4) ---
**Author:** ![Nummer378](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/nummer378/32/49862_2.png) [@Nummer378](https://community.letsencrypt.org/u/Nummer378)\ **Post date:** [December 31, 2024, 6:03pm UTC](https://community.letsencrypt.org/t/roadmap-request-post-quantum-cryptography/231143/3 "2024-12-31T18:03:23Z")
While you can of course add anything to the roadmap, I find it a bit early for Let's Encrypt to state anything until the cryptographic community has sorted things out a bit more. There's currently no clear guidance on what a Post-Quantum PKI should look like. There's no code in the common HSM modules etc. Let's Encrypt can't just do what they want, there are rules to follow and a hastily written PQ PKI may result in a security disaster. There's currently a push for PQ-hybrid key exchanges in security protocols (SSH, TLS, IPSec). That's relevant because of [store now, decrypt later](https://en.wikipedia.org/wiki/Harvest_now%2C_decrypt_later) attacks. It is assumed that there are presently various actors at play who store large quantities of secure sessions (e.g. TLS) to decrypt them at a later point in time using a Quantum Computer. It is therefore relevant to defend against these attacks now, as they're possibly happening right now. The PKI system on the other hand cannot be attacked after-the-fact, because it provides authentication, which can only be broken live. Therefore, the security community is currently focussed on securing the key exchange. Adding PQ secure authentication will probably happen at a later point. There's still a lot of work to be done on designing this PQ PKI scheme, and it's important that this is done with great care - or you will end up with a system that's not secure at all. It's important to understand that our security knowledge on the PQ algorithms is still... thin. For instance, NIST was relatively close to standardizing the `Rainbow` PQ signature scheme, up until this paper came along: [Breaking Rainbow Takes a Weekend on a Laptop](https://eprint.iacr.org/2022/214) (The scheme was withdrawn in a coordinated manner shortly before Beullen's work was made public) ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [December 31, 2024, 7:09pm UTC](https://community.letsencrypt.org/t/roadmap-request-post-quantum-cryptography/231143/4 "2024-12-31T19:09:26Z")
> [@AnAnonName](#): > > A lot of folks look to LetsEncrypt to be a leader here. The standards may change, but it's prudent to be up-to-date. "Unfortunately", every publicly trusted CA, thus including Let's Encrypt, needs to abide by the CA/Browser Forum Baseline Requirements. Those BR don't even accept Ed25519 yet, but just the NIST curves.. Until the BR have been changed to allow other algorithms, there's nothing LE can do. Except perhaps suggest a change to the BR. But any CA or browser member of the CA/B Forum can do that.. So while I understand your request, it's not up to Let's Encrypt to suddely implement these things. ---
**Author:** ![AnAnonName](https://avatars.discourse-cdn.com/v4/letter/a/85e7bf/32.png) [@AnAnonName](https://community.letsencrypt.org/u/AnAnonName)\ **Post date:** [December 31, 2024, 8:21pm UTC](https://community.letsencrypt.org/t/roadmap-request-post-quantum-cryptography/231143/5 "2024-12-31T20:21:53Z")
FYI, The August, 2024 NIST standards, for reference: > **[NIST Releases First 3 Finalized Post-Quantum Encryption Standards](https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards)** > > NIST is encouraging computer system administrators to begin transitioning to the new standards as soon as possible. ---
**Author:** ![jvanasco](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jvanasco/32/55900_2.png) [@jvanasco](https://community.letsencrypt.org/u/jvanasco)\ **Post date:** [December 31, 2024, 11:08pm UTC](https://community.letsencrypt.org/t/roadmap-request-post-quantum-cryptography/231143/6 "2024-12-31T23:08:58Z")
Just to put some of what @Nummer378 wrote in context: The Cloudflare research is on Key Agreement within the TLS Handshake; that is independent of x509 Certificates. The NIST research they cited, and later linked to, is also regarding Key Agreement and digest computing within the TLS protocol. This is all stuff that will eventually be implemented by the servers/gateways/CDNs that ISRG runs the LetsEncrypt service on. This stuff is all independent of the Certificates themselves. While some of the new research deals with calculating digests, LetsEncrypt's digests are communicated through TLS encrypted payloads between the server and client - so there isn't much of an immediate concern there. The current weak spots in the ecosystem, and the immediate target of improvements, are all in the key exchanges. In terms of changes to Certificates (such as key types), that is driven by the CA/B forum baseline requirements. Extensions or changes to the ACME protocol would require a mix of IETF support and CA/B Forum acceptance. TLDR on that is that we're not able to see any change on those things unless there is hotfix to a compromise, or several members make a coordinated push to fasttrack a new standard. LetsEncrypt staff have made it clear they want to fasttrack new PQ standards once the ecosystem is more stable - things are simply at a place now where there is a 99.9% chance all their work would be experimental R&D that is immediately obsoleted. ---
**Author:** ![impurify](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/impurify/32/85395_2.png) [@impurify](https://community.letsencrypt.org/u/impurify)\ **Post date:** [January 24, 2025, 4:36pm UTC](https://community.letsencrypt.org/t/roadmap-request-post-quantum-cryptography/231143/7 "2025-01-24T16:36:09Z")
This is a common source of user confusion. To add to the good information from @Nummer378 and @jvanasco, here is a practical view for immediate use: You can and should deploy post-quantum encryption on your website _today_. I am currently working on that (and on a website about post-quantum encryption). “All” you need is to link your webserver or TLS terminator with an SSL/TLS library that supports post-quantum KEX (key exchange). BoringSSL has had full support since “Implement X25519MLKEM768 for TLS” authored 2024-08-23, committed 2024-08-27: [https://boringssl.googlesource.com/boringssl/+/7fb4d3da5082225c7180267e9daad291887ce982](https://boringssl.googlesource.com/boringssl/+/7fb4d3da5082225c7180267e9daad291887ce982) My preliminary testing shows that BoringSSL at its current HEAD seems to support both standard ML-KEM as `SSL_GROUP_X25519_MLKEM768` in the source, and the draft `SSL_GROUP_X25519_KYBER768_DRAFT00` that has some support from many web browsers in the wild. I haven’t yet tried this on a functioning webserver—only in the `bssl` shell tool. I am busy patching BoringSSL to set policies that prefer or enforce PQ-KEX, among other things. (Beware that BoringSSL disobeys the old-style OpenSSL cipher/KEX preferences for TLS 1.3; it’s non-obvious unless you read the source. I should have a fix for this on Github soon, if I stop writing all this stuff.) At the time of this writing 2025-01-24, this OpenSSL issue is still open: > > > In preparation for a possible implementation of the evolving standard https://ww…w.ietf.org/archive/id/draft-kwiatkowski-tls-ecdhe-mlkem-02.html this is to suggest implementing provider-based generic hybrid key management and KEM operation enabling instantiation for the implementation of the standard proposal above. > > Design proposal: > \- The key manager shall maintain two generic EVP\_PKEY structures, incl. public and private key material, e.g., generating two keys instead of one when requested, responding to all key management operations triggering corresponding actions on both objects; the reported security strength should be the maximum of the two constituent security strengths as the KEM logic (see below) must ensure both constituent KEM operations are successful before considering the hybrid operation to be successful; the returned encoded public key shall be the concatenation of the constituent encoded public keys (configurable order). > \- The KEM logic shall enable operation of these two EVP\_PKEYs as a single KEM in the following way: Do two KEM encap/decap operations instead of one, encapsulating/decapsulating the concatenation of the two shared secrets as per the draft standard above, but be configurable to adapt easily to changes to the draft standard listed above (e.g., order of concatenation). > > Code evolution proposal: > Implementation of this may be aided by utilizing the generic code available in https://github.com/openssl/openssl/blob/master/providers/implementations/keymgmt/template\_kmgmt.c and https://github.com/openssl/openssl/blob/master/providers/implementations/kem/template\_kem.c; any PR implementing this issue is initially invited to be targeted towards the "ml-kem" feature branch in preparation of instantiation with MLKEM768 and classic KEM algorithms as constituent key types. Tests for this generic implementation of course could utilize pre-existing KEM algorithms, too (e.g., P256\_X25519), but a focus on X25519MLKEM768 and SecP256r1MLKEM768 is preferable. > > Feedback to this proposal solicited, particularly from @paulidale For this reason, I am switching to BoringSSL with my own patches. To round out this quick review of how you can use post-quantum encryption _right now_, GnuPG has supported hybrid PQC with NIST standard ML-KEM [since GnuPG v2.5.1 released 2024-09-12](https://lists.gnupg.org/pipermail/gnupg-announce/2024q3/000485.html)—only 30 days after NIST published the final FIPS-203. You need that for your personal communications. And you should set this in your OpenSSH configs on both client and server: ```nohighlight KexAlgorithms sntrup761x25519-sha512@openssh.com,sntrup761x25519-sha512,mlkem768x25519-sha256 ``` Omit the latter two if you have OpenSSH below v9.9. If needed temporarily to allow other KEX for sites that don’t yet support any of these, use `Host` blocks. OpenSSH has supported PQ-KEX since _2022_. All of this pertains only to post-quantum _encryption_. As Nummber said, this will protect data intercepted for future decryption, whether by [governments](https://en.wikipedia.org/wiki/Massive_Data_Repository) or by [unofficial criminals](https://www.technologyreview.com/2021/11/03/1039171/hackers-quantum-computers-us-homeland-security-cryptography/). There is absolutely no security need for post-quantum signatures in TLS at this time: Large quantum computers do not yet exist, and a potential future attacker cannot go back in time to forge signatures to tamper with TLS connections in the present. ---
**Author:** ![ghen](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/ghen/32/49729_2.png) [@ghen](https://community.letsencrypt.org/u/ghen)\ **Post date:** [January 24, 2025, 5:58pm UTC](https://community.letsencrypt.org/t/roadmap-request-post-quantum-cryptography/231143/8 "2025-01-24T17:58:47Z")
> [@impurify](#): > > At the time of this writing 2025-01-24, this OpenSSL issue is still open: Active development is taking place on the [ml-kem feature branch](https://github.com/openssl/openssl/tree/feature/ml-kem) (as well as [ml-dsa](https://github.com/openssl/openssl/tree/feature/ml-dsa)), and this will be part of [OpenSSL 3.5](https://github.com/openssl/openssl/milestone/48) to be released in April. In the meantime you can play with [oqs-provider](https://github.com/open-quantum-safe/oqs-provider/) for current OpenSSL 3.x. ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [January 24, 2025, 6:59pm UTC](https://community.letsencrypt.org/t/roadmap-request-post-quantum-cryptography/231143/9 "2025-01-24T18:59:14Z")
> [@impurify](#): > > and a potential future attacker cannot go back in time to forge signatures to tamper with TLS connections in the present That's not really the issue currently, [harvest now, decrypt later](https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later) is an issue though. To some extent. 🙂 By the way, key exchange _is_ part of TLS 😉 And also: browsers would also need to support any post-quantum key exchange, not just the webserver. ---
**Author:** ![ghen](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/ghen/32/49729_2.png) [@ghen](https://community.letsencrypt.org/u/ghen)\ **Post date:** [January 24, 2025, 7:30pm UTC](https://community.letsencrypt.org/t/roadmap-request-post-quantum-cryptography/231143/10 "2025-01-24T19:30:05Z")
> [@Osiris](#): > > That's not really the issue currently, [harvest now, decrypt later](https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later) is an issue though. To some extent. 🙂 That's exactly what @Impurify was arguing. 🙂 Securing key exchange (for encryption) is the priority now, not signatures (for authentication). > [@Osiris](#): > > And also: browsers would also need to support any post-quantum key exchange, not just the webserver. Chrome (and derivatives, including Edge) and Firefox support X25519MLKEM768 now (and until recently X25519Kyber768Draft00). ---
**Author:** ![Nummer378](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/nummer378/32/49862_2.png) [@Nummer378](https://community.letsencrypt.org/u/Nummer378)\ **Post date:** [January 24, 2025, 7:32pm UTC](https://community.letsencrypt.org/t/roadmap-request-post-quantum-cryptography/231143/11 "2025-01-24T19:32:11Z")
[Firefox and Chrome both have support](https://developers.cloudflare.com/ssl/post-quantum-cryptography/pqc-support/) for Kyber hybrid KEX in TLS ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [January 24, 2025, 7:38pm UTC](https://community.letsencrypt.org/t/roadmap-request-post-quantum-cryptography/231143/12 "2025-01-24T19:38:46Z")
> [@ghen](#): > > Chrome (and derivatives, including Edge) and Firefox support X25519MLKEM768 now (and until recently X25519Kyber768Draft00). > [@Nummer378](#): > > [Firefox and Chrome both have support](https://developers.cloudflare.com/ssl/post-quantum-cryptography/pqc-support/) for Kyber hybrid KEX in TLS Cool, I stand corrected. The [SSLLabs client test](https://clienttest.ssllabs.com:8443/ssltest/viewMyClient.html) apparently doesn't recognise the `ML-KEM768+X25519` codepoint `0x11ec` (hybrid ML-KEM) as such.. 😕 ---
**Author:** ![ghen](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/ghen/32/49729_2.png) [@ghen](https://community.letsencrypt.org/u/ghen)\ **Post date:** [January 24, 2025, 7:40pm UTC](https://community.letsencrypt.org/t/roadmap-request-post-quantum-cryptography/231143/13 "2025-01-24T19:40:50Z")
[SSL/TLS Client Test - TLS Fingerprinting - BrowserLeaks](https://browserleaks.com/tls) does. ---
**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\ **Post date:** [February 23, 2025, 7:41pm UTC](https://community.letsencrypt.org/t/roadmap-request-post-quantum-cryptography/231143/14 "2025-02-23T19:41:35Z")
Closed on February 23, 2025, 7:41pm UTC This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.