AI Weekly Malaysia

Cloudflare Workers now exposes post-quantum algorithms through Web Crypto: ML-KEM-768/1024 for key encapsulation and ML-DSA-44/65/87 for signatures, plus encapsulateBits(), decapsulateBits(), encapsulateKey(), decapsulateKey(), getPublicKey(), SubtleCrypto.supports(), and JWK import/export. The feature is opt-in behind the webcrypto_modern_algorithms compatibility flag because the underlying 'Modern Algorithms in the Web Cryptography API' draft community group report is still moving. Cloudflare's post by Thibault Meunier states explicitly that this is not a full migration path, only building blocks for validating an integration, and that ML-KEM output still needs to be fed into a key schedule and AEAD such as AES-GCM via something like HPKE.

Why: If you already bundle a JavaScript or WebAssembly post-quantum library into a Workers project, this is a chance to delete that dependency and test ML-KEM/ML-DSA against the runtime's own implementation instead. But the flag is named webcrypto_modern_algorithms and the spec is a draft, so treat it as an experiment branch, not a production key-exchange swap — Cloudflare itself says there is no complete migration path here. There is no Malaysian or Southeast Asian angle in this text; the relevance is purely for teams already running Workers.

Cloudflare added per-connection post-quantum TLS visibility to Logpush, Log Explorer, and the HTTP Traffic Analytics dashboard, exposing the key-exchange algorithm negotiated on every incoming request so customers can audit PQ posture per domain. Its Radar data shows roughly 70% of browser-generated traffic to Cloudflare is already protected with hybrid ML-KEM (FIPS 203), but only about 15% of the origins Cloudflare connects to use it. Cloudflare is targeting full post-quantum security by 2029, and says many customers face quantum-readiness deadlines around 2030; it also recently launched Automatic Key Exchange for the Cloudflare-to-origin connection to reveal which algorithms an origin supports.

Why: The 70% visitor vs 15% origin gap is the actionable number: if you run an origin behind Cloudflare, your visitors are probably already negotiating hybrid ML-KEM while your own origin likely is not, so the weak link is on your side of the connection. You can now pull the negotiated key-exchange field from Logpush or Log Explorer per domain to find which of your origins still fall back to classical cryptography, and check whether outdated origin TLS config is downgrading a connection that could support PQ. There is no Malaysia-specific or regional detail in this post; treat it as a general infrastructure item.

Cloudflare announced it is becoming a certificate authority, and says that CA will support Merkle Tree Certificates (MTCs), targeting early 2027 for inclusion in Chrome's newly launched Quantum-resistant Root Store, with standard MTC issuance offered at no cost. The post frames MTCs as the industry's agreed path forward after an experimental deployment with Chrome, arguing that simply swapping post-quantum cryptography into certificates at Internet scale would cause unacceptable performance degradation. Cloudflare also positions the MTC design as making certificate transparency a first-party property rather than an add-on, alongside a stated industry goal of upgrading to post-quantum cryptography by 2029. The published excerpt cuts off during the background section on today's trust ecosystem, so the detailed MTC mechanics are not in the provided text.

Why: If you terminate TLS through Cloudflare, the concrete change to track is that MTC issuance is promised free and its CA is targeting Chrome's Quantum-resistant Root Store in early 2027 — that is a browser-trust change, not just a Cloudflare feature. For everyone else, the 2029 post-quantum deadline in this post is the thing to plan against: MTCs exist because putting PQ signatures directly into certificates degrades performance at scale, so the decision to make is which part of your stack (load balancer, CDN, ingress, client libraries) will need MTC support versus classical certificate issuance, and when. The post contains no Malaysia- or Southeast Asia-specific detail; any local impact would come only from how widely regional builders use Cloudflare as their TLS terminator, which this text does not establish.

