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.