post-quantum-cryptography

14 posts

cloudflare

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.

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

Cloudflare proudly joins the UK government's Cyber Resilience Pledge (opens in new tab)

Cloudflare has joined the UK government’s voluntary Cyber Resilience Pledge, supporting its focus on security governance, board accountability, and supply-chain protection. The company argues that these principles align with its existing approach: make security broadly accessible, use network-scale intelligence, apply protections internally, and be transparent about failures. It presents collective action and stronger baseline controls as essential to addressing rising cyberattacks and AI-enabled threats. ## The Cyber Resilience Pledge - The pledge encourages organizations to adopt foundational cybersecurity governance and make resilience a leadership responsibility. - It promotes comprehensive security coverage across supply chains. - Its central principles include: - Democratizing access to security - Leadership accountability - Radical transparency - Cloudflare sees the pledge as validation of principles it has followed for more than a decade. - The company highlights the need to address common weaknesses such as: - Unpatched systems - Weak access controls - Poor vendor oversight ## Rising Cybersecurity Risk - Cloudflare blocked an average of 234 billion cyber threats per day during the first quarter of 2026. - It recently mitigated a DDoS attack peaking at 31.4 Tbps. - By the end of 2025, the UK was the sixth-most targeted location globally for DDoS attacks. - Threat actors increasingly targeted application-layer services in financial services, aviation, and regional government. - UK survey data found that 43% of businesses and 28% of charities experienced a cyber incident in the previous year. - Frontier AI models are making attacks easier to automate, including vulnerability scanning and convincing phishing campaigns. ## Why Cyber Resilience Matters - Resilience is a business requirement because customers expect services to remain available, responsive, and trustworthy. - It extends beyond recovering from incidents to proactively: - Monitoring threat signals - Absorbing disruptions - Adapting systems after failures - Cloudflare views security controls as the foundation that makes resilience possible. ## Cloudflare’s Resilience Architecture ### Security by Default - Cloudflare aims to make baseline protections available to organizations of all sizes. - Examples include: - SSL certificates for encrypted traffic - Unmetered DDoS protection on its free plan - CDN and DNSSEC access - Post-quantum cryptography deployment - Impact programs such as Project Galileo and the Athenian Project - This model is intended to help small businesses, startups, local authorities, and public services participate in the UK’s resilience efforts. ### The Network as a Sensor - Cloudflare peers directly with more than 13,000 networks worldwide. - Attack intelligence gathered in one location can become a protection rule for customers elsewhere within seconds. - This global visibility improves threat detection, scoring, and response across its services. ### Cloudflare as “Customer Zero” - Cloudflare uses its own security products and infrastructure to protect internal systems. - Employees access internal applications through Cloudflare Access and Gateway. - Internal requests require hardware-based MFA, device posture checks, and cryptographically verified identity tokens. - Testing security controls internally helps Cloudflare identify improvements before delivering them to customers. ### Transparency and Incident Response - Cloudflare publishes technical postmortems for security incidents and zero-day vulnerabilities. - It shares indicators of compromise, telemetry, and architectural lessons with the wider security community. - After a major outage, its “Code Orange” initiative focused on building systems that “fail small,” safer configuration tooling, and automated best practices. ## Cloudflare’s Pledge Commitments - The post begins describing the pledge’s requirements around: - Board responsibility and governance - Supply-chain security - Technical standards related to UK Cyber Essentials - The provided text ends before detailing Cloudflare’s specific implementation of these commitments. Organizations should treat cyber resilience as an ongoing governance and engineering responsibility, not an optional product feature. Raising baseline protections, sharing lessons from incidents, and securing supply chains can make the wider Internet safer and more dependable.

cloudflare

The post-quantum EO is an important milestone. Now it’s time to get to work (opens in new tab)