Cloudflare's Sharon Goldberg and Tiago Silva describe the company's push to full post-quantum readiness by a 2029 deadline, under a self-described 'PQ everything' maximalist stance. Most Cloudflare products already use post-quantum encryption over TLS 1.3, but post-quantum authentication is still early, so they built an internal tool called CryptoLabe (named after the mariner's astrolabe) to inventory where classical vs post-quantum crypto is used per repository and per product. A third goal is surfacing prerequisites early: protocols, standards, and libraries that have no PQ migration plan yet, so they can push those stakeholders before the 2029 clock runs out. The excerpt cuts off before explaining the specific AI techniques used.

Why: The concrete split is worth acting on: encryption over TLS 1.3 is largely handled on Cloudflare's side, but authentication — cert signing, code signing, SSH, key management — is where they admit it's still early days and where your own stack likely has no PQ plan. If you terminate TLS on Cloudflare, you are already riding their PQ encryption defaults; that does not extend to anything you sign or verify yourself. Their 2029 internal deadline is also a useful reference point when vendors ask you about crypto roadmaps.

Cloudflare says it worked with the IETF to develop a mitigation against quantum downgrade attacks on IPsec, and has shipped it in beta across Cloudflare IPsec, Cloudflare WAN, and Magic Transit. The attack class: because endpoints must keep classical crypto for backwards compatibility, an on-path attacker can tamper with handshake messages so each side believes its peer doesn't support post-quantum algorithms, silently dropping the connection back to classical crypto that a future quantum computer could break. The post frames this as the next frontier of the PQ migration, after swapping Diffie-Hellman for ML-KEM and ECDSA/RSA for ML-DSA. The excerpt is truncated before the actual mitigation mechanism is described.

Why: If you terminate IPsec tunnels (site-to-site VPN, Cloudflare WAN, Magic Transit), enabling ML-KEM on both ends is not sufficient — the handshake itself can be manipulated to strip PQ. The concrete action is to ask your IPsec vendor or your Cloudflare account team whether downgrade protection is in the beta and how you'd verify a tunnel actually negotiated PQ rather than silently falling back. The write-up does not include the mechanism or test procedure in the excerpt, so treat the beta as something to evaluate, not a solved problem.

Simon Willison quotes cryptographer Matthew Green reacting to Anthropic's recent cryptography work. Green argues the field is mid-transition from EC and RSA public-key algorithms to post-quantum schemes built on newer hard problems — hence the number of standards under consideration such as HAWK — and that this makes it an unusually good moment for AI to get good at cryptanalysis. In the best case, he says, AI failing to break these problems gives real confidence in them and makes the cryptanalysis literature more robust.

Why: There is no Malaysia or Southeast Asia angle in this text, and no detail about what Anthropic actually did or published — it is a single quoted opinion. The one concrete decision-relevant point for builders is the migration context Green names: if you have a post-quantum migration on your roadmap (EC/RSA to newer schemes), his argument is that AI-assisted cryptanalysis during this window is more likely to validate the new problems than to break them, so the standards churn around candidates like HAWK is expected rather than alarming. Treat the 'Anthropic cryptography work' claim as unverified from this item alone.

Cloudflare announced its intent to become a public certificate authority, saying it has applied for inclusion in the Chrome, Apple, Microsoft, and Mozilla root programs and signed a definitive agreement to acquire an established, broadly trusted root from GlobalSign — a root trusted across browsers, OSes, and devices since 2012 — so it can reach older clients on day one. It also says it plans to be one of the first CAs to serve post-quantum certificates, targeting Chrome's recently announced Quantum-resistant Root Program. Cloudflare states it is not issuing certificates yet and gives no date for when it will.

Why: There is nothing to change today: Cloudflare explicitly says it is not issuing certificates yet, so no migration or config work is warranted. The concrete thing to track is the two-track trust strategy — a bought GlobalSign root for old devices versus a brand-new root built for root programs that are starting to cap how old a trusted root may be — plus Chrome's Quantum-resistant Root Program, which is the timeline that will eventually force post-quantum certificate choices on teams that terminate TLS. If you buy or resell certificates through GlobalSign, watch how the root's ownership change lands.

The headline states that Cloudflare plans to issue quantum-safe TLS certificates, but the retrieved Ars Technica page contains only cookie-consent and privacy-policy boilerplate — no publication body. As a result there are no details available here on algorithms, timelines, pricing, or which Cloudflare products are affected.

Why: There is nothing here a builder can act on: no date, no cipher suite, no certificate-authority or API change to plan around. If you were about to add a post-quantum migration item to a sprint based on this headline, hold off until the actual announcement text is readable — the fetched page gives you zero specifics to size the work against.