ml-kem

3 posts

cloudflare

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.

cloudflare

Post-quantum encryption for Cloudflare IPsec is generally available (opens in new tab)

Cloudflare has made post-quantum encryption for its IPsec service generally available, using hybrid ML-KEM alongside classical Diffie-Hellman. The implementation protects WAN traffic against “harvest-now-decrypt-later” attacks and interoperates with Cisco and Fortinet hardware already deployed by customers. Cloudflare argues that broadly adopted, software-based standards—not specialized quantum key distribution hardware—are essential for achieving post-quantum security at Internet scale. ## Cloudflare IPsec and WAN Connectivity - Cloudflare IPsec is a WAN Network-as-a-Service connecting: - Data centers - Branch offices - Cloud VPCs - Cloudflare One SASE environments - Encrypted IPsec tunnels run over Cloudflare’s global IP Anycast network. - Customers receive simplified configuration, high availability, automatic traffic rerouting, and global network scale. ## Hybrid ML-KEM for IPsec - The new implementation uses hybrid ML-KEM, standardized as FIPS 203. - It addresses harvest-now-decrypt-later attacks, in which attackers collect encrypted traffic today and decrypt it once quantum computers can break current public-key cryptography. - ML-KEM is designed to run in software on standard processors and requires neither specialized hardware nor dedicated physical links. - The IETF draft `draft-ietf-ipsecme-ikev2-mlkem` combines: - A classical Diffie-Hellman exchange - A second ML-KEM exchange encrypted using keys derived from the first - Key material from both exchanges mixed into session keys for IPsec ESP traffic ## Interoperability with Network Hardware - Cloudflare initially tested its implementation against the strongSwan reference implementation. - General availability now includes interoperability testing with: - Cisco 8000 Series Secure Routers running version 26.1.1 or later - Fortinet FortiOS 7.6.6 or later - These devices can establish post-quantum Cloudflare IPsec tunnels without requiring new specialized networking hardware. ## Why IPsec Lagged Behind TLS - Hybrid ML-KEM reached TLS production roughly four years before a corresponding IPsec specification. - Cloudflare enabled hybrid post-quantum TLS key agreement in 2022, and more than two-thirds of human-generated TLS traffic to Cloudflare is now protected this way. - IPsec standardization moved more slowly partly because of continued interest in Quantum Key Distribution (QKD). - Cloudflare criticizes QKD as unsuitable for Internet-scale deployment because it: - Requires specialized hardware and dedicated physical links - Does not provide authentication - Has limited cross-vendor interoperability - The NSA, Germany’s BSI, and the UK’s NCSC have warned against relying solely on QKD. ## Standards and Compatibility Challenges - RFC 9370, published in 2023, allowed multiple parallel key exchanges with classical Diffie-Hellman but did not define the specific ciphersuites to use. - Some vendors introduced incompatible or non-NIST-standardized ciphersuites, creating “ciphersuite bloat.” - Cloudflare’s implementation does not currently interoperate with Palo Alto Networks’ earlier RFC 9370-based implementation. - The newer ML-KEM draft fills this gap by defining hybrid ML-KEM as a standardized exchange mechanism. - Cloudflare hopes continued industry convergence will eventually enable interoperability with additional vendors, including Palo Alto Networks. ## Remaining Post-Quantum Work - Hybrid ML-KEM currently protects key establishment and data confidentiality. - IPsec still needs standardized post-quantum authentication mechanisms to defend live systems against quantum-enabled active attackers. - Cloudflare’s broader goal is full post-quantum security by 2029. Cloudflare recommends prioritizing interoperable, software-based post-quantum cryptography over niche QKD deployments. Organizations using supported Cisco or Fortinet branch hardware can begin protecting IPsec WAN traffic against future quantum decryption threats now.

cloudflare

Cloudflare One is the first SASE offering modern post-quantum encryption across the full platform (opens in new tab)

Cloudflare says Cloudflare One is now the first SASE platform to provide standards-compliant post-quantum hybrid ML-KEM encryption across Secure Web Gateway, Zero Trust, and WAN connectivity. The update extends protection to Cloudflare IPsec and Cloudflare One Appliance, addressing both current “harvest now, decrypt later” attacks and future quantum threats. The appliance support is generally available in version 2026.2.0, while Cloudflare IPsec is in closed beta. ## Post-Quantum Cryptography Is an Immediate Concern - NIST has set 2030 as the target for phasing out RSA and elliptic-curve cryptography in favor of post-quantum algorithms. - Cryptographic migrations can take decades, as demonstrated by vulnerabilities involving deprecated algorithms such as MD5. - Organizations face “harvest now, decrypt later” attacks, in which encrypted traffic is collected today for future decryption. - Cloudflare argues that built-in crypto agility makes it easier for enterprises to upgrade algorithms without redesigning remote-access and WAN infrastructure. ## Two Required Cryptographic Migrations - **Key establishment:** ML-KEM is becoming the standard post-quantum mechanism for establishing shared encryption keys. - Cloudflare uses hybrid ML-KEM, combining ML-KEM with classical ECDHE. - This approach protects against harvested traffic, requires no specialized hardware like quantum key distribution, and has limited performance impact. - More than 60% of human-generated TLS traffic reaching Cloudflare is already protected by hybrid ML-KEM. - **Digital signatures:** Post-quantum signatures protect against server impersonation but are larger than current ECC signatures. - Their migration is considered less urgent because they primarily defend against active quantum adversaries, which do not yet exist. - Cloudflare’s current IPsec work therefore focuses on post-quantum key establishment rather than signatures. ## Post-Quantum Protection for Cloudflare IPsec - Cloudflare upgraded its IPsec products to support hybrid ML-KEM within IKEv2. - Cloudflare IPsec creates encrypted tunnels from customer networks to Cloudflare’s global network. - IP Anycast routes tunnels to the nearest data center and automatically redirects traffic if a location becomes unavailable. - The service supports site-to-site WAN connectivity as well as outbound Internet connections. - Cloudflare One Appliance, which establishes Cloudflare IPsec connections, supports the upgrade starting with version 2026.2.0. - The Cloudflare IPsec upgrade remains in closed beta. ## Limitations of Earlier IPsec Approaches - IPsec has historically evolved differently from TLS because it is commonly used between devices from the same vendor, making interoperability less central. - RFC 8784 proposed combining long-lived pre-shared keys with Diffie-Hellman exchange. - While this can help protect against harvest-now-decrypt-later attacks, it does not provide forward secrecy against quantum attackers. - Quantum key distribution is also impractical for many enterprise environments because it requires specialized physical connectivity. Cloudflare’s recommendation is to begin post-quantum migration now, starting with hybrid ML-KEM for key establishment across Internet access, Zero Trust, and WAN connections.