The post welcomes Executive Order 14409 as a major step toward post-quantum security, setting federal deadlines of 2030 for encryption and 2031 for authentication. It argues that the threat timeline has accelerated and that organizations must begin migration now, especially to prevent “harvest-now-decrypt-later” attacks. Cloudflare views the order as a strong foundation but believes agencies need clearer guidance and a coordinated migration roadmap. ## Federal Post-Quantum Requirements - The order primarily covers: - **High Value Assets (HVAs)**, such as systems containing sensitive employee records, classified intelligence, or federal financial data. - **High impact systems** rated “high” under FIPS 199, where compromise could cause severe harm. - Key deadlines include: - **July 2026:** Agencies name a post-quantum migration lead. - **September 2026:** Agencies inventory HVAs and high-impact systems, create migration plans, and submit them to OMB and the National Cyber Director. - **December 2030:** Key establishment must use post-quantum cryptography. - **December 2031:** Digital signatures and certificates must use post-quantum cryptography. - National Security Systems are excluded from these deadlines and remain on a separate NSA-managed schedule. - The order directly binds federal agencies, not state and local governments, critical infrastructure, academia, or civil society. ## Encryption and Authentication Are Separate Migrations - **Post-quantum encryption** protects key establishment and should begin immediately. - It prevents attackers from collecting encrypted data now and decrypting it after quantum computers become capable of breaking RSA and elliptic-curve cryptography. - This is especially important for government, financial, healthcare, defense, and telecommunications data with long-term value. - **Post-quantum authentication** protects digital signatures, certificates, software signatures, and system access. - It prevents future quantum computers from impersonating servers or forging trusted signatures. - Its primary threat emerges once a cryptographically relevant quantum computer exists. - The order’s 2031 authentication deadline suggests the U.S. government considers an operational quantum computer around that period a meaningful possibility. ## Standardized Cryptography Over Quantum Key Distribution - The order emphasizes NIST-standardized post-quantum algorithms. - The authors support this focus because Quantum Key Distribution requires specialized hardware and dedicated physical links, making it unsuitable for Internet-scale deployment. - Cloudflare reports that more than two-thirds of browser traffic reaching its network already uses post-quantum encryption. - Its Cloudflare One platform supports post-quantum protection across TLS, MASQUE, and IPsec, while broader post-quantum authentication deployment is still beginning. ## Why Authentication Is More Difficult - Post-quantum ML-DSA signatures are larger than traditional signatures, potentially reducing performance in systems such as short-lived TLS connections. - Cloudflare is working with Google Chrome on Merkle Tree Certificates to reduce this TLS overhead. - Authentication requires coordinated upgrades across a larger ecosystem: - Clients and servers - Certificate authorities - Certificate transparency logs - Root stores - Web browsers - By comparison, post-quantum key establishment is already more widely available and easier to deploy incrementally. Organizations should begin with asset inventories, risk assessments, and post-quantum key-establishment upgrades now rather than waiting for the federal deadlines. Authentication migration should also start early because its broader dependency chain and larger signatures make it the more complex transition.

cloudflare

Celebrating 12 years of Project Galileo (opens in new tab)

Project Galileo, launched by Cloudflare 12 years ago, provides free cybersecurity services to more than 3,400 civil society websites across 120 countries. Its anniversary report shows that journalists, human rights groups, and nonprofits face more frequent and intense attacks than other Internet users, especially during politically sensitive work. Cloudflare is responding with expanded research, case studies, partnerships, and a call for accessible security protections. ## Project Galileo’s Mission and Reach - The program protects journalists, human rights defenders, and nonprofit organizations from being forced offline. - It now supports more than 3,400 websites in 120 countries. - Cloudflare’s global network spans more than 335 cities in 125 countries, with over 20% of the web behind its infrastructure. ## Cyberattacks Targeting Civil Society Cloudflare’s first comprehensive annual report compares threats against civil society with attacks against Internet users more broadly. - DDoS attacks were the most common threat, often lasting for days or weeks. - Civil society organizations faced website vulnerability exploitation attempts at more than seven times the rate of other Cloudflare customers. - Media organizations were especially affected. - Journalists working in exile received nearly four times more malicious traffic than journalism organizations overall. - Almost 10% of emails processed for civil society organizations contained potential phishing material. - Attacks often coincided with investigative reporting, public advocacy, or other critical organizational activities. Cloudflare calls for affordable cybersecurity, greater transparency around cyberattacks and Internet shutdowns, and default integration of AI-aware and post-quantum protections. The company plans to publish the report annually to track changing threat patterns. ## Case Studies of Project Galileo Participants Sixteen case studies illustrate the varied security needs of participating organizations, including: - Digital rights groups such as SHARE Foundation. - Investigative and independent media organizations, including OCCRP, elTOQUE, and China Digital Times. - Organizations documenting conflict and human rights abuses, such as Ukraine War Archive. - Research and public-interest institutions including Our World in Data and the Bulletin of Atomic Scientists. - Environmental, legal, scientific, and humanitarian groups such as Sea Shepherd Brazil, Activist Rights, and the Royal Meteorological Society. ## Expanding the Partner Network Project Galileo depends on 59 civil society partners that review and approve applications. - Partners contribute local expertise and help identify organizations that need protection. - Previous collaborations produced initiatives such as email security with Protect.ngo and Internet measurement work through UNICEF’s Giga project. - Cloudflare has focused on expanding access beyond North America and Europe through regional events and partnerships. - Recent Asia-Pacific partners include EngageMedia and the OpenCulture Foundation. - The anniversary announcement introduces three additional partners serving journalists, including the International Center for Journalists and Media Cluster Norway. Project Galileo’s next phase combines threat intelligence, direct protection, regional partnerships, and specialized services for journalism organizations. Its broader recommendation is that reliable cybersecurity should be treated as essential infrastructure for civil society and public discourse.

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.

