DEV Community: Mohammad Taha Azizi Ahad

AI Just Proved Signal's Encryption With Math. Here's What That Actually Means

Mohammad Taha Azizi Ahad — Wed, 11 Nov 2026 16:55:03 +0000

AI Just Proved Signal's Encryption With Math. Here's What That Actually Means

On November 10, Google DeepMind published something I have been waiting years to see: a mathematical proof that the code behind Signal's encryption actually does what it promises. Not a code review. Not an audit. A proof, checked by a machine, covering the compiled code that runs on real phones.

The project is called AlphaProof Code. A team of five researchers spent four weeks with it, and AI agents working under human supervision generated more than six million lines of Lean proof covering libsignal, the reference implementation of the Signal protocol. That is the same protocol that protects chats in Signal, WhatsApp, and Google Messages. The work covers two things that matter most in a messenger: the PQXDH handshake that sets up a conversation, and the Triple Ratchet that rotates the key for every message.

Four weeks. Work like this used to take expert teams years.

Why this is different from every audit you have read about

Most of the security assurance in our industry stops at the design level. Cryptographers write a protocol on paper, prove the paper version is sound, and then somebody else writes the code. The gap between those two things is where real vulnerabilities live. A ratchet that is perfect in a paper can still leak a key if the implementation reuses a nonce, skips a step on an error path, or mishandles a state transition that the paper never had to think about.

DeepMind's team did not verify the paper version. They verified the compiled code, down to the exact instructions running on ARM devices. They proved four properties of that code: messages stay secret, the other side is who they claim to be, past messages stay secret even if a key leaks later, and the conversation recovers its security after a compromise. That last one, post-compromise security, is the property most messengers get wrong in practice, and it is the one users notice least until it fails.

This is also the first time, by DeepMind's own account, that the implementation of a widely deployed protocol like this has been formally verified by any method at all, with or without AI.

The detail that convinced me

A proof that finds no bugs always raises the same question: would it have found a bug if one was there? DeepMind answered that directly. They took two real bugs that had been found and fixed in older versions of Signal, reintroduced them into an isolated copy of the code, and ran the system against it. In both cases, AlphaProof Code produced a machine-checked proof that the buggy version was insecure.

That is the right test. A verification tool that cannot fail is a rubber stamp. This one failed exactly when it was supposed to.

The human side of the process matters too. Researchers and models wrote the formal specifications together, and human experts reviewed every single one. The agents then flagged about one percent of the codebase for a second human look, and Lean checked the rest automatically. The point is not that AI replaced the experts. The point is that the experts could finally spend their time on the one percent where judgment actually matters, instead of grinding through the other ninety-nine.

What it does not prove

I am writing this as someone building a messenger, so I want to be precise about the limits, because they are easy to overstate away.

First, the proof covers one-to-one sessions only. Group messaging is listed as future work. Second, it applies to libsignal version 0.105.4, compiled for ARM Linux inside a test harness, not to the full Signal app on your phone. The app, the servers, the key servers, the UI that shows you a safety number: none of that is covered. Third, the low-level cryptographic building blocks are assumed secure, not proven. If the math under ML-KEM or the curve code had a flaw, this proof would not catch it. And fourth, a proof is only as good as its specification. If the humans wrote down the wrong security goal, the machine will happily prove the wrong thing.

There is also a subtlety people will miss: WhatsApp and Google Messages run their own versions of the protocol. This result is about libsignal. It does not automatically carry over to every app that borrows Signal's ideas.

None of that diminishes the result. It just tells you what the result is. A proof about the core ratchet and handshake of the reference implementation is exactly the part that has been out of reach for years, and it is now in reach.

What changes for people building messengers

I build a messenger myself. My own project uses a post-quantum ratchet built on ML-KEM-768 with ML-DSA-65 signatures, and I have written before about how much of the work is not the cryptography on paper but the state machine around it: what happens when a message arrives out of order, when a key is replaced, when a session is restored from a backup. That is the work where bugs hide, and it is also the work that formal verification has historically been too slow and too expensive to touch.

If a four-week project with five people can now do what used to take years, the economics of that work change completely. Verification stops being something only a Signal or a Google can afford for one protocol, and starts being something a small team can plan for. The artifacts are open source, the technical paper is public, and the method is not tied to Signal. DeepMind names medical device firmware and power grid software as the next targets, and they are right to aim there, but the more immediate effect is on messaging itself: the next generation of protocols, including post-quantum ones, can be verified at implementation depth from the start instead of audited years after shipping.

There is a second effect that matters just as much. As AI-written code becomes normal, AI-written attacks will get faster too. A defense that takes years to build and four weeks to verify is a defense that can keep up. A defense that takes years to verify is not. Pairing verification with automated patching, which DeepMind mentions alongside a tool called CodeMender, points at a future where the loop from finding a flaw to proving the fix is measured in weeks, not release cycles.

The honest summary

Signal's core cryptography now has something almost no widely used software can claim: a machine-checked proof that the compiled code delivers forward secrecy, authentication, post-compromise security, and handshake secrecy for one-to-one chats. No new flaws were found in the current code. The proof is public, the method is repeatable, and the control experiment shows the tool can actually catch real bugs.

It does not prove the whole app is safe. It does not cover groups. It does not replace audits, and it does not mean every messenger using Signal's ideas inherits the result. But it moves the strongest form of assurance we have from the realm of multi-year research projects into something a small team can run in a month.

For anyone building secure messaging, that is the news. The bar for what "verified" means just moved, and it moved in our direction.

Sources: Google DeepMind, "Formal Verification of Signal's Protocol with Gemini" (November 10, 2026); DeepMind's AlphaProof Code announcement and open-sourced verification artifacts.

Singapore just gave its banks a quantum deadline. The interesting part is what it left out

Mohammad Taha Azizi Ahad — Tue, 10 Nov 2026 16:54:52 +0000

On 6 November 2026, the Monetary Authority of Singapore published Consultation Paper P019-2026, a proposed Circular that tells every financial institution in the country when it should be quantum-safe. The dates are clear. The plan deadline is 31 December 2027. Critical systems follow by 31 December 2030. Everything else is done by 31 December 2034. The consultation closes on 23 November, so the industry has barely two weeks to respond.

I read the paper the way I read most regulator documents now: looking for the gap between what it demands and what it actually enforces. This one has a real gap, and it is worth talking about, because Singapore is one of the first regulators to put calendar dates on a quantum migration, and other regulators will copy the shape of this document even if they change the dates.

What MAS actually asks for

The proposed Circular sets five expectations. A financial institution should have governance and accountability for the migration, a cryptographic asset inventory, a board-approved migration plan, tested implementation, and progress tracking with interim checkpoints and quantitative targets.

The timelines are tiered. The biggest players go first. Critical Information Infrastructure Owners, Domestic Systemically Important Banks, and NETS are expected to submit their migration plans to MAS by 30 June 2027. Critical Information Infrastructure Owners should finish migrating their critical infrastructure systems by 31 December 2029. Everyone else gets until the end of 2027 for a plan, the end of 2030 for critical systems, and the end of 2034 for the rest.

A critical system, in the paper's definition, is one whose failure would cause significant disruption to a firm's operations or materially affect its service to customers. That is a wide definition on purpose. A payments switch qualifies. So does the system that holds customer records for the next thirty years, which matters more than it sounds, for a reason I will come back to.

The paper builds on an advisory MAS issued in February 2024 about quantum-related cybersecurity risks. That advisory warned. This paper schedules.

The part that is missing

Here is the honest part. The proposed Circular is not legally binding. MAS says so itself. It is to be read as supplementary to existing Notices and Guidelines, including the Notice on Technology Risk Management and the Notice on Cyber Hygiene. It creates no penalty of its own. Institutions that run into technical or operational hurdles are expected to record the reasons for any deviation and put interim controls in place.

The paper also names no algorithm, no key size, and no protocol profile. It does not mention hybrid cryptography by name. It does not mention cryptographic agility. It does not mention harvest-now-decrypt-later. It does not refer to NIST's post-quantum standards, FIPS 203, 204, and 205, by name at all.

Instead, the technical work is delegated to a different document: the Cyber Security Agency of Singapore's Quantum-Safe Migration Handbook, version 1, published 16 July 2026, along with the CSA's Quantum Readiness Index. The handbook is described as informational. So the Circular sets the dates, and a non-mandatory handbook holds the technical guidance, and neither document by itself forces a bank to pick a specific algorithm.

I am not saying this makes the paper useless. A regulator that names dates changes budgets. A bank that has to produce a board-approved plan by the end of 2027 will hire people and buy tooling in 2026, because that is how planning cycles work. But there is a difference between a deadline and a standard, and this paper is a deadline without a standard. If a bank migrates its critical systems to something that turns out to be the wrong choice, the Circular gives it no cover and no correction, because it never specified the choice.

How it compares to what came before

Two comparisons put this in context.

The first is NIST. On 27 October 2026, NIST published the final version of IR 8547, its transition plan for post-quantum cryptography. That document deprecates every quantum-vulnerable public-key algorithm after 2030 and disallows them after 2035. Under Executive Order 14412, US federal high value assets and high impact systems must use post-quantum key establishment by 31 December 2030 and post-quantum signatures by 31 December 2031. The NIST dates and the MAS dates line up closely on purpose. Both end up at 2030 for the critical work. The difference is that NIST also names the algorithms, ML-KEM for key establishment and ML-DSA for signatures, and MAS does not.

The second comparison is Hong Kong. The Hong Kong Monetary Authority published a post-quantum toolkit for banks earlier this month. A toolkit tells you how. A Circular tells you when. MAS chose when. The HKMA chose how. A bank operating in both cities now has both halves of the picture, which is probably the point. Regulators talk to each other, and the Asian financial centres are converging on the same message from different directions: start now, finish the critical systems by 2030.

The inventory is the real work

Of the five expectations, one matters more than the other four combined: the cryptographic asset inventory.

You cannot migrate what you cannot find. A bank that has been running for decades has RSA and elliptic curve cryptography in places nobody remembers. It is in TLS configurations, in database encryption, in signed firmware on ATMs, in the VPN that connects two branches, in a library a vendor shipped inside a product ten years ago and never updated, in backups that were encrypted with a key nobody can rotate without restoring the backup first.

