TechPrufer
Get started
Cloudflare
Cloudflare logoCloudflare · Feature trail

Random Number Generation for Security

87 posts · Sep 2013 – Oct 2026

What this trail covers

Cloudflare's security posture continues to evolve with the integration of post-quantum cryptography primitives into Cloudflare Workers' Web Crypto API. This enables developers to experiment with and integrate ML-KEM and ML-DSA algorithms, providing building blocks for future secure protocols like HPKE and OHTTP. The implementation leverages BoringSSL and adds support for `getPublicKey()` and `SubtleCrypto.supports()` for better interoperability. Future work may include broader algorithm support and protocol-level integrations.

All Cloudflare trails
  1. Support for modern cryptographic algorithms in WorkersThis post introduces the addition of ML-KEM-768 and ML-DSA-44 (with support for ML-KEM-1024, ML-DSA-65, ML-DSA-87) to Cloudflare Workers' Web Crypto API. It details the implementation of `encapsulateBits()`, `decapsulateBits()`, `encapsulateKey()`, `decapsulateKey()`, `getPublicKey()`, and `SubtleCrypto.supports()`. The post provides code examples for using these primitives with libraries like `jose` and `hpke`, and explains the rationale for native implementation over bundling separate crypto libraries. It also highlights the need for compatibility flags and the ongoing evolution of the Web Crypto API specification.
  2. Using AI to chart a course for our post-quantum migrationThis post details the development of CryptoLabe, an AI-powered internal tool designed to manage Cloudflare's post-quantum (PQ) migration. CryptoLabe uses AI models to scan codebases, identify cryptographic usage (classical encryption, signatures, tokens, and PQ-ready hybrid key exchange), and classify findings. It operates in two stages: discovery (mapping repositories and searching for crypto usage) and analysis (re-checking observations, investigating runtime usage, and assigning classifications). The tool is built on Cloudflare's Developer Platform using Workers, Durable Objects, and D1, and leverages Agents SDK for orchestration. The post highlights the challenges of discovering cryptography in large codebases and the benefits of AI for this task, aiming to achieve full PQ readiness by 2029.
  3. Post-quantum authentication to origins is now supportedThis post details the implementation of post-quantum authentication for Cloudflare-to-origin connections using ML-DSA signatures. It covers the configuration of Authenticated Origin Pulls (AOP) and Custom Origin Trust Store (COTS) products to support ML-DSA CAs and client certificates. The post also provides detailed instructions for generating ML-DSA certificates and configuring these products via the Cloudflare API, emphasizing the importance of avoiding downgrade attacks.
  4. Why we cannot wait for better post-quantum signature algorithmsThis post details the challenges and trade-offs of migrating to post-quantum signature algorithms, comparing ML-DSA with emerging candidates like FN-DSA, SQIsign, HAWK, and others, highlighting their respective strengths and weaknesses in terms of size, speed, and security. It emphasizes the urgency of this migration due to the threat of harvest-now-decrypt-later attacks and the impending arrival of quantum computers capable of breaking classical cryptography. The post contrasts the 'all-star' nature of Ed25519 with the 'specialist' and 'generalist' categories of post-quantum algorithms, and discusses the specific characteristics of SQIsign (small signatures, slow signing) and its potential applications in offline scenarios.
  5. The White House's post-quantum executive order is an important milestone. It’s time to get to workThis post discusses the US government's Executive Order 14412 mandating the transition to post-quantum cryptography (PQC) for federal agencies and contractors. It highlights the deadlines for PQC encryption (2030) and authentication (2031), and Cloudflare's own roadmap towards full PQC security by 2029. The post emphasizes the importance of PQC for both encryption (to prevent harvest-now-decrypt-later attacks) and authentication (to stop quantum-enabled impersonation and forging). It notes the challenges in migrating authentication systems due to larger signature sizes and longer dependency chains. Cloudflare's existing deployment of PQC encryption across its network is mentioned, along with ongoing work on PQC authentication and contributions to IETF standards. The role of federal contractors in driving PQC adoption is also discussed.
  7. Post-quantum encryption for Cloudflare IPsec is generally availableThis post announces the general availability of post-quantum encryption for Cloudflare IPsec, utilizing the hybrid ML-KEM (FIPS 203) standard. It details the implementation of the hybrid IPsec handshake, which combines classical Diffie-Hellman with ML-KEM for enhanced security against harvest-now-decrypt-later attacks. The post highlights successful interoperability testing with Cisco and Fortinet branch connectors, demonstrating the practical application of the new standard. It also discusses the four-year delay in IPsec standardization compared to TLS, attributing it partly to the community's interest in QKD and the need for post-quantum authentication standards in IPsec.
  8. Cloudflare targets 2029 for full post-quantum securityThis post announces Cloudflare's accelerated timeline to achieve full post-quantum (PQ) security by 2029, including post-quantum authentication. It details recent breakthroughs in quantum computing hardware (neutral atoms) and algorithms that have shortened the estimated time to break current cryptography (e.g., P-256). The post emphasizes the shift in industry focus from PQ encryption (mitigating harvest-now/decrypt-later attacks) to PQ authentication, which is considered more critical for an imminent Q-Day due to the catastrophic impact of broken authentication. It highlights the prioritization of long-lived keys (root certificates, API auth keys, code-signing certs) and the need to disable quantum-vulnerable cryptography to prevent downgrade attacks. The post also notes the dependency chain for migrating to PQ authentication, which will take years.
  9. Bringing more transparency to post-quantum usage, encrypted messaging, and routing securityThis post introduces new data sets and tools on Cloudflare Radar to enhance visibility into post-quantum (PQ) encryption support, encrypted messaging security, and routing security. It extends PQ monitoring to origin-facing connections, providing a graph of customer origins supporting X25519MLKEM768 and a tool to test individual hostnames for PQ support. The post also launches a Key Transparency section on Radar, displaying audit data for logs of end-to-end encrypted messaging services like WhatsApp and Facebook Messenger Transport. Finally, it expands Routing Security insights with ASPA deployment information at global, country, and network levels.
  10. Cloudflare One is the first SASE offering modern post-quantum encryption across the full platformThis post details the integration of hybrid ML-KEM (Module-Lattice-based Key-Encapsulation Mechanism) for post-quantum encryption into Cloudflare One's SASE platform, specifically within Cloudflare IPsec and the Cloudflare One Appliance. It explains the importance of post-quantum cryptography for future security, the two key migrations (key agreement and digital signatures), and the technical challenges and solutions encountered in adapting IPsec for PQC, contrasting it with TLS's adoption.
  11. Building a serverless, post-quantum Matrix homeserverThis post demonstrates the practical application of post-quantum cryptography (PQC) by porting a Matrix homeserver to Cloudflare Workers. It highlights how Cloudflare's existing PQC deployment for TLS 1.3 (X25519MLKEM768) automatically protects all connections to the serverless homeserver, offering a significant advantage over traditional deployments which would require complex upgrades and testing. It also showcases the use of Cloudflare's serverless and storage primitives (Workers, D1, KV, R2, Durable Objects) to build a cost-effective, low-latency, and secure Matrix homeserver, further integrating PQC into a real-world application.
  12. Policy, privacy and post-quantum: anonymous credentials for everyoneThis post explores the application of post-quantum cryptography to Anonymous Credentials (ACs), a privacy-preserving mechanism for proving specific facts without over-sharing information. It discusses the challenges of migrating classical AC primitives to PQ alternatives, the requirements for PQ ACs (including blind signatures, state management, nullifiers, and public attributes), and the current landscape of classical and emerging PQ AC research, including efforts at the IETF and potential use cases like private rate-limiting for AI agents.
  13. Keeping the Internet fast and secure- introducing Merkle Tree CertificatesIntroduces Merkle Tree Certificates (MTCs) as a proposal to redesign the WebPKI for post-quantum cryptography. MTCs aim to reduce the number of signatures and public keys in TLS handshakes to enable the deployment of quantum-safe certificates without performance degradation. The post details the current WebPKI's limitations with larger PQ signatures and outlines the MTC approach, which includes disseminating necessary information out-of-band and making certificate transparency a first-class feature. Cloudflare is also announcing an experimental deployment of MTCs in collaboration with Chrome Security.
  14. State of the post-quantum Internet in 2025This post provides an update on the state of post-quantum cryptography migration on the internet, highlighting that the majority of human-initiated traffic with Cloudflare is now using post-quantum encryption. It details progress on quantum hardware (silicon-based, trapped-ion, topological qubits) and software, emphasizing Craig Gidney's optimizations that significantly reduced the estimated qubit count needed to break RSA-2048, effectively bringing Q-day closer. It also discusses the scare from Chen's algorithm and its subsequent debunking, reinforcing the current reliance on lattice-based cryptography.
  15. Improving the trustworthiness of Javascript on the WebThis post introduces the Web Application Integrity, Consistency, and Transparency (WAICT) initiative, a new approach to securing web applications by ensuring the integrity and transparency of JavaScript code. It details the challenges of client-side cryptography due to code distribution vulnerabilities and proposes solutions like integrity manifests and hash chains to provide app-store-like security guarantees for web applications. This significantly expands the scope of security beyond traditional cryptographic primitives to encompass the trustworthiness of the code itself.
  16. Automatically Secure: how we upgraded 6,000,000 domains by default to get ready for the Quantum FutureThis post details the proactive upgrade of over 6 million domains to stronger TLS encryption modes by default using Automatic SSL/TLS. It highlights the importance of TLS protocol evolution, the challenges of securing the 'back door' between Cloudflare's edge and origin servers, and the transition towards post-quantum cryptography (PQC) with hybrid X25519 + MLKEM key agreement to prepare for future quantum computing threats.
  17. Securing today for the quantum future: WARP client now supports post-quantum cryptography (PQC)This post announces the upgrade of Cloudflare's WARP client (both consumer 1.1.1.1 and enterprise Cloudflare One Agent) to support post-quantum key agreement. This upgrade provides immediate protection against harvest-now-decrypt-later attacks by establishing MASQUE tunnels with post-quantum key agreement. For the Cloudflare One Agent, this enables end-to-end quantum encryption for traffic to internal corporate resources. For the consumer WARP client, it provides post-quantum key agreement for traffic to the internet, even if the final destination server does not yet support PQC. The post details the cryptographic primitives involved, highlighting the maturity and performance of ML-KEM for key agreement and contrasting it with the ongoing standardization of post-quantum digital signatures. It also outlines the unique challenges of upgrading client software on end-user devices and the strategies employed: temporary PQC downgrades, gradual rollout, and MDM overrides.
  18. You don’t need quantum hardware for post-quantum securityThis post clarifies that Post-Quantum Cryptography (PQC) is the necessary and sufficient solution for protecting against quantum adversaries, emphasizing its deployability on existing hardware without specialized quantum technology. It argues against the necessity of Quantum Key Distribution (QKD) and Quantum Random Number Generation (QRNG) for this purpose, citing QKD's lack of Internet-scale applicability and the fact that PQC itself provides sufficient randomness and security. The post highlights that PQC algorithms are based on mathematical problems hard for both classical and quantum computers and are being standardized by NIST. It contrasts PQC with quantum technologies, stating that investments in quantum tech should be for their own sake (e.g., scientific advancement) rather than for quantum-era security.
  19. Prepping for post-quantum: a beginner’s guide to lattice cryptographyThis post introduces lattice cryptography as a foundational element for post-quantum (PQ) cryptography, explaining its application in key exchange protocols like ML-KEM. It details the mathematical concepts of matrices, modular arithmetic, matrix transpose, matrix multiplication, and matrix addition as they apply to lattice-based cryptography. The post provides a simplified Python implementation using NumPy to illustrate how these operations can be used to establish a shared secret, analogous to Diffie-Hellman key exchange, while highlighting the significantly larger communication overhead of lattice-based schemes compared to current elliptic-curve cryptography.
  20. Chaos in Cloudflare’s Lisbon office: securing the Internet with wave motionThis post details the integration of a new physical entropy source, a 'wall of entropy' composed of 50 wave machines, into Cloudflare's LavaRand system. It describes the artistic and engineering challenges in creating custom wave machines capable of 24/7 operation, the specific components and fluid used, and the process of capturing images of the chaotic wave motion to generate random bytes. This new source of entropy complements existing sources like lava lamps, suspended rainbows, and chaotic pendulums, contributing to the cryptographic security of Cloudflare's global infrastructure and services like Cloudflare Workers and the drand API.
  21. Conventional cryptography is under threat. Upgrade to post-quantum cryptography with Cloudflare Zero Trust.This post announces the first phase of end-to-end quantum readiness for Cloudflare's Zero Trust platform, enabling customers to protect corporate network traffic with post-quantum cryptography. It details the 'harvest now, decrypt later' threat and the challenges of deprecating cryptography. The post explains Cloudflare's two-phase migration strategy, focusing on TLS 1.3 key agreement with ML-KEM. It highlights the integration of PQC into Cloudflare Access, WARP device client, and Gateway, and provides technical details on how the Zero Trust platform supports PQC.
  22. A look at the latest post-quantum signature standardization candidatesThis post analyzes fourteen post-quantum signature candidates advanced to the second round of NIST's "signatures on ramp" competition. It details the cryptographic handshake process in TLS, including the roles of leaf, intermediate, and root certificates, as well as Signed Certificate Timestamps (SCTs). The post categorizes algorithms by family (Lattices, Codebased, MPC in the head, VOLE in the head, Isogeny, Multivariate) and compares their public key size, signature size, signing time, and verification time against classical and existing post-quantum schemes. It highlights the significant increase in data size required by post-quantum signatures compared to classical elliptic curves and discusses the trade-offs between signing and verification speed, as well as public key and signature size, for different TLS use cases. Specific attention is given to ML-DSA, SLH-DSA, and Falcon, noting their characteristics and potential challenges for secure implementation.
  23. NIST’s first post-quantum standardsThis post announces NIST's publication of the first three post-quantum cryptographic standards (ML-KEM, ML-DSA, SLH-DSA) designed to resist quantum computer attacks. It discusses the threat posed by quantum computers to current cryptography, the NIST standardization process, and Cloudflare's involvement in evaluating and deploying preliminary versions of these algorithms. The post highlights the urgency of migrating to post-quantum key agreement and the challenges associated with migrating to post-quantum signatures. Cloudflare's current deployment of a hybrid post-quantum key agreement protects a significant percentage of human traffic and plans are in place to upgrade to the final ML-KEM standard. The post also notes that widespread adoption of post-quantum signatures is expected to take longer.
  24. Harnessing chaos in Cloudflare officesThis post details the expansion of Cloudflare's LavaRand system to include new physical entropy sources from its London (double pendulums) and Austin (mobiles) offices, in addition to the original San Francisco lava lamps. It explains how images of these chaotic physical systems are captured, hashed to derive random bytes, and then used to seed a CSPRNG. The post also highlights how this enhanced randomness can be made available to external applications via an API for both private (e.g., key generation) and public (e.g., verifiable random draws, timelock encryption) use cases.
  25. The state of the post-quantum InternetThis post provides an update on the state of post-quantum cryptography (PQC) adoption and its implications for the internet. It highlights that nearly 2% of Cloudflare's TLS 1.3 connections are already secured with PQC, with expectations of double-digit adoption by the end of 2024. The post details the quantum threat, discusses timelines for cryptographically relevant quantum computers, and emphasizes the two main migration paths: key agreement and signatures/certificates. It clarifies that symmetric cryptography is already post-quantum secure and explains the NIST PQC security levels. The post also touches on the challenges of deploying post-quantum signatures at scale and the importance of proactive migration due to the 'harvest now, decrypt later' threat.
  26. Post-quantum cryptography goes GAThis post announces the General Availability (GA) rollout of post-quantum cryptography (PQC) support, specifically X25519+Kyber, across a wide range of Cloudflare products and internal systems. This includes enabling PQC for inbound and outbound connections, origin servers, and Cloudflare Workers. The rollout is phased, with different timelines for Free, Pro/Business, and Enterprise customers. The post also lists the initial set of products included in the GA rollout and those planned for future support, emphasizing the importance of preparing for quantum computing threats and making PQC accessible to everyone.
  27. Cloudflare now uses post-quantum cryptography to talk to your origin serverThis post details the rollout of X25519+Kyber768Draft00 for outbound connections from Cloudflare to origin servers and Cloudflare Workers fetch() calls. It explains the technical rationale behind adopting post-quantum cryptography (PQC) to defend against future quantum computer decryption threats. The post delves into the TLS 1.3 handshake, the role of HelloRetryRequest (HRR) in enabling smooth transitions, and the specifics of the X25519+Kyber hybrid key agreement, including the choice of security level (768 vs. 512) and the ongoing standardization of ML-KEM. It also provides quick start instructions for enabling PQC via API and configuring servers (e.g., nginx) and clients (e.g., bssl tool) for compatibility.
  28. No, AI did not break post-quantum cryptographyThis post clarifies that the Kyber post-quantum encryption algorithm is not broken, despite recent news coverage. It explains that AI has been used for over a decade in side-channel attacks and details how machine learning, particularly deep learning, can be effective in extracting leaked information from power traces. The post also discusses countermeasures like masking and the limitations of AI-based side-channel attacks, emphasizing that while powerful, they are not a magic bullet and carefully implemented countermeasures remain effective. It highlights that the paper discussed does not break Kyber but rather uses AI to aid in cryptanalysis.
  29. Post-quantum crypto should be free, so we’re including it for free, foreverThis post announces the free and permanent availability of Cloudflare's post-quantum cryptography (PQC) implementations for all customers. It details the support for Kyber for key agreement in TLS 1.3 and HTTP/3, and provides open-sourced forks of BoringSSL, Go, and quic-go for testing. It also outlines Cloudflare's internal PQC adoption strategy, including upgrades to BoringSSL and TLS 1.3 for internal connections, and plans to integrate PQC into Zero Trust products. Contributions to open-source projects like CIRCL are also highlighted.
  30. Defending against future threats: Cloudflare goes post-quantumThis post details Cloudflare's deployment of hybrid post-quantum key agreement in TLS 1.3, combining existing key agreements (like X25519) with new post-quantum algorithms (like Kyber). It explains the building blocks of TLS (AEAD, key agreement, signatures), the TLS 1.3 handshake flow, and the rationale behind deploying hybrid solutions for immediate protection against future quantum threats. It also discusses the challenges of migrating to post-quantum cryptography and encourages community testing.
  31. Introducing post-quantum Cloudflare TunnelIntroduces Post-Quantum Cloudflare Tunnel, a beta feature that adds a `--post-quantum` flag to `cloudflared` to establish post-quantum secure connections between `cloudflared` and Cloudflare's network. It uses hybrid key exchanges (X25519Kyber768Draft00 and X25519Kyber512Draft00) over QUIC. The post also announces support for post-quantum browser connections and discusses the challenges of middlebox interference.
  32. Experiment with post-quantum cryptography todayThis post introduces experimental support for X25519Kyber512Draft00 and X25519Kyber768Draft00 hybrid post-quantum key agreements on test domains. It details the performance characteristics of Kyber compared to classical key agreements, the use of hybrids for enhanced security, and provides open-sourced forks of BoringSSL and Go with support for these agreements. The post also includes on-the-wire analysis of TLS 1.3 handshakes with and without post-quantum key agreements, and discusses the underlying cryptographic details and differences between the Go and BoringSSL implementations.
  33. NIST’s pleasant post-quantum surpriseThis post details NIST's announcement of the first four post-quantum cryptographic algorithms to be standardized: Kyber for key agreement and three signature schemes. It explains the threat posed by quantum computers to current public-key cryptography (RSA, ECC) via Shor's algorithm, distinguishing between symmetric encryption, key agreement, and digital signatures. The post analyzes Kyber's performance characteristics compared to X25519 and RSA, noting its speed but larger key sizes. It also discusses the implications for TLS and the potential for hybrid deployments. The post also briefly mentions other KEM finalists and candidates proceeding to a fourth round.
  34. Future-proofing SaltStackThis post details the investigation and patching of several security vulnerabilities (CVE-2022-22934, CVE-2022-22935, CVE-2022-22936) in SaltStack's custom cryptographic protocol. It also explores the path towards making Salt post-quantum secure by proposing and prototyping an mTLS-based transport as a more robust and future-proof solution, which could also simplify the addition of new features and improve performance at scale.
  35. The post-quantum future: challenges and opportunitiesThis post discusses the challenges and opportunities of migrating to post-quantum cryptography (PQC). It highlights that while PQC algorithms can protect confidentiality and integrity, authentication remains a significant challenge, particularly with certificate-based authentication. The complexity of the Public Key Infrastructure (PKI), involving multiple actors, certificate chains, and revocation processes, makes migration difficult. The post also touches on the practical considerations of larger PQC signature sizes and computational costs, and the need for better coordination across the internet to update protocols and middleboxes. It suggests that this migration is an opportunity to rethink the PKI system beyond traditional digital signatures.
  36. Post-quantumify internal services: Logfwrdr, Tunnel, and gokeylessThis post details Cloudflare's initiative to "post-quantum-ify" its internal connections, starting with TLS. It explains the theoretical challenge and practical implementation, focusing on the confidentiality aspect of TLS which is vulnerable to quantum computers. The post introduces the concept of a "hybrid" mechanism for TLS key exchange, combining classical algorithms (like P-256) with post-quantum algorithms (like Kyber-512) to ensure security and FIPS compliance. It highlights the use of BoringCrypto and Golang with BoringCrypto, and the implementation of the Kyber-512 algorithm. Benchmarks comparing Curve P-256 and Kyber-512 key share operations are provided. The post also briefly touches upon why the authentication phase of TLS is not yet being migrated to post-quantum cryptography due to the need for wider industry coordination.
  37. HPKE: Standardizing public-key encryption (finally!)This post introduces Hybrid Public Key Encryption (HPKE) as a new standard (RFC 9180) for public-key encryption in internet protocols. It details the motivation, design goals, and construction of HPKE, highlighting its algorithm agility and authentication modes. HPKE is built from a KEM, KDF, and AEAD, allowing for flexible combinations of cryptographic algorithms. It is already being adopted in emerging standards like Encrypted Client Hello (ECH) and Oblivious DNS-over-HTTPS (ODoH), with an interoperable implementation available in Cloudflare's CIRCL library.
  38. Building Confidence in Cryptographic ProtocolsThis post introduces the concept of formal analysis and mathematical proofs for cryptographic protocols, using KEMTLS as an example. It explains how process algebras and tools like Tamarin are used to model protocols, represent rules, and generate trees of all possible protocol runs. The goal is to demonstrate the security of protocols by showing that no 'bad' runs exist within these trees, providing a rigorous method for building confidence in cryptographic designs, especially in the context of post-quantum cryptography.
  39. Using EasyCrypt and Jasmin for post-quantum verificationThis post introduces EasyCrypt and Jasmin as formal verification tools for ensuring the correctness and security of cryptographic implementations, particularly in the context of post-quantum cryptography. It details the goals of a formal analysis and verification process, distinguishing between formal analysis (proving specification properties) and formal verification (proving implementation correctness). The post explains the concept of indistinguishability games for modeling security goals and outlines a four-step process: formal specification, formal analysis, and formal verification of implementation correctness and additional properties like memory safety and constant-time execution. It highlights the benefits of computational analysis (EasyCrypt) over symbolic analysis (Tamarin) for detailed implementation verification, while acknowledging the potential for unwieldy computational models in complex protocols.
  40. Making protocols post-quantumThis post details the challenges and potential solutions for making TLS post-quantum. It analyzes the trade-offs between speed and size for various NIST post-quantum KEM and signature candidates, discussing their suitability for TLS key exchange and authentication. It also explores alternative approaches like using KEMs for authentication and the implications for certificate chain verification.
  41. Deep dive into a post-quantum key encapsulation algorithmThis post introduces FrodoKEM, a post-quantum Key Encapsulation Mechanism (KEM) based on the Learning With Errors (LWE) problem. It explains the mathematical underpinnings of LWE, including its relationship to lattices and the search/decision formulations. The post details the three algorithms of a KEM (Generate, Encapsulate, Decapsulate) and how FrodoKEM uses FrodoPKE (a PKE scheme based on LWE) as its core. It also discusses the motivation for KEMs in the context of efficient symmetric key exchange and the need for post-quantum cryptography.
  42. Deep dive into a post-quantum signature schemeThis post introduces CRYSTALS-Dilithium as a post-quantum signature scheme, detailing its construction. It explains the underlying mathematical problems, specifically the Short Integer Solution (SIS) problem and its relation to lattices. The post then outlines the algorithmic construction of Dilithium, starting with an identification scheme and its transformation into a signature scheme using the Fiat-Shamir transformation. This contributes to the understanding and implementation of post-quantum cryptography for authentication.
  43. The post-quantum state: a taxonomy of challengesThis post introduces a taxonomy of challenges related to post-quantum cryptography, categorizing them into Protocols, Implementation, Standardization, Community, and Research levels. It details the impact of quantum computers on cryptographic protocols like TLS, DNSSEC, IPsec, and WireGuard, discussing the trade-offs between post-quantum algorithm performance, key sizes, bandwidth, and latency. It highlights the challenges in updating handshake authentication due to larger post-quantum signatures and explores KEMTLS as a potential solution. The post also touches upon protocol ossification and the behavior of middleboxes.
  44. Sizing Up Post-Quantum SignaturesThis post details Cloudflare's investigation into the real-world performance of post-quantum (PQ) signature schemes for TLS, comparing Dilithium, Falcon, and Rainbow against RSA and ECDSA. It highlights the challenges of larger signature sizes impacting TLS handshakes and outlines an experimental setup using dummy certificates to measure these effects on a large scale. The research aims to inform the transition to quantum-resistant cryptography.
  45. Pairings in CIRCLThis post announces a major update to the CIRCL library, introducing new packages for pairing-based cryptography. It explains the mathematical properties of pairings, including their bilinear map nature, and how they enable advanced cryptographic protocols like efficient three-party Diffie-Hellman key exchange and identity-based encryption. The post also touches upon the use of pairings in zk-SNARKs, drand, and BLS signatures, and briefly explains their mathematical origins in elliptic curve theory and divisors.
  46. Introducing Zero-Knowledge Proofs for Private Web Attestation with Cross/Multi-Vendor HardwareIntroduced a Zero-Knowledge Proof (ZKP) system for web attestation to enhance privacy. The system allows hardware security keys to prove their authenticity without revealing manufacturer or model information, addressing privacy concerns with the existing WebAuthn attestation mechanism. The ZKP is designed to be efficient for browser-based implementation and works with existing hardware. The code is open-sourced.
  47. Using HPKE to Encrypt Request PayloadsThis post details the implementation of Hybrid Public Key Encryption (HPKE) to securely encrypt sensitive request payloads for debugging Firewall Rules. It covers the algorithm requirements, the decision to use HPKE due to its performance and emerging standard status, the implementation in Rust and compilation to WebAssembly for cross-platform use (edge, dashboard UI, CLI), and the user-facing aspects of key generation and decryption. The process of payload extraction, rule matching, and serialization is also described.
  48. KEMTLS: Post-quantum TLS without signaturesThis post introduces KEMTLS, a novel mechanism for achieving post-quantum secure TLS handshakes without relying on traditional digital signatures. It proposes replacing the handshake signature with a post-quantum Key Encapsulation Mechanism (KEM) key exchange to reduce the size of transmitted data. The post details the motivation, past experiments, and the implementation of KEMTLS in Go, demonstrating a significant reduction in handshake data size compared to traditional post-quantum TLS approaches.
  49. Securing the post-quantum worldThis post details the threat posed by quantum computing to current cryptographic algorithms, specifically mentioning Shor's algorithm's ability to break RSA and ECC. It highlights the ongoing efforts by NIST to standardize post-quantum cryptography (PQC) algorithms and Cloudflare's involvement in testing and implementing these algorithms, including the TLS Post-Quantum Experiment and the development of high-speed assembly versions of NIST finalists (Kyber, Dilithium) in the CIRCL library. It also introduces KEMTLS as a fully post-quantum TLS protocol. The post emphasizes the urgency of deploying PQC due to the 'harvest now, decrypt later' threat.
  50. Helping build the next generation of privacy-preserving protocolsThis post introduces three new privacy-preserving protocols: Encrypted Client Hello (ECH) to encrypt SNI, Oblivious DNS-over-HTTPS (ODoH) for private DNS lookups, and OPAQUE for secure password authentication. It also highlights past contributions to Universal SSL, TLS 1.3, QUIC, RPKI, time synchronization, and DNS security, emphasizing a commitment to building a better Internet that respects user privacy by changing protocols to expose less sensitive data on the wire.
  51. Announcing the Results of the 1.1.1.1 Public DNS Resolver Privacy ExaminationThis post details the results of an independent examination of Cloudflare's 1.1.1.1 public DNS resolver's privacy commitments. It clarifies that Cloudflare does not retain personal data from resolver users, does not link IP addresses with DNS queries, and truncates source IP addresses to anonymize them. The post also addresses a previous ambiguity regarding the retention of anonymous logs and clarifies the limited use of randomly sampled network packets for troubleshooting and DoS mitigation. Updated privacy commitments are provided, emphasizing that personal data will not be sold or shared, and that source IP addresses will be anonymized and deleted within 25 hours. Transaction and debug logs will also be deleted within 25 hours, with limited access granted to APNIC for research purposes.
  52. Pwned Passwords Padding (ft. Lava Lamps and Workers)This post introduces a new security advancement for the Pwned Passwords API: padded responses. This feature uses Cloudflare Workers to dynamically generate random padding for API responses, preventing attackers from inferring user queries based on response size. It leverages cryptographically secure random number generators, seeded with entropy from sources like lava lamps and server-level randomness, to ensure unpredictable padding. The post also discusses the technical implementation, the low risk of false positives, and future work on more advanced protocols for compromised credential checking.
  53. Securing Memory at EPYC ScaleThis post introduces Cloudflare's exploration and implementation of AMD's Secure Memory Encryption (SME) on EPYC processors. This feature provides hardware-level encryption for data in RAM, addressing physical server theft and memory snooping vulnerabilities. The post details the components of SME, its transparent mode (TSME), and performance testing results, demonstrating a minimal performance impact. This adds a new layer of hardware-assisted security to protect data in use, complementing existing encryption strategies.
  54. Going Keyless EverywhereThis post details Cloudflare's multi-year project to make its platform more resilient against remote memory disclosure vulnerabilities like Heartbleed and Cloudbleed. The core of this effort is the 'Keyless Everywhere' initiative, which separates private keys from internet-facing processes. This was achieved by repurposing the Keyless SSL architecture, originally designed for customer-held keys, to manage Cloudflare's own private keys. The internal implementation, 'gokeyless-internal', was developed to handle millions of private keys at the edge, incorporating lazy loading and graceful upgrade mechanisms. The TLS 1.3 implementation and Spectrum were the first services to adopt this keyless architecture.
  55. Delegated Credentials for TLSThis post introduces Delegated Credentials for TLS, a new cryptographic protocol developed in collaboration with industry partners to enable secure and performant TLS termination in global networks. It addresses the challenges of managing private keys remotely by allowing short-lived, delegated credentials to be pushed to servers, reducing latency and improving availability compared to previous 'Keyless SSL' approaches. This advancement also opens avenues for experimenting with new authentication algorithms and transitioning to post-quantum cryptography by allowing flexibility beyond the traditional Public Key Infrastructure (PKI).
  56. Announcing cfnts: Cloudflare's implementation of NTS in RustThis post details Cloudflare's implementation of the Network Time Security (NTS) protocol in Rust, named 'cfnts'. It explains the NTS protocol's two stages (NTS-KE and NTPv4), the rationale for choosing Rust (memory safety, non-nullability, thread safety, immutability, error handling) over Go for performance-critical time synchronization, and the dependencies used (Mio, Rustls). It also highlights participation in IETF hackathons to ensure interoperability and the strategy of leveraging existing tools like chrony for clock adjustment while focusing on implementing the new secure time protocols.
  57. The TLS Post-Quantum ExperimentThis post details a large-scale experiment with Google to evaluate the performance and feasibility of deploying two post-quantum key agreement algorithms (SIKE and HRSS) in TLS. The experiment measured server-side handshake durations and found that while HRSS (ostrich) generally outperformed SIKE (turkey), SIKE showed better performance for the slowest connections on some devices (Android, Linux, Windows). The experiment also analyzed factors like session resumption, IP version, and network location, finding that while they impacted overall latency, they did not significantly alter the performance gap between the post-quantum ciphers.
  58. Supporting the latest version of the Privacy Pass ProtocolThis post details the evolution of the Privacy Pass protocol, introducing version 2.0 of the browser extension with easier configuration, integration with hCaptcha, and compliance with new cryptographic standards. It also announces a new server backend using Cloudflare Workers for cryptographic operations and the public redemption API. The post highlights ongoing standardization efforts for oblivious pseudorandom functions (OPRFs) and the Privacy Pass protocol itself, emphasizing the commitment to privacy-preserving technologies and community collaboration.
  59. Tales from the Crypt(o team)This post announces a week-long series of blog posts focused on cryptography. It highlights upcoming technical content on Privacy Pass, Post-quantum Cryptography in TLS, Cloudflare's NTS implementation in Rust (cfnts), DNS Encryption, and Delegated Credentials for TLS. The post emphasizes Cloudflare's long-term mission to use cryptography for a better Internet and the importance of partnerships in this endeavor.
  60. How Cloudflare and Wall Street Are Helping Encrypt the Internet TodayThis post details the use of lava lamp footage from the NYSE trading floor as an additional seed for Cloudflare's LavaRand entropy generation system. It explains that true randomness is impossible with computers and that entropy generators are needed. LavaRand captures video of lava lamps, amplifies the randomness, and mixes it with other entropy sources to create a cryptographically-secure source of randomness. The post also mentions the League of Entropy, a consortium of organizations generating verifiable randomness.
  61. The Quantum MenaceThis post introduces quantum computing and its potential impact on current cryptographic standards. It explains the fundamental concepts of quantum computing, including qubits, superposition, and measurement, and how quantum gates operate. The post sets the stage for subsequent discussions on quantum-resistant algorithms and Cloudflare's experiments and open-source contributions in this area.
  62. Towards Post-Quantum Cryptography in TLSThis post details Cloudflare's involvement in the transition to post-quantum cryptography (PQC) for TLS. It explains the threat posed by quantum computers to current public-key cryptography, the ongoing NIST standardization process, and the characteristics required for PQC algorithms in TLS (latency, key size, design clarity, hardware use). Cloudflare is experimenting with two candidate algorithms, HRSS-SXY (lattice-based) and SIKE (isogeny-based), in a joint experiment with Google. The experiment aims to collect telemetry on TLS handshakes using these algorithms to understand their real-world performance, latency impacts, and interactions with network middleboxes. The post also discusses the trade-offs between speed and size for these algorithms compared to X25519.
  63. Introducing CIRCL: An Advanced Cryptographic LibraryThis post introduces CIRCL, a new Go-based cryptographic library developed by Cloudflare. CIRCL includes implementations for post-quantum cryptography (SIKE, SIDH), key exchange (X25519, X448, FourQ), digital signatures (Ed25519), and hash functions for prime groups. It also features optimized ECC curves like P-384. The library is designed to be complementary to existing Go crypto packages, offering more aggressively optimized or less commonly used algorithms. The post provides code examples for using SIKE for key encapsulation and discusses the trade-offs between field sizes and performance.
  64. Securing Certificate Issuance using Multipath Domain Control ValidationThis post introduces a new, free tool Cloudflare offers to Certificate Authorities (CAs) to secure certificate issuance by addressing vulnerabilities in Domain Control Validation (DCV). It details how BGP hijacking attacks (Sub-Prefix Attack and Equally-Specific-Prefix Attack) and DNS spoofing can be used to trick CAs into issuing certificates for domains the attacker does not own. The post explains the mechanisms of these attacks and highlights the critical need for more robust DCV methods to prevent certificate mis-issuance, which can lead to large-scale data breaches and trust erosion.
  65. League of Entropy: Not All Heroes Wear CapesThis post introduces the League of Entropy, a consortium of organizations including Cloudflare, Protocol Labs, University of Chile, EPFL, and Kudelski Security, that have joined forces to provide a quorum of decentralized randomness beacons. The League of Entropy uses the drand protocol to generate publicly verifiable random values every sixty seconds. Each founding member contributes their own high-entropy source (e.g., Cloudflare's LavaRand, EPFL's URand, UChile's Seismic Girl, Kudelski Security's ChaChaRand, Protocol Labs' InterplanetaryRand) to ensure unpredictability, unbiasability, and verifiability. The post clarifies that this public randomness is not suitable for private cryptographic keys and highlights its use cases in election auditing and lotteries.
  66. Inside the EntropyThis post introduces the League of Entropy, a network of distributed, publicly verifiable randomness beacons based on the drand project. It details the cryptographic architecture, including distributed key generation and threshold signature schemes, to provide verifiable randomness for applications like elections and lotteries. The post explains the concept of entropy, how randomness is sampled from natural phenomena and user characteristics, and the mathematical intuition behind threshold cryptography to ensure randomness even with corrupted beacons.
  67. Welcome to Crypto Week 2019This post announces 'Crypto Week 2019' and highlights several new projects and services leveraging modern cryptography. It discusses the ongoing evolution of Internet protocols, focusing on routing security (BGP and RPKI) and DNS security (DNSSEC, DoT/DoH). It also introduces TLS as a critical protocol for web security and mentions the upcoming announcements for the week, which include projects related to entropy, certificate issuance, Ethereum/IPFS gateways, post-quantum cryptography, and secure time services.
  68. Roughtime: Securing Time with Digital SignaturesThis post introduces Roughtime, a free, high-availability, and low-latency authenticated time service available at roughtime.cloudflare.com on port 2002. Roughtime aims to provide accurate time synchronization for cryptographic applications, addressing issues of client clock skew and the security limitations of traditional NTP. The protocol uses digital signatures to authenticate responses and includes features like Merkle trees for batching and UDP for transport to ensure scalability and prevent DDoS amplification. Cloudflare is deploying this service to enhance the validity of TLS artifacts and to contribute to the growth of the Roughtime ecosystem.
  69. Welcome to Crypto WeekThis post announces Cloudflare's 'Crypto Week', a series of daily announcements introducing new technologies that use cryptography to improve the internet. The week's announcements include: Cloudflare's IPFS Gateway, E2E Integrity with IPFS, Expanding DNSSEC Adoption, RPKI for BGP routing security, Cloudflare Onion Service, and Roughtime for securing time with digital signatures. The post explains how cryptography, specifically hashes and digital signatures, can be used to build a more trustworthy internet by encoding and enforcing trust relationships in routing, DNS, and HTTPS.
  70. How "expensive" is crypto anyway?This post provides a detailed analysis of the CPU cost of various cryptographic algorithms used in TLS deployments at Cloudflare's scale. It breaks down the performance impact of symmetric encryption (AES-GCM, ChaCha20-Poly1305, AES-CBC), public-key operations (ECDHE with P256 and x25519, RSA signatures, ECDSA), and hash functions (SHA1, SHA2). The findings indicate that while modern ciphers are efficient, RSA remains a significant performance bottleneck. It also foreshadows the need for post-quantum cryptography.
  71. Concise (Post-Christmas) Cryptography ChallengesThis post presents three cryptography challenges: password hashing using BCrypt, understanding HTTP Strict Transport Security (HSTS) implications for SSL stripping, and reversing AES-256 CTR mode encryption when the key and IV are identical. It details the cracking of BCrypt hashes using hashcat and a password list, explains how HSTS prevents practical SSL stripping attacks, and demonstrates a two-time pad attack on AES-CTR by XORing two ciphertexts encrypted with the same key and IV to recover the original plaintext.
  72. TLS 1.3 is going to save us all, and other reasons why IoT is still insecureThis post discusses the security challenges in IoT devices, specifically focusing on the difficulties of software updates and the overhead of TLS. It highlights TLS 1.3 as a solution to reduce handshake latency and the benefits of Elliptic Curve Cryptography (ECC) for reducing certificate size on resource-constrained devices. It also touches upon the plaintext nature of some IoT protocols like MQTT and CoAP.
  73. Technical reading from the Cloudflare blog for the holidaysThis post details the use of LavaRand, a system that uses a wall of lava lamps to feed entropy into random number generators across Cloudflare's network. It explains how the physical chaos of the lava lamps is captured via cameras, hashed into random bytes, and used to seed Cryptographically Secure Pseudorandom Number Generators (CSPRNGs) for cryptographic security.
  74. LavaRand in Production: The Nitty-Gritty Technical DetailsThis post details the technical implementation of Cloudflare's LavaRand system, which uses a wall of lava lamps as an additional entropy source for cryptographic randomness. It explains the concepts of true randomness vs. pseudorandomness, the importance of entropy pools in operating systems, and the security considerations of randomness generation. The LavaRand design involves a camera capturing the lava lamps, a server mixing this entropy with its own, and a production service further combining it with local entropy. Potential attacks and mitigation strategies are discussed, emphasizing defense-in-depth.
  75. Randomness 101: LavaRand in ProductionThis post introduces LavaRand, a system that uses lava lamps as a secondary source of randomness for production servers. It explains the importance of unpredictable randomness in cryptography, how computers can obtain it from the real world, and the concept of mixing random sources. LavaRand captures images of lava lamps with a camera, feeds the video into a CSPRNG, and uses the output as an extra source of randomness for production servers. This system was inspired by a similar system from Silicon Graphics and serves as a hedge against potential flaws in primary randomness sources.
  76. SIDH in Go for quantum-resistant TLS 1.3This post details the implementation of Supersingular Isogeny Diffie-Hellman (SIDH) in Go for quantum-resistant TLS 1.3. It introduces the p751sidh Go package, which includes a SIDH implementation and a TLS 1.3 client. The work builds on Microsoft Research's SIDH algorithms and C/assembly implementation, porting field arithmetic to Go and integrating it with the TLS 1.3 key agreement mechanism. The post explains the quantum threat to current cryptography, the principles of Diffie-Hellman and SIDH, and the challenges of high-performance field arithmetic in Go, necessitating assembly language.
  77. Why it’s harder to forge a SHA-1 certificate than it is to find a SHA-1 collisionThis post details the practical implications of SHA-1's cryptographic weaknesses, explaining that while SHA-1 collisions are becoming feasible, forging a digital certificate requires more than just a collision. It highlights the 'chosen-prefix attack' technique used to forge an MD5 certificate in the past, which relies on predictable certificate fields like serial numbers and validity periods. The post emphasizes that by including randomness in certificate serial numbers, Certificate Authorities can significantly increase the difficulty of such attacks, even when hash collisions are possible.
  78. Introducing CFSSL - CloudFlare's PKI toolkitIntroduced CFSSL, an open-source toolkit for TLS/SSL certificate management and internal Certificate Authority infrastructure. CFSSL simplifies certificate bundling by selecting optimal certificate chains for compatibility, security, and performance. It can be used as a command-line tool or a web service with a JSON API.
  79. How the NSA (may have) put a backdoor in RSA’s cryptography: A technical primerThis post provides a technical primer on how a backdoor can be inserted into a pseudo-random bit generator (PRNG), specifically focusing on the Dual_EC_DRBG algorithm and its alleged backdoor insertion by the NSA. It explains the concept of backdoors in cryptographic systems, the importance of unpredictable random number generation for security (citing examples of breaches due to flawed RNGs), and details how elliptic curves can be used to create one-way functions that are fundamental to secure PRNG construction. The post illustrates the mathematical principles behind PRNGs and the potential for algorithmic weaknesses to compromise system security.
  80. A (Relatively Easy To Understand) Primer on Elliptic Curve CryptographyThis post provides a foundational explanation of Elliptic Curve Cryptography (ECC) as a more secure and performant alternative to RSA. It details the mathematical underpinnings of public-key cryptography, explains RSA with a toy example, and highlights the limitations of RSA due to the efficiency of factoring algorithms. It then introduces elliptic curves as a basis for a better trapdoor function, explaining their mathematical definition and graphical representation.
  81. Ensuring Randomness with Linux's Random Number GeneratorThis post details the inner workings of Linux's random number generator, focusing on the kernel entropy pool, entropy sources (timestamps from user interaction, network, disk), and the use of XOR for mixing entropy. It explains the concepts of uniformity and unpredictability, the role of entropy in cryptographic security, and the distinction between /dev/random and /dev/urandom, particularly when entropy levels are low. The post emphasizes the importance of monitoring entropy availability and the use of cryptographic hash functions like SHA-1 to derive high-entropy random numbers from the pool.
  82. Why some cryptographic keys are much smaller than othersThis post explains the difference in key lengths between symmetric and asymmetric cryptography, specifically in the context of TLS connections. It details why symmetric keys (like AES) can be shorter (e.g., 128-bit or 256-bit) due to the vast number of possible keys, making brute-force attacks impractical. In contrast, asymmetric keys (like RSA) require much larger key lengths (e.g., 2048-bit) because their security relies on mathematical problems (like prime factorization) which have fewer possible solutions and are susceptible to specific algorithmic attacks (e.g., General Number Field Sieve). The post uses examples of RC4, AES, ECDHE_RSA, and RSA to illustrate these concepts.
  83. Why secure systems require random numbersThis post explains the fundamental importance of random numbers in secure systems, using the Hacker News session ID vulnerability as a concrete example of how weak seeding and pseudo-random number generators can be exploited. It details the middle-square method and contrasts it with cryptographically secure pseudo-random number generators (CSPRNGs). The post highlights the use of random numbers in SSL/TLS handshakes, WPA2, SSH, and the Achilles' heel of the one-time pad. Cloudflare's current reliance on OpenSSL and Linux kernel sources for random numbers is discussed, along with plans to incorporate truly random data from physical sources like radioactive decay, fluid motion, and atmospheric noise to enhance security for customers.