toss

Why We Adopted Post-Quantum Cryptography a Decade Before Quantum Computers Arrive (opens in new tab)

Toss Payments’ biggest legacy-overhaul challenge was not the technology itself, but improving security without disrupting tens of thousands of merchants using decades-old integrations. Because payment systems depend on outdated client environments and small businesses with limited technical resources, security upgrades had to be gradual and carefully communicated. The effort ultimately led from modernizing transport security to adopting post-quantum cryptography in 2026. ## The Challenge of Changing a Legacy Payment Network - Toss Payments supports merchants integrated with its PG system for many years, sometimes decades. - Server-side clients are harder to update than browsers, which update automatically to support new standards. - Security changes such as upgrading TLS, removing weak ciphers, or changing encryption can affect every API call, payment window, and server connection. - Many merchants are small businesses without dedicated developers, making complex security requirements difficult to understand and implement. - As a result, security is a shared responsibility: Toss Payments can strengthen its systems, but legacy merchant environments may still leave connections partially exposed. ## Why Existing Encryption Is Becoming Unsafe - Modern HTTPS and payment systems commonly rely on public-key algorithms such as RSA and ECDSA. - These algorithms are considered secure because conventional computers cannot practically factor enormous numbers or solve elliptic-curve problems. - Quantum algorithms have been mathematically shown to solve these problems efficiently once sufficiently powerful quantum computers exist. - This would make current encryption systems vulnerable, undermining decades of digital-security assumptions. ## Q-Day and “Harvest Now, Decrypt Later” - “Q-Day” refers to the point when quantum computers can break today’s widely used encryption. - Attackers can already intercept and store encrypted payment communications that they cannot currently decrypt. - Once quantum computers become practical, the stored data could be decrypted in bulk. - Payment information is especially valuable because it can remain sensitive for years; data transmitted today could be exposed in the 2030s. - The threat therefore requires action before quantum computers are fully operational. ## A Four-Year Security Upgrade Toss Payments chose a phased approach rather than replacing its security stack all at once: - **2022:** Became the first payment gateway in Korea’s PG industry to implement HTTP/3. - **2022–2025:** Removed weak TLS cipher suites. - **2022–2025:** Completed the rollout of TLS 1.3. - **April 2026:** Implemented post-quantum cryptography (PQC). Each stage balanced stronger protection against the risk of disrupting merchant payments. The gradual rollout gave merchants time to update their systems while ensuring that security improvements continued instead of being postponed indefinitely. ## Starting with HTTP/3 - HTTP/3 is a newer web-transport protocol designed to improve speed and stability, especially on unreliable networks. - It requires TLS 1.3, meaning that adopting HTTP/3 also enforces the use of a modern security protocol. - Toss Payments began with HTTP/3 because it offered both performance improvements and a relatively direct path toward stronger encryption. The broader lesson is that legacy security cannot be improved through a single disruptive upgrade. A phased migration, combined with clear communication and preparation for post-quantum cryptography, allows payment providers to raise security standards while keeping existing merchants operational.