I know this from a much smaller system. I build an end-to-end encrypted messenger with its own post-quantum protocol, and even at that scale the inventory is the hard part. The key exchange is one line of code. Finding every place a key is generated, stored, rotated, backed up, or logged is the actual job. The first time I listed every place my app touched a key, I found two I had forgotten. Multiply that by a bank with forty years of systems and you understand why MAS put the inventory second on its list and why the plan deadline is a full year away.

This is also why the 2034 date matters less than it looks. The systems that hold data with a long shelf life are the ones at risk today, not in 2034. An attacker can record encrypted traffic now and decrypt it later, once a capable quantum computer exists. Financial records, health records, and legal documents are kept for decades. A payment record encrypted with RSA today and stored by an adversary is a payment record exposed in ten years. MAS does not use the phrase harvest-now-decrypt-later in this paper, but the 2030 deadline for critical systems is the answer to it: migrate the long-lived data first, because the clock on that data started years ago.

What I would do with this paper if I ran a bank's migration

I do not run a bank. But I have done a migration of a live system to post-quantum key exchange, and the shape of the work is the same at any scale. If I were reading P019-2026 as an engineer instead of a commentator, here is what I would take from it.

First, build the inventory before arguing about algorithms. The inventory decides the plan. A team that starts by picking ML-KEM-768 versus ML-KEM-1024 before it knows where its RSA lives will pick wrong, because the constraint is never the algorithm, it is the oldest system in the fleet.

Second, go hybrid. Pair ML-KEM with X25519 for key establishment, the way browsers and TLS deployments already do. Hybrid means a break in the new lattice algorithm falls back to the classical algorithm you already trust, and a quantum computer breaks the classical half but not the lattice half. It is the only migration strategy that does not ask you to bet the bank on a single new primitive. The IETF published new hybrid cipher suites for Messaging Layer Security on 1 November 2026, and the same pattern applies to TLS. MAS does not require hybrid, which is a gap in the paper, but nothing in it forbids it either.

Third, treat the plan as a living document, not a deliverable. MAS says the timelines may be revised as threats and standards evolve. That is the regulator telling you the dates will move. A board-approved plan that cannot be revised is a plan that will be wrong. Build the migration so the algorithm can be swapped, because it will need to be. Cryptographic agility is not a feature. It is the whole point of doing this migration instead of the last one.

Fourth, submit a comment before 23 November if you are affected. This is a consultation, not a finished rule. The window is short, and the final Circular will be shaped by who shows up. The questions MAS is actually asking are whether the expectations are comprehensive enough and whether the timelines are realistic. If you run systems that cannot meet 2030, the time to say so is now, with reasons, not in 2029.

What to watch next

The consultation closes on 23 November 2026. After that, MAS will publish a final Circular, and the dates in it may shift. Watch three things: whether the final version names ML-KEM and ML-DSA, whether it makes the CSA handbook mandatory instead of informational, and whether it adds any requirement for independent assurance that the migration actually happened. The current paper asks for none of these. If the final version adds even one, it becomes a much stronger document.

The bigger pattern is the one to keep an eye on. NIST set the global dates in October. Hong Kong gave banks a toolkit. Singapore gave them a calendar. Australia's ASD, the US NSA, and CISA updated their joint vendor-readiness guidance in the same week. The regulators are no longer debating whether the migration happens. They are debating the paperwork around it. The engineering is now the easy part. The inventory, the budget, and the board meeting are the hard part, and the deadline for those is 2027, not 2034.

If you build anything that encrypts data someone else will want to read in ten years, that deadline is yours too, whether or not a regulator has sent you a letter yet.

Sources: MAS Consultation Paper P019-2026 (6 November 2026); CSA Quantum-Safe Migration Handbook v1 (16 July 2026); NIST IR 8547 final (27 October 2026); HKMA post-quantum toolkit for banks (November 2026).

Group chats are the last post-quantum holdout. The IETF just moved to fix that.

Mohammad Taha Azizi Ahad — Mon, 09 Nov 2026 16:55:43 +0000

Group chats are the last post-quantum holdout. The IETF just moved to fix that.

On November 1, a document most developers will never read was submitted to the IESG for publication as a Proposed Standard. It is called draft-ietf-mls-pq-ciphersuites-07, and it registers new cipher suites for Messaging Layer Security, the IETF standard for end-to-end encrypted group messaging. If you build messengers, this is the document that decides whether your group chats survive the post-quantum transition, or whether only your one-to-one chats do.

That split is real, and it is the reason this draft matters.

One-to-one went post-quantum years ago. Groups did not.

Signal added PQXDH, a post-quantum key agreement for one-to-one chats, in September 2023. TLS 1.3 has hybrid ML-KEM key exchange in browsers. AWS KMS shipped ML-KEM in October. The one-to-one problem is, by now, a solved engineering task with a deployment schedule.

Group messaging never got the same treatment, because groups are a different problem. In a one-to-one chat, two people agree on a key. In a group chat, fifty people need to agree on a key, members join and leave, people are offline for days, and the whole thing still has to give you forward secrecy and post-compromise security. When someone leaves the group, the keys have to rotate so they cannot read future messages. When someone's phone is compromised, the group has to heal. Doing all of that with keys that are thirty times larger than the ones you used before is not a matter of swapping one algorithm for another. It is a redesign of the plumbing.

MLS, published as RFC 9420 in 2023, is the protocol built for exactly this. It uses a structure called TreeKEM, where group members sit at the leaves of a tree and key updates travel up the tree instead of being sent to every member one by one. That is what makes it scale to groups of thousands. Until now, though, every MLS cipher suite was classical. A quantum computer that could break the key agreement would break the group.

What the draft actually registers

Version 07 of the draft defines eleven cipher suites. They come in two groups, and the difference between them is the honest part of this story.

The first eight combine a post-quantum or hybrid key encapsulation mechanism with a traditional signature algorithm. The KEM options are ML-KEM-768 paired with X25519, ML-KEM-768 paired with P-256, ML-KEM-1024 paired with P-384, and pure ML-KEM-768 or ML-KEM-1024 on their own. The signatures in these eight are classical, Ed25519 and its NIST equivalents.

That means these eight suites give you post-quantum confidentiality but not post-quantum authentication. The encryption keys are safe against a quantum attacker. The signatures that prove who sent a message are not. A future attacker with a quantum computer could forge a group member's signature. The draft says this plainly, and any honest write-up should too: these suites protect the content of your messages, not the identity of the sender.

The last three suites fix that. They pair the same KEMs with ML-DSA signatures, the post-quantum signature scheme NIST standardized as FIPS 204. Those three are fully post-quantum, key agreement and signatures alike. And version 07 changed something important here compared to earlier versions: suites with post-quantum signatures can now use a hybrid KEM as well, not only a pure post-quantum one. In earlier drafts, if you wanted ML-DSA signatures, you had to take a pure ML-KEM key agreement with them. Now you can have the hybrid too, which is the combination most careful deployments will want: ML-KEM plus a classical algorithm, so that if either one turns out to be broken, the other still holds.

The draft also changed its own standing. Earlier versions were informational, a registry entry with no expectation that anyone had to follow it. Version 07 is on the Standards Track, submitted to the IESG for publication as a Proposed Standard. That is the IETF saying this is the way group messaging goes post-quantum, not just one way.

The price is measured in bytes

None of this is free, and the cost is the part that will shape real implementations. An X25519 public key is 32 bytes. An ML-KEM-768 public key is 1,184 bytes, and its ciphertext is 1,088 bytes. An Ed25519 signature is 64 bytes. An ML-DSA-44 signature is 2,420 bytes.

In MLS, those numbers multiply. Every member publishes a key package when they join. Every group update carries new key material. In a group of a hundred people, the difference between 32-byte keys and 1,184-byte keys is the difference between a message that fits comfortably in a push notification payload and one that does not. TreeKEM keeps the scaling logarithmic instead of linear, which is why MLS can absorb this at all, but the constant factor still lands on every phone in the group, on every join, on every key rotation, on every spotty connection.

This is not a reason to avoid the migration. It is a reason to plan it as a protocol change, not a library upgrade. If your messenger treats key sizes as a fixed assumption anywhere, in message size limits, in database columns, in the way you serialize a key package, the post-quantum group chat will find that assumption and break it.

What this means if you build a messenger

I build an encrypted messenger of my own, with a post-quantum ratchet I designed myself: ML-KEM-768 for key exchange, ML-DSA-65 signatures, and group key rotation on member changes. I know this problem from the inside, because I had to solve the same pieces MLS is standardizing: what happens to the group key when someone leaves, how you rotate without breaking offline members, how you keep signatures verifiable when the signature alone is bigger than the message it signs.

So my advice to anyone building in this space is simple. Do not build your own post-quantum group protocol now. The standard is here, it is on the Standards Track, and it has already made the hard choices: which hybrids to bless, how to handle the signature question, how to keep the tree efficient when the keys get big. Your job is to watch this draft become an RFC, and to make your implementation ready for the key sizes it brings.

There are two things to do while you wait. First, measure. Take your current group implementation and run it with ML-KEM-768 key packages, and see where it breaks: message size limits, storage, the time a phone spends parsing a commit. Second, decide your position on the eight versus the three. If you adopt the hybrid suites with classical signatures, you get post-quantum confidentiality now and you accept that authentication stays classical until you move to the ML-DSA suites. That is a defensible choice, and it is probably the right one for most messengers in the next year. Just make it deliberately, and say so in your own documentation, instead of letting your users assume the word post-quantum covers everything.

The direction is set

The draft expires on May 5, 2027, and drafts can still change. The IESG review could ask for revisions. None of that changes the shape of what happened on November 1: the IETF's group messaging standard now has a post-quantum path, on the Standards Track, with hybrid and pure options and with the signature question answered honestly instead of hidden.

One-to-one chats went post-quantum in 2023. The group chat, the harder problem, the one most of us actually live in, finally has its answer on paper. Now it needs to ship.

Post-quantum readiness just became a procurement question

Mohammad Taha Azizi Ahad — Sun, 08 Nov 2026 16:55:04 +0000

Post-quantum readiness just became a procurement question

On November 4, three government cybersecurity agencies published a document that does not tell anyone to do anything. It just lists questions. Nineteen pages of them, aimed at one specific conversation: the one between a buyer and a vendor, at contract renewal time.

The document is called "Post-quantum questions to ask your vendors: Evaluating third-party readiness for post-quantum cryptography." It comes from the NSA, CISA, and Australia's cyber security centre, ASD's ACSC. Australia published the first version in July. This November update turns it into a joint edition, and it arrives one week after NIST published its final transition plan, the one that says RSA and elliptic-curve cryptography become deprecated after 2030 and disallowed after 2035.

