ml-dsa

Post-quantum authentication to origins is now supported (opens in new tab)

Cloudflare has added post-quantum authentication to Authenticated Origin Pulls (AOP) and Custom Origin Trust Store (COTS), enabling fully post-quantum-secure mutual TLS between Cloudflare and customer origins. The implementation uses ML-DSA signatures, with ML-DSA-44 recommended for most deployments. This marks the first milestone in Cloudflare’s roadmap toward full post-quantum security by 2029. ## Why Cloudflare-to-Origin Authentication Is Different - A proxied request typically involves: - Visitor to Cloudflare - Cloudflare to the customer’s origin - Post-quantum encryption already protects both connections. - Authentication requirements differ for the origin connection because: - Cloudflare controls the client side and can use connection pooling to amortize signature costs. - Cloudflare and customers already have an account-based trust relationship. - Custom PKIs can be used without relying on public WebPKI constraints such as intermediate certificates and Certificate Transparency. - Cloudflare is pursuing Merkle Tree Certificates for visitor-to-Cloudflare authentication, but ML-DSA can be deployed sooner for origin connections. ## ML-DSA Support - Cloudflare supports all FIPS 204 ML-DSA parameter sets: - ML-DSA-44 - ML-DSA-65 - ML-DSA-87 - ML-DSA-44 is recommended for most applications because it offers the best performance while providing NIST category 2 security strength. ## Custom Origin Trust Store - In Full (strict) SSL mode, Cloudflare validates origin certificates against trusted public CAs and Cloudflare’s Origin CA. - COTS lets customers replace that default trust store with a set of customer-controlled CAs. - Customers can now upload ML-DSA CAs. - Cloudflare will trust origin certificates that chain to those ML-DSA CAs. - COTS requires Advanced Certificate Manager. ## Authenticated Origin Pulls - AOP enables mutual TLS, allowing origins to require requests to come from Cloudflare. - It is available on all Cloudflare plan levels. - Per-zone and per-hostname AOP configurations now support ML-DSA certificates and private keys. - Private keys must be uploaded in FIPS 204 seed format. - The global AOP configuration does not yet support this capability and will require additional work. ## Preventing Downgrade Attacks - Simply supporting post-quantum algorithms is not enough if classical authentication methods remain trusted. - An attacker with the ability to forge classical credentials could force a connection to downgrade to a quantum-vulnerable mechanism. - Origins must therefore remove trust in classical authentication mechanisms where appropriate. - Cloudflare’s AOP and COTS configuration guidance explains how to prevent these downgrades. ## Configuration Requirements - Certificate generation requires OpenSSL 3.5.0 or later. - ML-DSA private keys must use the FIPS 204 seed-only encoding. - Customers configure: - An ML-DSA CA and origin certificate chain for COTS - An ML-DSA client certificate and private key for AOP - Configuration can be performed through the Cloudflare API, with dashboard instructions available in the developer documentation. Cloudflare customers needing post-quantum protection for origin connections should combine ML-DSA-based COTS and AOP, explicitly remove trust in classical alternatives, and use ML-DSA-44 unless their security requirements justify a larger parameter set.

Why we cannot wait for better post-quantum signature algorithms (opens in new tab)

RSA and elliptic-curve signatures will eventually be vulnerable to sufficiently powerful quantum computers, so organizations cannot delay migration until ideal post-quantum algorithms arrive. ML-KEM already protects much of Cloudflare’s traffic from “harvest now, decrypt later” attacks, while ML-DSA is currently the practical choice for post-quantum signatures despite its larger keys and signatures. Better schemes are being developed, but they will not be standardized and deployable in time for the initial transition. ## The urgency of post-quantum migration - NIST standardized ML-KEM encryption and ML-DSA signatures in 2024 after an eight-year international competition. - Cloudflare reports that most of its traffic already uses ML-KEM. - Post-quantum signatures are still needed to protect authentication systems from quantum-enabled attacks. - Cloudflare aims to be fully post-quantum secure by 2029. - The authors argue that deployment must begin with currently available algorithms: - “You go to war with the algorithms you have, not the ones you wish you had.” - Future signature research remains important because current options have substantial performance, size, and implementation drawbacks. ## Comparing the candidate signature algorithms - The candidates include: - Existing classical algorithms such as RSA and elliptic-curve signatures, which are quantum-vulnerable. - ML-DSA and other already standardized or soon-to-be-standardized post-quantum schemes. - Nine candidates advancing to the third round of NIST’s signatures on-ramp. - Comparisons focus on variants relevant to TLS at the 128-bit security level. - The measurements cover: - Public-key and signature sizes. - Signing and verification speed. - Implementation concerns and side-channel resistance. - Some algorithms have important operational limitations: - FN-DSA and SQIsign are difficult to implement with fast, timing-safe signing. - LMS requires state to be maintained securely between signatures. - Certain SLH-DSA variants are intended for only a limited number of signatures. ## No single post-quantum “all-star” - Ed25519 remains the strongest all-around performer when quantum resistance is ignored. - It offers particularly favorable: - Public-key size. - Signature size. - Signing speed. - Its verification is slower than some alternatives but remains fast enough for most applications. - Post-quantum schemes instead fall into two broad groups: - **Specialists:** Excellent on particular metrics but unsuitable for general use because of other weaknesses. - **Generalists:** More balanced schemes such as ML-DSA, which avoid extreme weaknesses but do not match elliptic curves overall. ## SQIsign: compact signatures with slow signing - SQIsign is attractive for bandwidth-sensitive applications: - 148-byte signatures. - 65-byte public keys. - Smaller than RSA-2048 and close to elliptic-curve sizes. - Its disadvantages include: - High mathematical and implementation complexity. - Slow signing and verification. - Difficulty achieving efficient, timing-side-channel-resistant signing. - Progress since 2024 has significantly simplified SQIsign and improved verification speed. - Secure signing is still unlikely to become fast enough for common online uses such as TLS handshakes. - It may be better suited to offline applications where signing is infrequent and verification matters more, including: - Certificate-authority signatures. - DNSSEC. - SQIsign is based on isogenies, a category that attracted concern after SIKE was catastrophically broken. - The authors distinguish the schemes: - SIKE already had known security concerns and used problematic torsion points. - SQIsign does not use those torsion points. - The best known SQIsign attacks are generic brute-force attacks, resembling attacks against well-chosen elliptic curves. - Isogeny mathematics still has a large attack surface, but the authors consider SQIsign’s security outlook stronger than that of structured multivariate schemes. - The authors see significant promise in SQIsign but caution against standardizing it prematurely. The practical recommendation is to begin the post-quantum transition with ML-DSA rather than waiting for smaller or faster alternatives. New schemes such as SQIsign may eventually serve specialized use cases, but they must undergo further cryptanalysis, standardization, implementation work, and deployment before they can replace today’s available algorithms.