toss

Applying Post-Quantum Cryptography for the Quantum Computing Era: Why Implement It 10 Years Early? (opens in new tab)

Toss Payments’ hardest legacy-modernization challenge was not replacing old systems, but improving security across tens of thousands of merchants with diverse, outdated environments. Over four years, it gradually introduced HTTP/3, removed vulnerable cipher suites, deployed TLS 1.3, and ultimately adopted post-quantum cryptography (PQC) in April 2026. The central lesson is that security upgrades must begin early and be introduced gradually, with merchant support and backward compatibility built in. ## Breaking the Inertia of Legacy Systems - Mission-critical payment services tend to follow the principle: “If it works, don’t touch it.” - Security protocol changes are particularly difficult because they can affect every merchant integration and may be hard to troubleshoot or roll back. - Many merchants still operate decades-old server-side systems that cannot support modern security policies. - Documentation alone is often insufficient, especially for merchants without dedicated development teams. - Because every API, SDK, payment window, and server connection is part of the security boundary, Toss Payments could not improve security independently of its merchants. ## Why Existing Encryption Must Evolve - Modern HTTPS, banking, and payment systems rely heavily on RSA and ECDSA. - These algorithms are considered secure because factoring large numbers and solving elliptic-curve problems is impractical for classical computers. - Quantum computers could solve these problems efficiently, making current public-key cryptography vulnerable. - The anticipated point at which quantum computers can break these systems is often called “Q-Day.” - The “Harvest Now, Decrypt Later” threat means attackers can collect encrypted payment data today and decrypt it years later when quantum computers become practical. ## A Four-Year Security Upgrade Program Toss Payments chose a gradual migration strategy to improve security without abruptly disrupting merchant payments: - **2022:** Introduced HTTP/3, which requires TLS 1.3. - **2022–2025:** Removed vulnerable TLS cipher suites. - **2022–2025:** Enabled TLS 1.3 across all endpoints. - **April 2026:** Introduced post-quantum cryptography. ## HTTP/3 as a Low-Impact Starting Point - HTTP/3 improves speed and reliability on unstable networks. - Because it requires TLS 1.3, enabling HTTP/3 also raised security standards. - Modern browsers automatically select HTTP/3, so merchants required no configuration changes. - This made HTTP/3 an effective first step with minimal migration risk. ## Gradual Cipher Suite Removal - A cipher suite defines the algorithms used by a client and server to establish encrypted communication. - Some legacy merchant servers supported only vulnerable suites, such as `TLS_RSA_WITH_AES_128_CBC_SHA`. - Removing them immediately could stop payments for affected merchants, while delaying removal would leave the wider ecosystem exposed. - Toss Payments used: - Merchant-by-merchant compatibility analysis - Individual notifications six months to a year in advance - Environment-specific documentation and configuration guidance - Technical consulting where necessary - The Technical Account Manager team was essential in coordinating these changes and communicating with merchants in accessible language. ## TLS 1.3 Deployment - TLS 1.2 remained the minimum supported version, while TLS 1.3 was added alongside it. - Clients capable of TLS 1.3 automatically use the stronger protocol. - Older clients continue using TLS 1.2 without forced changes. - TLS 1.3 was enabled endpoint by endpoint from 2022 and supported across all endpoints by 2025. - The process demonstrated that ecosystem-wide security improvements require more time helping merchants migrate than technically changing the servers. ## Post-Quantum Cryptography - Toss Payments began preparing for PQC in 2025 and completed deployment in April 2026. - Modern browsers and clients that support PQC automatically use stronger quantum-resistant channels. - Unsupported environments continue using established encryption methods, preserving compatibility. - Merchants do not need to change configurations or update their integrations. - The approach provides stronger protection against future quantum attacks while minimizing present-day disruption. ## Cross-Team Collaboration - **Infra Team:** Applied PQC within Toss Payments’ private data-center infrastructure and physical hardware. - **Server Platform Team:** Integrated PQC into live traffic paths in AWS. - **TAM Team:** Used its experience from the cipher-suite migration to guide merchants and assess integration environments. - The result was a large-scale, proactive security deployment across the private payment ecosystem. Toss Payments’ experience suggests that organizations should start security migrations well before threats become immediate. Compatibility layers, staged enforcement, and sustained technical support allow legacy ecosystems to adopt stronger security without sacrificing availability.