That timing is not a coincidence. The policy now exists. The deadlines now exist. The question this new guidance asks is different, and harder: can the people who sell you software actually get there?

The swap is not the hard part

For the last two years, most of the post-quantum conversation has sounded like a shopping list. Replace RSA with ML-KEM. Replace ECDSA with ML-DSA. NIST published the standards in 2024, the libraries are shipping, and the algorithms themselves are, by now, the solved part of the problem.

I know this from the inside, in a small way. I built my own encrypted messenger, and its protocol runs on ML-KEM-768 for key exchange and ML-DSA-65 for identity signatures. When I wrote that code, I knew exactly which algorithm sat in which place, because I put it there myself. That is the luxury of building something from scratch. Almost nobody else has it.

Most organisations do not build their cryptography. They buy it, inside products, inside libraries, inside firmware, inside cloud services they never see the source of. Their encryption is a stack of other people's decisions, and a surprising number of those decisions are undocumented. The new guidance starts from that fact. Its first phase is not "implement." It is "locate."

Know what is actually in the box

The centrepiece of the guidance is a simple idea with an unglamorous name: the cryptographic bill of materials, or CBOM. It is an extension of the software bill of materials, and it lists every algorithm, library, protocol, parameter set, and configuration a product depends on, including the ones inherited from third parties.

That sounds like paperwork. It is actually the whole migration, compressed into one artefact. You cannot plan a transition for cryptography you cannot see. A vendor that cannot produce a CBOM is a vendor that does not know its own product well enough to migrate it, and the guidance is blunt about what a good answer looks like: a complete, current inventory, actively maintained, covering authentication, signing, and data protection in transit and at rest.

The questions that follow are the ones I wish more people asked before they signed a renewal. Is any cryptography hardcoded, or bound to hardware? Can the firmware and the boot process accept a post-quantum signature without replacing the device? Which product versions are covered, and when, exactly, will a post-quantum-ready release ship, with enough time left to test and deploy it before the end of 2030?

That last question matters because of the way the guidance treats 2030. It is a planning milestone drawn from Australia's own transition objectives, not a universal deadline. The document does not impose dates, name algorithms, or name products. It is vendor-neutral guidance, not a mandate. But a vendor that cannot give you a dated release plan is telling you something, even if the guidance never says so out loud.

Firmware is where migrations go to die

The part of the guidance that stuck with me most is the firmware question, because it is where the abstract risk turns physical.

A server can be patched. A phone app can be updated. But a device whose boot chain verifies firmware with an RSA signature has that signature baked into its trust model. If the hardware cannot verify a post-quantum signature, the upgrade path is not a software update. It is a replacement. The guidance asks vendors to explain how the existing trust mechanism transitions, and whether older units simply have to go.

I think about this every time I work on Android, because I have spent enough time with rooted phones and custom modules to know how much trust lives below the operating system. The bootloader, the verified boot chain, the keys that decide whether a piece of firmware is allowed to run: all of it is cryptography, and almost none of it is visible to the person using the device. A migration plan that covers the app layer and forgets the boot chain is not a migration plan.

The same logic applies to the cloud, only the hardware is someone else's. A managed service can be post-quantum ready in its marketing and still depend on a library three layers down that is not. The CBOM is supposed to catch exactly that: the dependency you did not know you had, inherited from a supplier your supplier never audited.

What this means if you build things

There is a temptation to read a document like this as something for procurement departments and government buyers. It is, and it is also a checklist for anyone who ships software, including people building things alone.

Here is the honest version of that checklist, the one I would hand to a developer who asked me where to start:

First, write down your own cryptography. Not a formal CBOM, just a list: which algorithms, which libraries, which protocol versions, where each one lives in your system. If you cannot produce that list for your own project, you are in the same position as the vendor the guidance is warning about.

Second, look for the places where cryptography is hard to change. A signature scheme baked into a file format. A key type assumed by a database column. A protocol version pinned in a client you cannot force to update. Those are the spots that will hurt later, and they are cheaper to find now.

Third, treat crypto-agility as a design property, not a feature. When I built my messenger's protocol, the decision that mattered most was not which algorithm I picked. It was making the algorithm a parameter, so the protocol could move to a different one without being rewritten. That is the same property the guidance is asking vendors to demonstrate, at product scale.

Fourth, plan around data lifetime, not algorithm lifetime. The agencies are careful to say that no cryptographically relevant quantum computer exists today, and they give no arrival date. The risk they describe is narrower and more concrete: data intercepted now can be stored and decrypted later, so anything that must stay secret for years should be protected by post-quantum cryptography sooner than the deadlines suggest. If your data has a long shelf life, your deadline is earlier than the official one.

A question, not a mandate

The guidance ends the way it begins: with questions, not orders. Organisations are told not to ask every question of every vendor. A small supplier and a cloud provider get different conversations. The point is that the conversation happens at all, at renewal time, while there is still leverage, instead of in 2030, when there is none.

That is the real shift here. For years, post-quantum migration was framed as an engineering project with a distant deadline. This document reframes it as a purchasing decision with a near one. The next time a contract comes up for renewal, somebody on the buying side is supposed to ask where the cryptography is, who controls the upgrade, and when the post-quantum version ships. The vendors who can answer will keep the contract. The ones who cannot will have to explain why.

If you build software, do not wait for someone to ask you those questions. Ask them of yourself first, while the answers are still cheap.

Sources: ASD's ACSC / CISA / NSA, "Post-quantum questions to ask your vendors" (November 2026); NIST IR 8547, "Transition to Post-Quantum Cryptography Standards" (October 2026).

GitHub Just Switched Off Your Old SSH Algorithms for a Day — Here's What Broke and What to Fix Before January 13

Mohammad Taha Azizi Ahad — Sat, 07 Nov 2026 16:54:26 +0000

On November 4, GitHub did something it had been warning about since September: it turned off two legacy SSH algorithms for a day. Not a warning banner. Not a deprecation notice in a changelog you never read. The algorithms simply stopped working, and anyone whose setup still depended on them got a failed connection instead of a push.

If your git push worked fine that day, good. That probably means you were never at risk. But the brownout was only a rehearsal. The same switch flips again on December 9, and on January 13, 2027, the old algorithms are gone for good. If you push code over SSH — and if you run any automation that does — now is the time to check, while the fix is still a five-minute job and not a 2 a.m. incident.

What actually changed

GitHub announced the change on September 22, and it has four parts:

RSA signatures using SHA-1 are going away. In SSH terms, that is the ssh-rsa signature type, including RSA certificates that sign with SHA-1. SHA-1 has been known-weak for years; this is GitHub finally pulling the plug.
The diffie-hellman-group-exchange-sha256 key exchange is going away. GitHub calls it slow and little used, and notes that advances in quantum computing could break it.
New RSA keys must be at least 3,072 bits. Since October 14, any RSA key uploaded to GitHub — for login or for signing commits — has to be 3,072 bits or longer. The 2,048-bit default that older versions of ssh-keygen still produce gets rejected on upload.
A post-quantum key exchange is now available. GitHub switched on mlkem768x25519-sha256, a hybrid that combines ML-KEM-768 with X25519, for SSH connections to github.com.

The schedule is what matters: brownouts on November 4 and December 9, permanent removal on January 13, 2027. One independent check of the first brownout found the old algorithms off from about 08:30 UTC to about 22:00 UTC on November 4, then back on. That is the whole point of a brownout — a controlled, temporary outage so you find your broken setups on a day you chose, instead of discovering them on the day the algorithms disappear forever.

The part most people get wrong

The headline that traveled around was "GitHub requires 3,072-bit RSA keys now," and a lot of people read that as "my RSA key is dead, I need a new one." That is not what GitHub said, and it is the most common misunderstanding in this whole change.

The 3,072-bit rule applies only to keys uploaded after October 14. Your existing RSA key keeps working — with one condition. Your SSH client has to sign with SHA-2, using rsa-sha2-256 or rsa-sha2-512 (defined in RFC 8332 back in 2018), instead of the old SHA-1 ssh-rsa signature. Any modern client does this by default. OpenSSH 7.2 and later, which is nearly a decade old at this point, handles it.

In fact, the group of people who can still hit the SHA-1 problem is smaller than it looks. Since March 2022, GitHub has only accepted SHA-1 signatures from RSA keys that were added before November 2, 2021. If your key is newer than that, your client was already forced onto SHA-2 signatures years ago. The people at real risk are running old keys on old clients — and the old clients are the actual problem.

Where the breakage really lives

If you are a developer on a current laptop, you are probably fine. The breakage lives in the places nobody looks at:

CI runners and build servers that were set up years ago and never updated, still running an ancient OpenSSH or an old Java SSH library.
Embedded devices and appliances with a bundled SSH client from 2019 that nobody can update without a firmware release.
Deploy scripts and cron jobs that push over SSH from a forgotten VM, using a key generated when 2,048-bit RSA was the default.
Old Git clients and IDE integrations that ship their own SSH implementation instead of using the system one.

GitHub published minimum client versions with solid RSA/SHA-2 support, and the pattern is consistent: if your tooling is from the last few years, you are fine; if it predates 2021, check it. The key exchange side is the second trap — a client that only speaks the removed Diffie-Hellman method fails no matter what key you give it.

The November 4 brownout was designed to smoke exactly these out. If something in your pipeline failed that day and nobody noticed, December 9 is your second warning. January 13 has no warning attached.

The post-quantum part is the quiet headline

Buried under the deprecation dates is the more interesting change: mlkem768x25519-sha256 is live on github.com. It is a hybrid key exchange — ML-KEM-768, the NIST-standardized post-quantum key encapsulation mechanism, combined with X25519, the elliptic-curve key agreement everyone already trusts. The two contributions are mixed to derive the session key, so the connection stays secure even if one of the two algorithms turns out to be weaker than expected.

This is the same hybrid pattern I use in my own messenger project, where ML-KEM-768 runs alongside a classical ECDH exchange. The idea is the same everywhere it shows up: do not bet the whole connection on the new algorithm before it has years of cryptanalysis behind it, and do not bet it on the old one either, because harvest-now-decrypt-later means today's traffic can be stored and broken later. Run both, and the attacker has to break both.

OpenSSH added support for this key exchange in version 9.9 and made it the default in 10.0, released in April 2025. So if you are running a current OpenSSH, you may already be negotiating a post-quantum key exchange with GitHub every time you push, without having changed a thing. You can check what your client actually negotiated:

ssh -v -T git@github.com 2>&1 | grep -i kex

If you see mlkem768x25519-sha256 in the agreed key exchange, your pushes are already hybrid post-quantum. If your client is older than 9.9, it will negotiate something classical instead, and upgrading OpenSSH is the whole fix. Nothing on the GitHub side needs to be configured — the server already offers it.

One honest caveat: this protects the key exchange, not the authentication. Your account is still authenticated by your Ed25519 or RSA key, and the post-quantum signature standards for SSH authentication are a separate, later conversation. Key exchange is where the harvest-now-decrypt-later risk lives, though, so it is the right place to start.

The five-minute check

Here is the whole audit, and it takes less time than reading this article did:

1. Confirm how you connect. If your remotes start with https://, none of this affects you. Check with git remote -v. Everything below is for SSH remotes only.

2. Check your key type. Look at ~/.ssh/ or run ssh-add -l. If your key is Ed25519, you are done with the key side — GitHub recommends Ed25519 for new keys wherever your platform supports it. If it is RSA, check its size: ssh-keygen -l -f ~/.ssh/id_rsa. An existing key of any size keeps working as long as your client signs with SHA-2, but if you ever need to re-upload it, it has to be 3,072 bits or more.

3. Check your client version. Run ssh -V. Anything reasonably current supports RSA with SHA-2, and 9.9 or later gets you the post-quantum key exchange too. If you are below that, update your client before you touch your keys — an old client with a brand-new key still fails.

4. Test the actual connection, verbosely. Run ssh -T git@github.com. Then run it with -v and look at the agreed key exchange and signature algorithm. What the handshake actually negotiates is the truth; what you assume your config does is not.

5. Generate a new key if you need one. For a fresh key, Ed25519 is the straightforward choice:

ssh-keygen -t ed25519 -C "your_email@example.com"

Upload the public key to GitHub, test it, and only then remove the old one. Never delete the old key before the new one is proven to work — that is how a five-minute job becomes a locked-out afternoon.

6. Hunt down the forgotten automation. This is the step people skip. Check deploy keys, CI runners, cron jobs, and any script that pushes or pulls over SSH. A key you generated in 2020 and forgot about is exactly the kind of thing the January 13 deadline is waiting for.

Why GitHub is doing it this way

The brownout pattern deserves a note, because it is good engineering and more projects should copy it. A hard cutoff date in a changelog is a promise that something will break for someone who did not read the changelog. A brownout converts that into a rehearsal with a known date and a recovery: the old algorithms come back at the end of the day, and the people who broke get a concrete error message pointing at a concrete fix, while there is still time to apply it.

The November 4 brownout already happened. If nothing of yours broke, that is real evidence, not luck — it means your clients and keys already speak the modern algorithms. If something did break and you worked around it by waiting for the algorithms to come back, that workaround expires on January 13.

The bigger picture is that this is what the post-quantum migration looks like in practice. It does not arrive as one dramatic flag day. It arrives as a series of unglamorous, well-signposted changes: a minimum key size here, a retired hash function there, a hybrid key exchange quietly becoming the default. NIST's transition report sets the end of the road at 2035; GitHub just moved one very widely used service a step down it. The developers who stay ahead of it are not the ones reading every standards document. They are the ones who run ssh -V when someone tells them to, and fix the old runner before the deadline instead of after it.

December 9 is five weeks away. January 13 is nine. Check now, while it is still boring.

Sources: GitHub Changelog announcement, September 22, 2026; GitHub's published SSH client minimum versions; OpenSSH 9.9 and 10.0 release notes; NIST IR 8547 (final, October 2026).

AWS KMS Just Shipped ML-KEM. Post-Quantum Crypto Stopped Being a Side Project

Mohammad Taha Azizi Ahad — Fri, 06 Nov 2026 16:54:57 +0000

AWS KMS Just Shipped ML-KEM. Post-Quantum Crypto Stopped Being a Side Project

On October 26, AWS added ML-KEM to its Key Management Service. If you build with cryptography, that date matters more than most of the quantum headlines this year. Not because a quantum computer is about to break RSA tomorrow. Because the boring, production part of the stack just went post-quantum, and boring is exactly how a migration actually happens.

I noticed the announcement for a personal reason: ML-KEM-768 is the same algorithm I use for key exchange in my own encrypted messenger. For the past year, using it has felt like working slightly ahead of the curve. Now the curve has caught up, and it is sitting inside the key vault of the biggest cloud provider on the planet.

What actually shipped

AWS KMS now lets you create keys for ML-KEM, the key encapsulation mechanism NIST standardized as FIPS 203 in 2024. All three parameter sets are supported: ML-KEM-512, ML-KEM-768, and ML-KEM-1024. Two new API calls do the work. Encapsulate takes a public key and produces a random 32-byte shared secret plus a ciphertext. Decapsulate takes that ciphertext and the private key and recovers the same secret. The private key itself never leaves the hardware security module. AWS says those HSMs are validated to FIPS 140-3 Level 3.

That last detail is the whole point. A KEM is only as good as the place its private key lives. Anyone can run ML-KEM from a library on a laptop. KMS puts the private key in a validated module, wraps it in access policy, audit logging, and key rotation, and hands your application a shared secret without ever showing it the long-term key. That is the difference between a demo and infrastructure.

A few facts worth keeping straight. The feature is available in every region where KMS runs except Bahrain, the United Arab Emirates, and China. AWS has not announced a separate ML-KEM price, and the announcement gave no customer adoption numbers or performance figures. The same week, Amazon Aurora PostgreSQL added post-quantum TLS key exchange on versions 18 and higher. And this is not AWS's first post-quantum move: in April 2025 it added a hybrid post-quantum method to protect connections to KMS itself, and KMS already supports ML-DSA, the FIPS 204 signature scheme, for signing.

Why a KMS launch matters more than another library release

Most of the post-quantum conversation is about algorithms. Libraries are the easy part. The hard part is where keys live, who can touch them, and what happens when one needs to be replaced.

Think about what a key exchange actually protects. The threat that drives this whole migration has a plain name: harvest now, decrypt later. An adversary records your encrypted traffic today and opens it years from now, once a capable quantum computer exists. That only works against the key exchange. If the shared secret was agreed with RSA or elliptic-curve Diffie-Hellman, a future machine can recover it from a recording made today. If it was agreed with ML-KEM, the recording stays locked.

That is why putting ML-KEM in KMS is a bigger deal than putting it in one more open source library. KMS is where companies already keep the keys that protect their databases, their backups, their customer data. When the key store itself can speak ML-KEM, a team can start protecting data that will still be sensitive in ten years without rebuilding their key management from scratch. The migration stops being a research project and becomes a configuration choice.

NIST's final transition report, published October 27, one day after the AWS announcement, sets the clock: quantum-vulnerable public-key cryptography is deprecated after 2030 and disallowed under NIST standards after 2035. That sounds far away. It is not, if your data has a long shelf life. Medical records, legal archives, government files, and yes, chat histories, are exactly the kind of data that is still valuable in a decade. The question is not whether quantum computers arrive on schedule. It is whether you want your ten-year-old ciphertexts to be readable when they do.

What I learned using ML-KEM-768 in my own messenger

I built my messenger around a hybrid design: ML-KEM-768 for key encapsulation plus ECDH on P-256, with ML-DSA-65 identity signatures on top. My project is small, experimental, and not independently audited, and I say that plainly because it matters. But building with the algorithm taught me things no announcement will tell you.

First, the sizes are real. An ML-KEM-768 public key is 1,184 bytes. The ciphertext is 1,088 bytes. Compare that with a 32-byte X25519 public key and you understand immediately why protocols need redesign, not just a swap. Every message that carries a key bundle gets heavier. On a phone, on a slow connection, that weight shows up.

Second, the hard part was never the math. Libraries handle the math. The hard part was everything around it: where the private key is stored, how a contact verifies a changed key, what happens to old messages when a key rotates. I ended up building safety numbers, the same idea Signal uses, so two people can compare a fingerprint of each other's identity keys and know nobody swapped them in the middle. Key management is the product. The algorithm is one component inside it.

Third, hybrid is the sane default right now. Running ML-KEM alongside a classical algorithm means you are protected if either one holds up. Pure post-quantum sounds cleaner, but classical algorithms have decades of cryptanalysis behind them and ML-KEM has two years as a standard. Until the new standard earns that kind of track record, belt and suspenders is the honest choice. AWS seems to agree: its earlier KMS move was hybrid, and its documentation treats hybrid as the migration path.

What this launch does not do

A KMS feature does not make your application post-quantum. It gives you a place to keep a post-quantum key and an API to use it. You still have to decide which data needs protection, which sessions use the new keys, and how your protocol handles the bigger key material. If your application encrypts with a key it derived through RSA key transport somewhere else, a shiny ML-KEM key in KMS changes nothing for that data.

It also does not solve the identity problem. ML-KEM establishes a shared secret. It does not prove who is on the other end. That is what signatures are for, and it is why ML-DSA support in KMS matters as much as ML-KEM. A key exchange without authentication is an invitation to a person-in-the-middle. Any real deployment needs both, and needs to think about how keys are verified when they change, not just when they are created.

And the usual caveats apply. No pricing was announced, so budget planning still needs a conversation with AWS. Three regions are excluded at launch. And no vendor announcement tells you how many customers have actually migrated, so treat any claim about industry momentum as marketing until you see real deployments.

If you are starting a migration, start here

I am not going to pretend there is a checklist that fits every system. But the order that makes sense to me, from building my own small version of this problem, looks like this.

Start with an inventory. List every place your system uses public-key cryptography: TLS, key exchange, signatures, encrypted backups, signed updates. Most teams are surprised by how many places there are. You cannot migrate what you have not found.

Protect the long-lived data first. Session keys expire. Backups, archives, and stored messages do not. A KMS ML-KEM key is most useful exactly where the data will outlive the migration.

Go hybrid, and test with real traffic. ML-KEM key material is bigger than what your protocol was designed for. Size limits in databases, message queues, and URL fields are where migrations quietly break. Find those limits in testing, not in production.

Finally, plan for key changes. The day a key needs to rotate or a contact's key changes is the day your verification story gets tested. Build the human side of that early: a fingerprint users can compare, a warning when something changes, a clear path to re-verify. I learned that one the slow way, by getting it wrong first.