meta

Post-Quantum Cryptography Migration at Meta: Framework, Lessons, and Takeaways (opens in new tab)

Meta argues that organizations should begin migrating to post-quantum cryptography (PQC) before quantum computers become practical. The “store now, decrypt later” threat means attackers may already be collecting encrypted data for future decryption, making long-lived sensitive information vulnerable today. Meta’s experience suggests a phased strategy based on risk prioritization, cryptographic inventories, technical readiness, deployment, and operational guardrails. ## Why PQC Migration Is Urgent - Quantum computers are expected to eventually break conventional public-key cryptography, potentially within 10–15 years. - Attackers can use “store now, decrypt later” (SNDL) attacks by collecting encrypted data today and decrypting it once quantum capabilities mature. - NIST and the UK NCSC have issued migration guidance, including target timeframes such as 2030 for protecting critical systems. - NIST has standardized algorithms including: - **ML-KEM (Kyber)** for key encapsulation - **ML-DSA (Dilithium)** for digital signatures - **HQC**, which includes contributions from Meta cryptographers ## Meta’s Migration Goals Meta’s multi-year migration is guided by four objectives: - **Effectiveness:** Protect systems against quantum-enabled adversaries. - **Timeliness:** Deploy protections as standards and technologies evolve. - **Performance:** Minimize latency, resource use, and user impact. - **Cost efficiency:** Balance investment against the risk and sensitivity of each use case. ## PQC Migration Levels Meta proposes a maturity ladder that measures how quickly an organization can respond to a relevant quantum event, such as a major technical breakthrough, new standards, or changing industry practices. - **PQ-Unaware:** The organization has not recognized the quantum threat. - **PQ-Aware:** The threat and eventual requirements have been assessed, but design work has not begun. - **PQ-Ready:** A suitable PQC solution has been identified or prepared, but deployment is deferred because of cost, prioritization, or other constraints. - **PQ-Hardened:** All currently available protections have been implemented, but complete mitigation is impossible because required primitives—such as efficient post-quantum OPRFs—do not yet exist. - **PQ-Enabled:** A post-quantum-secure solution is deployed for the use case. This is the desired end state for every application. Even reaching PQ-Ready can reduce future reaction time and create useful technical and organizational foundations, although it does not itself protect systems from quantum attacks. ## Meta’s PQC Migration Strategy Meta describes migration as several potentially overlapping workstreams: - **Define prioritization:** Classify applications by high, moderate, or low risk so the most exposed use cases move first. - **Build a cryptographic inventory:** Identify where cryptography is used and which applications rely on quantum-vulnerable algorithms. - **Address external dependencies:** Track standards, PQC-capable hardware security modules, and the maturity of available implementations. - **Implement PQC components:** Build reusable post-quantum cryptographic capabilities for later integration. - **Deploy guardrails:** Update cryptographic standards, prevent creation of new vulnerable keys, and restrict affected APIs. - **Integrate protections:** Apply PQC components to prioritized use cases and internal traffic. ## Prioritizing Applications The first prioritization category focuses on applications vulnerable to attacks that can begin now and be completed later using quantum algorithms such as Shor’s algorithm. - Applications using quantum-vulnerable public-key encryption or key-exchange mechanisms are considered high priority. - Systems handling sensitive data with long confidentiality requirements are especially exposed to SNDL attacks. - Risk-based prioritization helps organizations avoid attempting a costly, simultaneous migration of every application. Organizations should begin by identifying high-value and long-lived data, inventorying vulnerable cryptography, and moving each use case progressively toward PQ-Enabled status.

cloudflare

Cloudflare targets 2029 for full post-quantum security (opens in new tab)