The takeaway

A year ago, using ML-KEM meant pulling a library into your own project and explaining to people why you were doing something unusual. This week, the same algorithm is a key type you can pick from a dropdown in the console of the largest cloud provider. That is what a real transition looks like. Not a breakthrough, not a deadline, just the standard plumbing getting a new option, one service at a time.

The quantum computer is still not here. The migration is. And it is arriving the way infrastructure always arrives: quietly, in a changelog, on a Tuesday.

Sources: AWS Weekly Roundup, November 2, 2026; AWS What's New, KMS ML-KEM support, October 26, 2026; NIST IR 8547, "Transition to Post-Quantum Cryptography Standards," final version, October 27, 2026; TechInformed, "AWS KMS adds quantum-resistant key exchange," October 30, 2026.

Signal Just Killed the Phone Number. Here's What Replaces It

Mohammad Taha Azizi Ahad — Thu, 05 Nov 2026 16:54:50 +0000

Signal Just Killed the Phone Number. Here's What Replaces It

For over a decade, Signal had one rule that never bent: no phone number, no account. You could hide your number from other users, you could talk to people by username instead, but underneath it all, your account was still a phone number. That changed in September, and by mid-October it had rolled out to every Android user on Signal 8.31.2.

The feature is called Signal Login. It lets you create a Signal account without giving Signal a phone number at all. It costs $2.99, one time. And the thing that replaces your number is not another identifier you can look up. It is two strings of characters that only you hold.

I build a small encrypted messenger of my own, and its identity has always been a key pair rather than a phone number, so this change hits close to home. It is the biggest identity decision Signal has made since launch, and the interesting part is not that the number is gone. It is what Signal had to give up, and what it asks you to take on, to make that possible.

What actually happens when you sign up

On a fresh install of the Android app, the registration screen now has a second option at the bottom: register without a number. Tap it and Signal asks for a one-time in-app purchase, $2.99 in the US and €3.49 in Europe, prices varying by country. Once the payment clears, Signal generates two keys for you:

An Account ID, 32 characters long. This identifies your account.
A Recovery Key, 64 characters long. This restores your message history and media from a backup.

That is your account now. There is no phone number fallback. Signal is blunt about this in its own support docs: if you lose both keys, there is no way to recover the account. Support cannot look it up for you, because Signal does not store a record linking your identity to the account. The app pushes you to save both keys in a password manager during setup, and you should listen to it.

A username is optional on top of this. If you skip it, your account is completely unreachable. Nobody can find you or message you first. The only conversations you can have are the ones you start yourself. That sounds like a limitation, and it is, but it is also the point: an account that nobody can discover is an account nobody can target.

A few limits worth knowing up front. Signal Login only works for new accounts. If you already have a Signal account, you cannot drop the number from it yet, though Signal has said that may come later. It is Android only for now, with iOS to follow. And it still carries a beta label, which means the details can still move.

Why it costs three dollars

The fee is the part people argue about, and it is worth understanding instead of just reacting to it.

A phone number was never just an identifier for Signal. It was the spam filter. Getting a phone number costs something, it is tied to a real-world subscriber, and a carrier will cut you off if you abuse it. That friction is what kept Signal from drowning in bulk fake accounts. Remove the number and you remove the friction, so Signal had to replace it with a different kind of friction. Three dollars is that replacement.

It is a small amount on purpose. It is cheap enough that a real person barely notices it, and expensive enough that spinning up ten thousand fake accounts stops being free. It is the same logic behind proof-of-work puzzles and CAPTCHAs, just expressed in money instead of compute.

The payment itself is handled with the same zero-knowledge proofs Signal already uses for donations. The server can verify that somebody paid without learning which payment belongs to which account. That matters, because the obvious objection writes itself: you are paying to stay anonymous, so does the payment identify you? Signal's answer is that the cryptography separates the two. You should still know the practical side, though. On Android, the only way to pay right now is through Google Play billing, which needs Play Services and a Google account with a payment method on file. You can skip handing Signal your number, but you cannot yet skip Google's checkout. Signal has said more payment methods are planned, without naming them or giving a timeline. If you run a de-Googled phone, this door is closed to you for now.

What the number was protecting you from, and what it was exposing you to

People treat the phone number as a privacy problem, and it was. A phone number points at a telecom subscriber, a billing address, a SIM card that can be swapped by an attacker who talks a carrier employee into it. SIM swap attacks were one of the most practical ways to take over a Signal account, because the number was the account. Removing it closes that whole class of attack. Nobody can social-engineer a carrier into handing them your Account ID, because there is no carrier involved.

But the number was also doing real work for you, and losing it has a cost that is easy to miss.

A phone number is recoverable. Lose your phone, walk into a shop, get a new SIM, and your number comes back. Your Signal account came back with it. An Account ID and a Recovery Key are not recoverable. They are self-custody in the fullest sense: you are your own carrier now, your own customer support desk, your own backup system. Most people have never held an identity that works like that. A password manager helps, a piece of paper in a drawer helps, but the habit itself is new, and the failure mode is total. One lost string is an inconvenience. Both lost strings is an account that never existed as far as anyone can prove.

This is the trade at the heart of Signal Login, and I think it is the honest way to describe it. You are trading a recoverable identity owned by a telecom company for an unrecoverable identity owned by you. That is a better deal for privacy and a worse deal for convenience, and which side of that you land on depends on what you are actually worried about.

What it does not change

It is worth being clear about what Signal Login is not.

It does not change how messages are encrypted. The Signal Protocol is untouched. It does not change sealed sender, which already hid who sent a message from Signal's servers. It does not verify that the person behind an account is who they claim to be in real life. An Account ID proves that someone holds a key, not that they are a particular human.

And it does not remove the need for key verification. If anything, it makes the tools Signal shipped for that job more important. Signal's Automatic Key Verification, which arrived in August, checks a contact's key against an append-only public ledger instead of asking you to compare safety numbers in person. My own messenger took the older route: a safety number computed from both parties' identity keys, shown as 60 digits and a QR code, with a warning when a key changes. The mechanism differs. The problem is the same: when identity is a key, you need a way to know the key in front of you is the right one. Signal Login moves that problem to the front of the experience instead of the back.

The view from someone building a messenger

Here is the part that interests me most as a builder. For years, the standard answer to "how do I identify users" in messaging was a phone number, because it was the only identifier that was globally unique, hard to fake at scale, and something users already had. Every messenger inherited that answer, and with it inherited the telecom system: SIM registration laws, number recycling, carrier databases, all of it.

Signal just showed that the answer can be different. Identity can be a key pair you generate on the device, with a small payment standing in for the anti-spam job the number used to do. That is a real design shift, and I expect other messengers to study it closely, because it unbundles identity from telecom. A messenger no longer needs a country's phone system to know who its users are.

But it also shows why the phone number survived so long. The number was doing three jobs at once: identity, spam prevention, and recovery. Signal Login splits those three jobs apart and hands one of them, recovery, entirely to the user. That is a brave design choice and a demanding one. Whether ordinary users accept it will decide whether this stays a niche option or becomes the default way to join Signal.

My guess is that it stays optional for a long time, and that is fine. Most people will keep the number, because it is free and it recovers itself. The people who pay three dollars are the ones for whom a phone number is not just inconvenient but dangerous: people whose number identifies them to someone they need to stay hidden from, people in countries where a SIM is registered to a national ID, people who simply do not want a telecom company standing between them and their conversations.

For them, three dollars is not a price. It is the first time the door was open at all.

Should you use it?

If you are creating a fresh Signal account and your phone number is something you cannot safely attach to your messaging, yes. Save both keys in a password manager before you do anything else, add a username only if you want to be findable, and understand that losing those keys means losing the account.

If you already have a Signal account that works, there is nothing to do right now. You cannot migrate yet, and your number is already hidden from other users by default.

And if you are building a messenger yourself, pay attention to the shape of this decision. The interesting question is no longer whether identity needs a phone number. Signal just answered that. The interesting question is what you do with the recovery job once the number is gone, because that is the part nobody has solved well yet, and whoever solves it will decide what the next decade of private messaging looks like.

Sources: Signal Support, "Phone Numberless Registration for Android beta"; Signal Community forum, Greyson Parrelli on the 8.28 beta (16 September 2026); AboutSignal, "Signal registration without a phone number now available on Android" (17 October 2026); Gizmodo, "Signal Finally Lets You Skip the Phone Number, but Now Google Is Involved" (24 September 2026).

23,000 Qubits to Break RSA-2048: What That Number Actually Means

Mohammad Taha Azizi Ahad — Wed, 04 Nov 2026 16:54:05 +0000

Last week a number travelled fast through the security world: 22,593. That is how many physical qubits the French quantum company Alice & Bob estimates Shor's algorithm would need to factor RSA-2048, in about 3.14 days, on its cat-qubit architecture. The paper, "Shor's algorithm compiled on cat qubits: 22 593 qubits for RSA-2048 in 3.14 days," was posted to the IACR ePrint archive on October 28, and the company announced it the next day.

If you build software that encrypts things, this number deserves a careful read, not a panicked one. It is real progress in resource estimation. It is not a machine, and it is not a date.

Where the number comes from

The headline figure is the latest point on a steep downward curve. Alice & Bob's own estimates for breaking RSA-2048 on cat qubits were roughly 350,000 in 2023 and just under 100,000 in 2024. Now it is about 23,000. For comparison, the company says its architecture needs about 40 times fewer physical qubits than Google Quantum AI's Craig Gidney estimated in 2025, which was on the order of one million transmon qubits. The same paper puts a Bitcoin key at roughly 30,000 physical qubits in about one hour.

The reason cat qubits get a smaller number is hardware-level error suppression. A cat qubit is designed so that bit-flip errors are suppressed by the physics of the device itself, which means the error correction layer only has to deal with phase flips. Fewer errors to correct means fewer physical qubits per logical qubit, and the whole machine shrinks. Alice & Bob also switched from the repetition code used in its earlier estimates to more efficient LDPC-cat codes, which is a large part of why the number fell so far between 2024 and now.

That is genuinely interesting engineering. It is also the part of the story where the fine print starts to matter.

The assumption doing all the work

The headline figure assumes no bit flips at all during the computation. In the company's own words, that is equivalent to a bit-flip time of about one century. If bit flips instead occur about once an hour, the same calculation needs roughly 45,000 qubits, nearly double.

That assumption has not been demonstrated at scale. Cat qubits exist in labs and show the promised bit-flip suppression in small devices, but nobody has built tens of thousands of them into a fault-tolerant machine running Shor's algorithm for three days straight. The paper is a preprint, not yet peer reviewed, and the "record low" framing comes from the company's own press release. Other researchers quoted in coverage made the same point: the estimate is a blueprint of a machine that would be built, not a measurement of a machine that exists.

So the honest summary is this: if cat qubits scale the way their designers hope, breaking RSA-2048 gets much cheaper than the previous best estimates suggested. The "if" is doing a lot of work, and it will stay that way until hardware catches up with the math.

Why the number still matters

It would be a mistake to dismiss the estimate entirely because of its assumptions. Resource estimates for breaking RSA have fallen repeatedly, across different architectures and different research groups, for more than a decade. Every time someone finds a smarter way to compile Shor's algorithm or a more efficient error-correcting code, the machine that does not exist yet gets smaller. The direction of travel is consistent even when individual numbers are optimistic.

That direction matters because of one specific threat: harvest now, decrypt later. An attacker does not need a quantum computer today. They need to record encrypted traffic today and keep it until a machine capable of breaking it exists. Session keys protected by forward secrecy limit that damage for live conversations, but long-term keys, stored backups, signed documents, and anything encrypted with a static RSA key do not get that protection. Data with a long shelf life, medical records, state secrets, private messages archived for years, is exposed to a machine that might arrive in the 2030s.

This is also why the timing of the announcement matters. Two days before it, NIST published the final version of its transition report, IR 8547, which says quantum-vulnerable public-key cryptography will be deprecated after 2030 and disallowed under NIST standards after 2035. The two documents are independent, but they point the same way: the window for treating migration as a future project is closing.

What I would actually do about it

I build a messenger, so this is not abstract for me. My own project already pairs ML-KEM-768 key exchange with ML-DSA-65 signatures, and working through that migration taught me a few practical things that apply far beyond one app.

First, find out where RSA and elliptic-curve cryptography actually live in your system. Most teams are surprised. It is in TLS certificates, in old API clients, in backup encryption, in signed update packages, in the identity keys that users never rotate. You cannot migrate what you have not inventoried.

Second, start with key exchange, not signatures. Key exchange is where harvest-now-decrypt-later bites, and it is also the easier migration. A hybrid approach, ML-KEM alongside a classical algorithm like X25519, is the pragmatic choice while post-quantum standards are still bedding in: if either one holds, the session stays secret. TLS 1.3 already supports hybrid key exchange in practice, and libraries for ML-KEM are available in the major stacks now.

Third, design for crypto agility from the start. The algorithm you pick today will not be the last one you ship. Parameter sets get revised, standards get updated, and a migration that requires rewriting your protocol is a migration that will be postponed. If your code treats the key exchange mechanism as a replaceable module rather than something baked into every message format, the next migration costs weeks instead of months.

Fourth, do not wait for a perfect plan. The gap between "we should migrate" and "we have migrated" is measured in years for any real system, and the estimates above suggest the machine on the other side of that gap keeps getting smaller. Starting with the highest-value, longest-lived data first is a better strategy than waiting until every dependency is ready.

What not to do

Do not announce that Q-Day has arrived. No cryptographically relevant quantum computer exists today, and a preprint resource estimate is not one. Do not rip RSA out of everything overnight either; badly rushed migrations create outages and real vulnerabilities that are worse than the theoretical one you are trying to fix. And do not treat any single vendor's number as a timeline. Alice & Bob itself says it expects hardware improvements and falling resource requirements to converge in the early 2030s, and that is a company forecast, not a fact.

The number to remember from last week is not really 22,593. It is the trend behind it: every few years, breaking RSA gets estimated to be substantially cheaper than we thought. Builders who act on the trend, quietly and early, will be fine. Builders who wait for certainty will get it at exactly the moment they no longer need it.

Sources: Alice & Bob, "Shor's algorithm compiled on cat qubits: 22 593 qubits for RSA-2048 in 3.14 days," IACR ePrint 2026/2665; Alice & Bob press release, October 29, 2026; NIST IR 8547 (final, October 27, 2026).

The Botnet That Shipped in the Box: What XCPE Teaches Builders About Trust

Mohammad Taha Azizi Ahad — Tue, 03 Nov 2026 16:54:31 +0000

The Botnet That Shipped in the Box: What XCPE Teaches Builders About Trust

Most malware stories start with a mistake. Someone clicked a link, installed a shady APK, or ignored an update. The XCPE story starts somewhere else entirely: at the factory.

On 2 November 2026, Google announced it had disrupted XCPE, a backdoor and botnet built from more than 1.3 million Android devices. The overwhelming majority were Android TV set-top boxes, but Google also found the backdoor in other Android-based devices, including telehealth devices, karaoke machines, and digital signage displays. The owners of those boxes did nothing wrong. They plugged in a cheap box to watch television, and the box quietly went to work for someone else.

That detail is what makes this story worth sitting with, especially if you build software for Android.

What Google says happened

According to Google's Threat Intelligence Group, the backdoor was developed and operated by Videostrong Technology, a China-based manufacturer of Android devices. Google's assessment, stated with high confidence, is that this was deliberate: not a rogue employee, not a bug, not a missed vulnerability. Videostrong sold access to affiliates, who then ran their own schemes through people's living rooms.

The malware had a three-stage architecture, and the structure matters more than any single payload:

A primary backdoor that persisted on the /oem/ partition.
A loader and execution engine. In late 2024, Google says, this was a separate loader called com.abc.nexus. Since August 2026, the operators had been replacing it with smaller, specialised droppers disguised as Android system applications.
Monetisation modules that could execute additional backdoors and load still more modules.

Through that pipeline, the infected devices were abused for ad fraud, data exfiltration, and use as residential proxies, and for loading additional malware. That last point scales the story beyond the headline number. Google says the takedown likely severed access to at least 10 million other devices, because the operators of the modules loaded through XCPE had diversified their distribution beyond XCPE itself.

How it hid in plain sight

Videostrong was not some unknown workshop. It was a certified Android manufacturer, which means its devices went through Google's compatibility and security tests. Google says the company used obfuscation techniques to exploit a gap in that review process, loading the malicious code only after a device's first boot. The code that passed the test was not quite the code that ran in people's homes.

That is a hard lesson for anyone who treats certification as proof. A test checks a device at a moment in time, under conditions the manufacturer can anticipate. A backdoor designed to activate after that moment passes the test and still does its job. Google says it has since tightened its firmware integrity checks for certified Android TV devices and changed its review process. That is a fix to the process, and it is worth noting, but it is also an admission: the process had a hole, and it took a botnet of over a million devices to find it.

There is a second hiding place here, and it is architectural. Persistence on the /oem/ partition is not the same as a bad app a user can uninstall. A factory reset does not necessarily remove code that lives where the factory put it. A user scanning for suspicious apps would not see a system-level backdoor dressed up as part of the device. The usual advice, "just uninstall it" or "just reset the phone", does not apply when the problem ships with the hardware.

The takedown, and what it does not do

The disruption itself was a joint effort. Google took legal action to take down the botnet's domains and servers, plus the command-and-control domains behind the additional modules. Japan's National Police Agency, Lumen, HUMAN Security, Plume, Synthient, and TrendAI participated, and technical details were published by Plume, Synthient, and TrendAI. Google also banned Videostrong from making devices with preloaded Google apps, along with its future subsidiaries and affiliates.

That is a serious response, and it clearly hurt the operation. Google itself adds a caution worth quoting in spirit: the underlying illicit market is resilient, and when one component is disrupted, operators pivot to new loaders or rival monetisation SDKs. A seized domain cuts the strings. It does not uninstall the code sitting on a million devices, and it does not shut down the market that paid for those strings in the first place.

I want to be careful about one more thing. This is Google's assessment, corroborated by partner firms, not a court ruling. Videostrong did not respond to press inquiries about the claims. That distinction matters when you write about attribution. The technical facts, the scale, and the takedown actions are reported by multiple sources. The question of intent is Google's stated belief, and it should be labelled as such.

Four lessons I am taking from this as a builder

First, trust is a supply chain problem, not just a code problem. When I work on Android software, I think a lot about the code I write and the permissions I request. XCPE is a reminder that the chain starts before my code ever runs: the firmware, the preinstalled apps, the partitions I never touch. If any link in that chain is compromised, the user's choices after purchase barely matter.

Second, persistence beats payload. Security writing loves to focus on the clever exploit, but the XCPE operators built something less glamorous and more durable: a foothold that survived normal use, plus a loader that could swap in new modules over time. The payload could change. The position could not be easily removed. When you design a system, ask where your persistence lives, and who else could live there.

Third, a passing test is not a security guarantee. This applies to certification suites, to app review, and to my own testing. If a check only looks at one moment, assume an attacker will design around that moment. Delayed activation, staged downloads, and code that behaves differently after first boot are not exotic tricks anymore. They are standard practice for operators at this scale.

Fourth, build for the user who cannot see the problem. The people who owned these boxes had no realistic way to detect a backdoor on the /oem/ partition. That is not their failure. It is a design failure in the ecosystem around them. Anything I build that asks the user to spot a sophisticated compromise is asking the wrong person to do the work. The protection has to live in the system: verified boot, signed firmware, minimal preinstalled components, reproducible builds, and update channels the manufacturer cannot quietly bypass.

What this means for the rest of us

For users, the practical takeaway is boring and therefore useful: buy devices from vendors with a track record you can check, keep firmware updates on, and treat a suspiciously cheap smart device as a device that might be paying for itself some other way. None of that would have saved an XCPE owner on its own, which is exactly the point. Individual vigilance is not a substitute for a trustworthy supply chain.

For builders, the takeaway is sharper. Every preinstalled component you ship, every system partition you touch, every update mechanism you control is part of someone's trust boundary. Keep that surface small. Sign what you ship. Make it verifiable by someone other than you. And when something in your chain breaks, say so plainly, the way a takedown report has to: what happened, what you did about it, and what it does not fix.

The next time someone says security is just about not clicking bad links, remember XCPE. Over a million people did everything right. They bought a certified product, plugged it in, and watched TV. The malware was already home before they pressed power.

Sources: SecurityWeek's report on Google's XCPE announcement (2-3 November 2026), and Google's Threat Intelligence Group findings as reported there.