Cloudflare is accelerating its post-quantum security timeline and now aims to complete the transition by 2029, including post-quantum authentication. The company argues that recent advances in quantum algorithms, neutral-atom hardware, and error correction could bring “Q-Day”—when quantum computers can break today’s cryptography—as early as 2029–2030. While Cloudflare has largely addressed harvest-now/decrypt-later risks through post-quantum encryption, it now considers authentication the more urgent priority. ## Cloudflare’s Post-Quantum Roadmap - Cloudflare began preparing for post-quantum migration in 2019. - It enabled post-quantum encryption for all websites and APIs in 2022. - More than 65% of human traffic to Cloudflare is now post-quantum encrypted. - The remaining challenge is upgrading authentication, including certificates, signatures, and access credentials. - Cloudflare now targets 2029 for full post-quantum security. ## New Evidence That Q-Day May Arrive Earlier - Google announced a major improvement to an undisclosed quantum algorithm for breaking elliptic-curve cryptography. - Google provided a zero-knowledge proof of the algorithm rather than revealing its details. - Oratomic published estimates for breaking RSA-2048 and P-256 using neutral-atom quantum computers. - Its estimate for P-256 requires only about 10,000 qubits. - Important implementation details were intentionally omitted. - These developments led Google to move its own migration target to 2029. - Google has emphasized quantum-secure authentication, suggesting concern that Q-Day could arrive around 2030. - IBM Quantum Safe’s CTO has said that “moonshot attacks” against valuable targets might be possible as early as 2029. - Public progress estimates may become less reliable because researchers could stop disclosing details that would help adversaries. ## Progress Across Three Quantum-Computing Fronts ### Hardware - Competing approaches include: - Neutral atoms - Superconducting qubits - Ion traps - Photonics - Topological qubits - Most approaches have made substantial progress, although none has yet demonstrated the scalability needed to break deployed cryptography. - Neutral-atom systems appear particularly promising, and it would be risky to assume every competing approach will fail to scale. ### Error Correction - Quantum computers are inherently noisy and require error-correcting codes. - Conventional superconducting systems may need roughly 1,000 physical qubits per logical qubit because of noise and limited connectivity. - Neutral-atom systems offer highly connected, reconfigurable qubits that can use more efficient error-correcting codes. - Oratomic estimates that only about 3–4 physical neutral atoms may be needed per logical qubit. ### Quantum Software - Improvements to quantum algorithms can substantially reduce the resources required to break cryptography. - Google’s work reportedly accelerated attacks against P-256. - Oratomic added architecture-specific optimizations for reconfigurable neutral-atom systems. ## Why Authentication Requires Immediate Attention - Post-quantum encryption primarily protects against harvest-now/decrypt-later attacks: - Attackers collect encrypted traffic today. - They decrypt it later after obtaining a capable quantum computer. - This has been Cloudflare’s main focus since 2022. - Authentication presents a different threat: - Quantum computers could forge signatures, impersonate servers, or create unauthorized credentials. - If Q-Day were decades away, deploying post-quantum authentication would provide little immediate benefit. - If Q-Day could occur within a few years, authentication systems must be migrated before attackers can exploit them. Cloudflare’s recommendation is to treat post-quantum migration as an urgent, multi-year project rather than waiting for quantum computers to become publicly available. Organizations should continue protecting stored data with post-quantum encryption while prioritizing the migration of authentication, certificates, and digital signatures before 2029.

google

Safeguarding cryptocurrency by disclosing quantum vulnerabilities responsibly (opens in new tab)