Hong Kong's Banks Scored 2.3 Out of 10 on Quantum Readiness. The Fix Is Boring, and That Is the Point

Mohammad Taha Azizi Ahad — Mon, 02 Nov 2026 16:53:36 +0000

On 2 November 2026, at Hong Kong FinTech Week, the Hong Kong Monetary Authority and the Hong Kong University of Science and Technology launched a Post-Quantum Cryptography Toolkit for banks. The timing tells you most of the story. In July, the HKMA introduced its Quantum Preparedness Index to measure how ready the banking sector actually is for quantum-safe cryptography. The first score was 2.3 out of 10.

That is not a score you fix with a new algorithm announcement. It is a score you fix with an inventory.

I build a small experimental messenger with post-quantum key exchange, so I read these announcements differently from a bank compliance officer. My codebase is small enough that I can list every place cryptography touches it in an afternoon. A bank cannot. That gap is the whole story of the post-quantum transition, and Hong Kong just put a number on it.

What the 2.3 actually means

The HKMA is careful about what the index measures: awareness, planning, pilot projects, and practical readiness. A score of 2.3 means the sector has started paying attention but has barely started doing the work. Reporting on the survey behind the index put two numbers alongside it that matter more than the headline: around half of surveyed banks had no formal post-quantum plan, and 32 percent had not begun transition work at all.

Read that again slowly. Not "had not finished." Had not begun. In a sector that holds other people's money and keeps records that must stay secret for years, a third of institutions had not started, months after NIST published its post-quantum standards in 2024 and days after NIST finalised its transition report on 27 October 2026, deprecating quantum-vulnerable public-key cryptography after 2030 and disallowing it after 2035.

HKMA chief executive Eddie Yue warned at the launch that quantum computing could arrive within three to 15 years and could break existing cryptography quickly once it does. That range is honest and useless at the same time. Three years means you are already late. Fifteen years means a board can postpone the budget meeting. A toolkit exists to close that gap between "someday" and "this quarter."

What the toolkit actually contains

Strip away the launch language and the toolkit is four jobs, in order.

First, governance and accountability. Someone named owns the transition. Not a committee, not a working group that meets twice a year, a person or team whose job it is to answer for progress. HKMA deputy chief executive Arthur Yuen put it plainly: the index gave the sector a starting point, and the next step is to turn that understanding into clear responsibilities, informed priorities, and practical plans.

Second, assess cryptographic exposure. Take stock of cryptographic assets and dependencies. Where does RSA sit? Where does elliptic-curve cryptography sit? Which systems depend on which libraries, which vendors, which hardware? You cannot migrate what you have not listed, and in a bank the list is the hard part. It runs through core banking systems, payment rails, ATMs, mobile apps, third-party services, and hardware security modules that were bought a decade ago and never touched since.

Third, identify transition needs and set priorities. Not everything moves first. Data that must stay secret for ten years moves before data that expires next week. Key establishment, the ML-KEM side of the standards, moves before signatures in most plans, because the "harvest now, decrypt later" threat hits stored ciphertext first. A risk-based order beats a heroic rewrite.

Fourth, monitor implementation progress. The toolkit includes practical tools for building transition timelines and for strengthening engagement with suppliers, because a bank that migrates its own code but waits on a vendor's black-box appliance has not migrated at all.

The HKMA says the toolkit will keep evolving as standards and implementation experience mature, and it is available through the authority's Fintech Knowledge Hub. What it does not do is also worth noting: the launch announcement did not name specific algorithms for banks to adopt, and it did not set bank-by-bank deadlines. The target is the sector-level one: a QPI score of 10, defined as full quantum readiness, by 2030.

Why this matters outside banking

HKUST Business School dean Frederik Anseel called preparing for the quantum era "a leadership challenge," and said banks can build the knowledge and organisational capability they need even while the timing of the threat remains uncertain. I think that is the most useful sentence in the whole announcement, because it applies far beyond banks.

Most post-quantum writing, including some of mine, focuses on algorithms: ML-KEM versus the classical key exchange it replaces, ML-DSA versus ECDSA, key sizes, performance costs. Those details matter, and I have spent real time on them in my own messenger, where switching a key exchange means touching session setup, stored keys, and the fallback path when the other side runs an older build. But the algorithm is the easy part to describe. The hard part is everything around it: knowing where the old cryptography lives, who is responsible for changing it, what breaks when a key gets four times larger, and which supplier has not answered your email.

A bank with a 2.3 score and a solo builder with a small project have opposite versions of the same problem. The bank has scale and no map. The builder has a map and no scale. The builder can swap an algorithm in a weekend and test it on their own device that evening. The bank needs a toolkit just to find out what it owns. Both of them fail the same way if they skip the inventory and go straight to the shiny new standard.

So here is the practical version of the HKMA toolkit, sized for a project like mine or yours:

List every place your code uses public-key cryptography, including the ones inside libraries you did not write. If you cannot list it, you cannot migrate it.
Write down who owns each item. If the answer is "someone, eventually," the owner is you, now.
Rank by how long the protected data must stay secret, not by how easy the code change looks.
Pick one system, migrate it, and keep the old path working until the new one is proven. Crypto-agility, the ability to swap algorithms without redesigning the system, is worth more than picking the perfect algorithm on the first try.
Check your suppliers and dependencies the same way. An upstream library that never ships a post-quantum update is your problem, whether or not you wrote it.

None of that is exciting. None of it will get applause at a conference. It is also the entire difference between a sector that scores 2.3 and one that reaches 10 by 2030.

The uncomfortable part

Four years to full readiness, from 2.3, with a third of banks not yet started, is a steep climb. The HKMA target lines up with the NIST timeline, which gives federal high-value systems until the end of 2030 for post-quantum key establishment and the end of 2031 for signatures, and with the HSBC-style corporate pledges to be quantum-ready by 2030 that surfaced around the same FinTech Week sessions. Everyone has picked roughly the same year. That is either reassuring coordination or a shared deadline that a lot of organisations will miss together.

I do not know which one it is, and neither does anyone else, because a toolkit is not a migration. It is a plan for a migration. The next number that matters will not be a launch announcement. It will be the next QPI score, whenever the HKMA publishes it, and whether the share of banks with no formal plan has actually shrunk.

Until then, the lesson from Hong Kong is simple and a little humbling for those of us who like the algorithm part best: the post-quantum transition will be won or lost in inventories, ownership lists, and supplier emails. The cryptography was standardised in 2024. The boring work is still at 2.3 out of 10.

Sources: HKMA press release on Hong Kong FinTech Week 2026 (2 November 2026); HKMA/HKUST PQC Toolkit announcement coverage by Blockchain.News, The Quantum Insider, The Standard, and EconoTimes; NIST IR 8547 final, 27 October 2026.

Nobody Broke Signal's Encryption. They Just Got People to Scan a QR Code

Mohammad Taha Azizi Ahad — Sun, 01 Nov 2026 16:54:03 +0000

Nobody Broke Signal's Encryption. They Just Got People to Scan a QR Code

On October 13, 2026, the Czech Republic's National Cyber and Information Security Agency (NUKIB) published a formal threat analysis that should change how every messenger builder thinks about security. It confirmed that actors tied to the Russian Federation are running targeted phishing campaigns against Signal users across Europe, and that related incidents have now happened inside the Czech Republic itself.

That makes five Western agencies that have now publicly confirmed the same operation: the Netherlands, Germany, the United States, Ukraine, and now the Czech Republic. The FBI said in March 2026 that unauthorized access had reached thousands of Signal accounts worldwide. In Germany alone, roughly 300 accounts in the political sphere were compromised, according to Der Spiegel citing government sources. NUKIB warns the real footprint is almost certainly larger than the five countries where the technique has been officially documented.

Here is the part that matters most, and every one of those agencies agrees on it: Signal's end-to-end encryption was not broken. Nobody cracked the Signal Protocol. The attack goes around the cryptography entirely, through a feature that ships in every copy of Signal: linked devices.

How the attack actually works

When you link a laptop to your Signal account, your phone shows a QR code. Whatever scans that code gets paired to your account and receives your messages in real time. The attackers replace the legitimate QR code with a malicious one.

Google's Threat Intelligence Group documented the technique in early 2025. One variant, run by the group tracked as UNC5792, hosts fake Signal group invitation pages that look identical to the real thing. The QR code on the page does not encode a group invitation. It encodes a device-linking address pointing at attacker infrastructure. The victim thinks they are joining a group. They are actually pairing their account to someone else's machine.

Another variant, tracked as UNC4221, hid malicious QR codes inside a phishing kit that mimicked Kropyva, an artillery guidance app used by Ukrainian armed forces. The victim believed they were completing a routine operational step. Other clusters went lower tech: Turla used PowerShell scripts to pull Signal messages from compromised Windows machines, and a Belarus-linked cluster used the plain Robocopy file-copy utility to copy desktop Signal database files. Once you have the already-decrypted local database, encryption is irrelevant.

NUKIB describes a second vector that is even simpler: a message crafted to look like a legitimate Signal notification, a support alert, a security warning, a group invitation, with a link or QR code inside. Signal's real support team does not contact users through the app, and it never asks for a PIN or registration credentials in a message. But a convincing fake does not need to be perfect. It needs one tired person, once.

And here is the detail that should worry builders the most. According to Google's threat researchers, compromises established this way can go unnoticed for extended periods of time. Signal deliberately keeps no centralized server-side log of device-pairing events, because logging them would create a metadata trail about who links what, when. That is a principled privacy choice, and it is also the reason there is no reliable audit trail to catch a silent pairing. The same design decision protects users from bulk metadata collection and leaves them blind to this attack. Both things are true at the same time.

The same trick, from the other side of the law

This is not only a story about intelligence agencies. On September 30, 2026, Privacy Guides reported on documents obtained by Netzpolitik showing that German customs officials have been using the linked-device feature of messengers to read suspects' messages without breaking any encryption. They tested the approach starting at the end of 2023, and since August 2025 it has been an official, permanent strategy available to agents. The messengers affected include WhatsApp, Telegram, Threema, and Signal.

The implementations differ in how easy they make it. Telegram sends a login code to an existing device, and that code can be phished. WhatsApp is somewhat better: linking has to be started from inside the app, so an attacker cannot just send a code unprompted, but a victim can still be coached into typing in a linking code. Signal only allows linking through a QR code, and a QR code can still be sent by an attacker and scanned by a victim who has no idea what it really authorizes.

Put the two stories together and the pattern is unmistakable. The linked-device flow is now a standard tool for anyone who wants into an encrypted account, state actor or police agency alike, and it works precisely because it never touches the encryption. When the Dutch military intelligence director said publicly that even end-to-end encrypted apps are not appropriate for classified government information, this is the kind of thing he meant.

What I am taking into my own messenger

I build a small end-to-end encrypted messenger, and I recently shipped a safety-number feature for it: a fingerprint over both parties' identity keys, with a warning and a confirmation step if a contact's key changes. That feature protects against a specific threat, a silent key swap in the middle of a conversation. Writing about this campaign forced me to be honest about what it does not protect against. A linked device receives legitimate keys through a legitimate flow. Key verification passes. The safety number matches. Everything looks fine, because from the protocol's point of view, nothing went wrong. A new device joined, and the protocol did what it was asked to do.

So if you are building a messenger, here is where I think the real work is:

First, treat pairing like handing someone a copy of the account, because that is what it is. The pairing screen should say so in plain words, not in a vague "link a device" label. Users cannot defend a step they do not understand.

Second, a new pairing must be loud. A push notification, a persistent in-app banner, and an entry in the device list that stays visible until the user acknowledges it. A pairing that can happen silently is a pairing that will be abused silently.

Third, show what the QR code authorizes before the scan completes, and require a second confirmation on the phone itself: the device type, a name, and what it will be able to do. A QR code is opaque by design, and opaque approval steps are phishing bait. The phone already knows what it is about to approve. It should tell the user.

Fourth, make the device list a first-class screen, not a settings afterthought. The single highest-leverage habit in NUKIB's advisory is also the simplest: open Settings, then Linked Devices, and remove anything you do not recognize. If your app buries that list three menus deep, most users will never open it.

And one correction worth stating plainly, because I have seen it repeated wrongly: Signal's Registration Lock is worth turning on, but it is not the fix for this attack. Registration Lock blocks someone from re-registering your number on a new phone without your PIN. This attack does not re-register anything. It pairs a new device to an account that is already registered. Different flow, different defense. Conflating them leaves people feeling protected when they are not.

The uncomfortable lesson

Messenger security arguments usually end at the protocol. Is the ratchet sound, is the key exchange post-quantum, is the code audited. All of that matters, and none of it saved a single account in this campaign. The accounts fell at the boundary between the protocol and the person: a QR code that meant one thing to the user and another thing to the machine, a device list nobody checked, a pairing nobody noticed.

If you build messengers, that boundary is your product now. The cryptography is the easy part to get right and the hard part to explain. The pairing flow is the opposite: easy to build, easy to get wrong, and it is where real accounts are actually being lost in 2026.

For users, the checklist is short. Check your linked devices today, in whatever messenger you use, and remove anything unfamiliar. Never scan a QR code from an unsolicited message, no matter how official it looks. Turn on Registration Lock anyway, because it raises the cost of the neighboring attacks. And remember that the strongest encryption in the world only protects the messages. It does not protect the account.

Sources: NUKIB threat analysis (October 13, 2026); FBI public service announcement (March 20, 2026); joint AIVD/MIVD advisory (March 9, 2026); Google Threat Intelligence Group documentation of the device-linking technique (early 2025); Netzpolitik documents on German customs messenger surveillance, via Privacy Guides (September 30, 2026).

NIST Just Rewrote the Post-Quantum Deadline. Your RSA-3072 Plan Is Out of Date

Mohammad Taha Azizi Ahad — Sat, 31 Oct 2026 11:23:43 +0000

On October 27, NIST published the final version of IR 8547, Transition to Post-Quantum Cryptography Standards. If you followed the draft from November 2024, you might think you know what it says. You probably don't, because the final version changed the one thing that mattered most.

The draft deprecated only the 112-bit parameter sets after 2030. That left a comfortable reading: RSA-3072, P-256 ECDSA, and Ed25519 looked acceptable until 2035. The final report closes that door. Every approved quantum-vulnerable public-key algorithm is deprecated after 2030 and disallowed under NIST standards and guidelines after 2035, regardless of key size.

That is not a small edit. It moves the algorithms most products actually ship today into the deprecation category, with just over four years on the clock.

What the schedule actually says

For signatures, RSA, ECDSA, and EdDSA are all deprecated after 2030 and disallowed after 2035. For key establishment, finite-field Diffie-Hellman, elliptic-curve Diffie-Hellman, MQV, and RSA key transport get the same treatment. The dates are the same as the draft. The scope is much wider.

"Deprecated" in NIST usage does not mean banned. It means the algorithm may still be used, but there is a security risk, and the data owner has to examine that risk and decide whether to continue. In practice, that turns into a documented risk-acceptance obligation. For federal high-value assets and high-impact systems, the grace period is shorter than it looks: an executive order from June 2026 requires post-quantum key establishment by December 31, 2030, and post-quantum signatures by December 31, 2031. Those systems do not get until 2035. They get 2030 and 2031.

And the report does not stop at federal systems. NIST explicitly positions it as a blueprint for critical infrastructure and other organizations. The deadlines reach private vendors through procurement, not through NIST directly.

How a government report becomes your vendor requirement

NIST IR 8547 is not binding on private companies. It reaches them through five mechanisms, and together they explain why this report functions as a vendor requirement in practice.

First, the executive order directs the FAR Council to propose a rule requiring covered contractors to comply with NIST's post-quantum FIPS by December 31, 2030. That proposed rule is due around December 19, 2026, under a 180-day clock. Second, OMB Memorandum M-26-15, issued in June 2026, tells agencies to build post-quantum integration into product requirements and to settle post-quantum responsibilities with FedRAMP cloud providers. Agencies owed their migration plans by October 22, 2026. Third, CISA published a list of product categories back in January 2026, from web browsers to endpoint encryption, where agencies "should acquire only PQC-capable products." Fourth, NIST is revising its module validation processes to move faster. Fifth, CISA owes minimum elements for a cryptographic bill of materials by around March 19, 2027.

If you sell software, cloud services, or hardware into any of those categories, expect to be evaluated on post-quantum capability in federal acquisitions now, not after the FAR rule lands. And vendors are unlikely to keep separate federal and commercial cryptographic baselines for long. One baseline wins, and it will be the post-quantum one.

A Government Accountability Office report from October found that none of the 24 agencies it reviewed had fully addressed all three preparatory practices: building a cryptographic inventory, identifying funding, and planning testing. The people with the biggest budgets and the clearest mandate are behind. That should tell smaller teams something: this is not a task you start in 2029.

The hybrid question finally has an answer

For builders, the most useful clarification in the final report is about hybrid key establishment, the approach that pairs ML-KEM with a classical exchange like X25519. Until now, it was unclear how such constructions would fare in FIPS 140 validation once the classical half became deprecated or disallowed. The final report answers it: as long as at least one input to an approved composite key-establishment technique comes from an approved scheme, the combination can be validated. A hybrid mode does not lose its validation status because its classical half ages out.

That removes the last respectable excuse to wait. You can ship hybrid now without painting yourself into a validation corner later.

Two cautions, though. A validated module that supports hybrid ML-KEM does not prove that a given deployment actually negotiates it. Capability and enablement are different things, and buyers should check which one they are getting. And on hybrid signatures, NIST is more careful: it will accommodate dual signatures in validation but notes that their security properties are complex and need careful analysis. Signatures are the slower, more operationally disruptive half of this transition. They touch certificate authorities, firmware signing, hardware security modules, and smart cards, and none of those move quickly.

NIST also named ML-KEM-768 as its recommended default parameter set, calling it a large security margin at a reasonable performance cost, and said it has no current plans to standardize additional KEMs beyond HQC. If you are picking a parameter set today and want the choice least likely to be second-guessed, that is the one.

What I would do this quarter

I build a small end-to-end encrypted messenger, and I went through this migration myself: ML-KEM-768 for key establishment and ML-DSA-65 for identity signatures, replacing a classical design. The protocol part was not the hard part. The hard part was everything around it: key storage, migration paths for existing sessions, and making sure a new key type did not silently break an old client. That experience shapes how I read this report, and it is why I think the practical checklist matters more than the dates.

First, make a cryptographic inventory. You cannot migrate what you cannot list. Walk your codebase and your infrastructure and write down every place a public key is generated, exchanged, stored, or verified. Include the boring ones: TLS certificates, code signing, backup encryption, JWT signing keys, SSH host keys. The inventory is the part the GAO found agencies missing, and it is the part most small teams skip.

Second, put ML-KEM-768 behind a flag in your key establishment path, hybrid with your existing classical exchange, and turn it on where you control both ends. Do not wait for a perfect migration plan. The hybrid validation answer means this step is safe to take now.

Third, design for crypto-agility from the start. The algorithm you pick today will not be the last one you ship. If swapping a KEM or a signature scheme requires touching twenty files and a database migration, fix that structure before you fix the algorithm. A clean seam between "what key type" and "what the protocol does with it" is worth more than picking the perfect parameter set.

Fourth, treat signatures as a separate, longer project. Key establishment can go hybrid quickly. Signatures touch trust roots, and trust roots move slowly. Start the inventory for signatures now, even if the migration itself takes years.

Fifth, watch two dates that are closer than 2030: the FAR proposed rule around December 19, 2026, and the CISA bill-of-materials elements around March 19, 2027. If you sell to anyone who sells to the government, those will show up in your contracts and questionnaires before the 2030 deadline does.

The deadline stopped being a draft

For two years, the post-quantum transition had the feel of a long-range plan: real standards, vague dates, and plenty of room to say "we will get to it." The final IR 8547 changes the texture of it. The dates are now attached to procurement rules, validation processes, and contract clauses. The deprecation scope now covers the strong classical defaults, not just the weak ones. And the agencies that were supposed to be ready first have, by the GAO's account, not finished their homework.

None of this means a quantum computer is about to break RSA next week. It means the paperwork, the procurement, and the product roadmaps have caught up with the standards. If your plan still says RSA-3072 and P-256 are fine until 2035, that plan is out of date as of October 27. Rewrite it now, while rewriting it is still cheap.

Sources: NIST IR 8547 (Final, October 2026); OMB Memorandum M-26-15 (June 2026); Executive Order 14412 (June 2026); GAO-27-108740 (October 2026); Cloud Security Alliance research note on IR 8547 (October 30, 2026).