Google Quantum AI argues that future cryptographically relevant quantum computers could break the elliptic-curve cryptography securing many cryptocurrencies sooner and with fewer resources than previously estimated. Its research presents circuits for attacking 256-bit elliptic-curve discrete logarithms using fewer than 1,200–1,450 logical qubits and 70–90 million Toffoli gates. Google urges cryptocurrency developers to migrate to post-quantum cryptography while disclosing the findings through verifiable zero-knowledge proofs rather than publishing exploitable attack details. ## Updated Quantum Resource Estimates - The relevant threat is Shor’s algorithm running on a large, fault-tolerant quantum computer. - Google developed two circuits for solving ECDLP-256: - Fewer than 1,200 logical qubits and 90 million Toffoli gates. - Fewer than 1,450 logical qubits and 70 million Toffoli gates. - Under assumptions aligned with some superconducting quantum hardware, the attack could require: - Fewer than 500,000 physical qubits. - Only a few minutes of computation. - This represents an estimated 20-fold reduction in physical-qubit requirements compared with earlier estimates. - Google connects the findings to its proposed 2029 timeline for beginning migration to post-quantum cryptography. ## Protecting Cryptocurrencies with PQC - Most blockchains and cryptocurrencies rely on elliptic-curve cryptography for essential security functions. - Post-quantum cryptography offers a practical, established direction for protecting blockchains against quantum attacks. - Migration will take significant time, creating urgency for networks to begin transitioning now. - Short- and long-term recommendations include: - Avoid exposing vulnerable wallet addresses. - Do not reuse vulnerable addresses. - Consider policy responses for abandoned or inaccessible coins. - The post points to existing post-quantum blockchain projects and experimental deployments as evidence that migration is feasible. ## Responsible Disclosure Through Zero-Knowledge Proofs - Public vulnerability disclosure must balance two risks: - Revealing enough information for defenders to respond. - Giving attackers a usable blueprint. - Cryptocurrency disclosure is especially sensitive because fear and unsupported claims can damage public confidence even before a technical attack is possible. - Google says it reduced this risk by clarifying which blockchain components are not vulnerable and emphasizing existing post-quantum progress. - It also published a zero-knowledge proof that allows independent parties to verify the resource estimates without accessing the underlying quantum circuits. - Google encourages other research groups to adopt similarly responsible disclosure practices. ## Outlook for the Cryptocurrency Ecosystem - Google hopes the work will encourage coordinated discussion among quantum researchers, security experts, cryptocurrency developers, and policymakers. - The broader goal is to preserve confidence in blockchain systems while giving them enough time to complete a post-quantum transition. Cryptocurrency projects should begin planning and testing PQC migration now, while avoiding address exposure and reuse in the interim. At the same time, quantum researchers should disclose attack estimates in ways that support verification and defense without unnecessarily enabling exploitation.

cloudflare

Bringing more transparency to post-quantum usage, encrypted messaging, and routing security (opens in new tab)

Cloudflare Radar is expanding its security coverage with new visibility into post-quantum encryption, Key Transparency for encrypted messaging, and ASPA deployment for routing security. The updates extend monitoring from user-to-Cloudflare connections to origin servers, provide tools for testing individual websites, and expose verification data that users can independently inspect. Together, they aim to make emerging Internet security technologies more measurable and transparent. ## Measuring Origin Post-Quantum Support - Cloudflare has tracked browser and client support for post-quantum encryption since 2024, rising from below 3% to more than 60% by February 2026. - The monitored algorithm, `X25519MLKEM768`, combines: - Classical X25519 key exchange - NIST-standardized ML-KEM post-quantum cryptography - Radar now measures whether customer origin servers support the same hybrid key exchange. - Cloudflare’s automated TLS scanner probes TLS 1.3-compatible origins and aggregates results daily. - The data measures algorithm support, not necessarily algorithm preference; a server’s TLS configuration can still choose a classical exchange even when post-quantum support exists. - Approximately 10% of origins currently support post-quantum-preferred key agreement, up from less than 1% in early 2025. - Adoption has accelerated as newer versions of OpenSSL, GnuTLS, and Go enabled hybrid post-quantum support by default. - Origin readiness data is available through Radar, Data Explorer, and the Radar API. ## Website Post-Quantum Compatibility Testing - Radar now includes a tool for testing whether a publicly accessible hostname supports post-quantum encryption. - Users can enter a hostname and optionally specify a port, with HTTPS port 443 used by default. - Results show: - Whether the connection is post-quantum secure - The negotiated TLS key exchange algorithm - The tool uses Cloudflare Containers to run a Go-based TLS scanner. - Because Workers cannot inspect the underlying TLS handshake, the container uses Go’s `crypto/tls` package to perform the connection and report the negotiated algorithm. - Cloudflare has consolidated its client- and origin-facing post-quantum measurements into a dedicated Radar section. ## Key Transparency for Encrypted Messaging - End-to-end encrypted services such as WhatsApp and Signal depend on correct public-key distribution. - If a messaging provider’s key database were compromised, an attacker could replace a contact’s public key and potentially intercept messages without detection. - Key Transparency mitigates this risk through an auditable, append-only public-key log. - The model is comparable to Certificate Transparency: - Messaging services publish users’ public keys to a transparency log. - Independent auditors verify that the log is correctly built and remains consistent. - Radar now provides a public dashboard for Key Transparency Logs used by E2EE messaging services. - The dashboard shows when each log was last signed and verified by Cloudflare’s Auditor. - Users can also access an API to independently validate the Auditor’s proofs. ## Routing Security and ASPA - Radar’s routing security coverage now includes global, country-level, and network-level information about ASPA deployment. - ASPA is an emerging standard intended to help detect and prevent BGP route leaks. - The new data extends Radar’s broader monitoring of Internet routing security. Cloudflare’s additions make post-quantum readiness, encrypted-message key integrity, and routing protection easier to measure and verify. Organizations can use the Radar dashboards, API, and hostname testing tool to assess their own migration and security posture.

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.

cloudflare

Building a serverless, post-quantum Matrix homeserver (opens in new tab)

The post describes a proof-of-concept Matrix homeserver ported from Synapse to Cloudflare Workers. It replaces traditional VPS, PostgreSQL, Redis, and filesystem infrastructure with Workers, Durable Objects, D1, KV, and R2, reducing operational overhead and allowing costs to fall near zero when idle. The design also provides post-quantum TLS automatically while preserving Matrix’s end-to-end encryption, though the homeserver still exposes metadata. ## From Synapse to Cloudflare Workers - Traditional Synapse deployments depend on: - PostgreSQL for persistent state - Redis for caching - Filesystem storage for media - VPS infrastructure and operational maintenance - The proof of concept reimplemented core Matrix functionality in TypeScript with Hono, including: - Event authorization - Room state resolution - Cryptographic verification - Cloudflare services replace the traditional components: - Durable Objects provide strongly consistent, atomic coordination. - D1 replaces PostgreSQL. - KV replaces Redis. - R2 replaces filesystem-based media storage. ## Benefits of a Serverless Homeserver - Deployment becomes a single `wrangler deploy` command. - Cloudflare provides TLS termination, load balancing, DDoS protection, and global distribution. - Request-based pricing means the homeserver can cost almost nothing during periods of inactivity. - Workers execute close to users in more than 300 locations, reducing latency for globally distributed communities. - Built-in security features reduce the need to configure firewalls, rate limiting, WAF rules, and IP reputation systems manually. ## Post-Quantum TLS and Matrix Encryption - Cloudflare’s TLS 1.3 connections use hybrid `X25519MLKEM768`. - This combines: - X25519, a classical elliptic-curve algorithm - ML-KEM, a lattice-based post-quantum algorithm standardized by NIST - The hybrid design requires both cryptographic systems to be broken before the connection is compromised. - Traditional deployments would need to upgrade cryptographic libraries, configure cipher suites, test client compatibility, and monitor negotiation failures. - Workers provide this protection automatically through Cloudflare’s infrastructure. ## How Messages Are Protected - Matrix clients encrypt messages locally using Megolm before sending them. - The encrypted Megolm payload is then transported over TLS using post-quantum hybrid key agreement. - The Worker terminates TLS but receives only ciphertext, which it stores and routes without seeing plaintext. - Recipients download the ciphertext over another protected TLS connection and decrypt it locally. - This creates two independent encryption layers: - TLS protects data in transit. - Megolm end-to-end encryption protects message contents from the homeserver and infrastructure providers. ## Metadata and Privacy Limits - The homeserver operator can still observe metadata, including: - Room membership - Room existence - Message timing - Other routing and account information - Message contents remain inaccessible because they are encrypted before reaching the server. - Encrypted-room media is also encrypted client-side, and private keys remain on user devices. ## Storage Architecture - The design assigns each storage primitive to the consistency model it supports best. - D1 stores durable, queryable Matrix data, including users, rooms, events, and device keys across more than 25 tables. - Durable Objects handle real-time coordination and the strong consistency needed for Matrix state resolution. - KV provides cache-like storage, while R2 handles media and filesystem-style objects. The project demonstrates that a Matrix homeserver can be made substantially easier to operate with serverless infrastructure while gaining globally distributed execution and automatic post-quantum transport security. It remains a personal proof of concept, so production deployments should evaluate feature completeness, scalability, compatibility, and the privacy implications of relying on Cloudflare.