DEV Community: Mohammad Taha Azizi Ahad

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).

Attackers adopted post-quantum crypto before most defenders finished the inventory

Mohammad Taha Azizi Ahad — Fri, 30 Oct 2026 11:23:49 +0000

On 21 October 2026, Kaspersky's Global Research and Analysis Team disclosed a campaign it calls Operation FlashHole, attributed to the Lazarus group. At least three organisations in South Korea were affected, in construction, software, and wired communication equipment manufacturing. The campaign dates back to at least July 2025.

That part alone would be a routine espionage report. The detail that stopped me is the cryptography. An updated Lazarus tool called LPEClient uses ML-KEM-1024, the post-quantum key encapsulation mechanism standardised by NIST, to protect the delivery of further malware. It receives four ML-KEM-1024 public keys, generates four shared secrets, and uses the resulting key with the Threefish cipher to decrypt the next payload.

I build a small experimental messenger with post-quantum key exchange, so I follow this migration closely. I expected the first large-scale post-quantum stories to be about banks, browsers, and government systems finishing their upgrades. I did not expect one of the clearest early examples to be an attack tool using the same standard to hide its own next stage. That inversion is worth sitting with, because it tells us something plain about how this transition will actually go.

What Kaspersky actually found

The reported chain starts with spear-phishing emails linking to fabricated portfolio and CV websites tailored to the targets. Visiting a malicious site likely led to an infection involving CrossWeb EX, financial security software widely used in South Korea. Kaspersky could not establish the exact trigger or how the software was abused, and that gap matters. Honest reporting leaves gaps visible instead of filling them with a confident story.

Two previously undocumented tools, TouchHub and ClientHub, then install additional malware, run commands, and communicate with the attackers. LPEClient sits in that chain as the delivery protection: the post-quantum key exchange guards the payload, not the initial lure.

Kaspersky researcher Sojun Ryu said the group's use of post-quantum cryptography traces back to at least September 2024, more than a year before this disclosure. FlashHole is not a one-off experiment. It is a habit forming over time.

The second campaign matters more than the first

FlashHole follows another disclosure from August 2026. Check Point Research reported that malware in an Operation Dream Job campaign, also tied to Lazarus, used Kyber/ML-KEM key exchange before downloading an exploit for a Windows zero-day, CVE-2026-68820. Microsoft patched that flaw on 11 August.

Two campaigns, two different target sets, the same pattern: use a modern, standard key exchange to protect the step where the attacker fetches something valuable. In Dream Job the targets were defence and aerospace companies in Europe and India. In FlashHole they were South Korean firms. The point is not the choice of victim. The point is that the cryptographic upgrade is now part of the attacker's normal toolkit.

That should end a lazy assumption I have heard in builder circles: that post-quantum cryptography is a defensive project, something good teams adopt and bad actors ignore because they prefer old, broken tools. Attackers adopt whatever works. They do not wait for a migration roadmap, a procurement cycle, or a compliance deadline. They pick a standard, implement it, and move on.

Post-quantum is not a side

This is the part people get wrong when they react to news like this. ML-KEM is not a signal of guilt, and it is not a reason to panic about every post-quantum handshake you see. Post-quantum key exchange is already routine on legitimate networks. Cloudflare has reported that a large and growing share of human-generated web traffic on its network uses post-quantum encryption. A handshake alone tells a defender almost nothing about intent.

What changes is where detection has to happen. If the payload is protected by a strong, standard key exchange, you cannot rely on reading it in transit to know it is bad. You have to look at the behaviour around it: the unusual process launch, code executing in memory, a legitimate Windows binary being abused, a sequence of steps that does not fit the machine's normal work. Kaspersky's report documents exactly that kind of surrounding activity, including CrossWeb EX launching a legitimate binary and malicious code running in memory. Stronger encryption and detectable intrusion activity can exist at the same time.

For defenders, that is actually useful news. It means the job does not become impossible when cryptography gets stronger. It becomes more behavioural. The question shifts from "can we read this?" to "does this sequence make sense on this machine, at this time, for this user?"

What this changes for builders

I am not writing this as someone running a large security team. My messenger is a small, experimental project, not an audited product, and I will not pretend otherwise. But building with ML-KEM has taught me a few practical lessons that this news sharpens.

First, start with an inventory, not a slogan. You cannot migrate what you have not listed. Which libraries negotiate keys, which services terminate TLS, which stored messages or files depend on a classical key exchange that a future quantum computer could break retroactively? A US executive order from June 2026 directs federal high-value assets and high-impact systems, excluding national security systems, to adopt post-quantum key establishment by 31 December 2030 and digital signatures by 31 December 2031. Those dates are not the point for a small builder. The point is that the inventory comes first, and it is the step most teams skip.

Second, prefer hybrid key exchange while the standards settle. In my own project I combine ML-KEM-768 with a classical ECDH exchange, so the connection does not rest on one new algorithm alone. Lazarus used pure ML-KEM-1024 in this tool. That is their choice for their purpose. For a messenger or a service that has to stay trustworthy if one algorithm turns out weaker than expected, hybrid is the more cautious design, and it matches where TLS itself has gone with hybrid ML-KEM combinations.

Third, treat signatures as a separate, slower track. Key establishment has moved faster than signatures in real deployments. That is normal: replacing a key exchange in a live protocol is painful enough, and replacing every signature, certificate, and verification path is a larger job. Plan them as two migrations with different timelines, not one big switch you flip on a Friday.

Fourth, do not let a post-quantum label do your security thinking for you. A protocol can use ML-KEM and still leak metadata, still trust a server it should not trust, still store keys badly, still fail open when verification fails. I have seen that temptation in my own work: add the new algorithm, feel modern, and stop asking harder questions about key storage, rekeying, and what happens when a device is lost. The label is not the system.

Fifth, keep detection and migration on the same plan. Migration protects future traffic. Detection catches the intrusion that is already happening. FlashHole shows why you need both at once. A team that only migrates will still miss the spear-phishing lure and the abused legitimate software. A team that only hunts intrusions will still leave years of recorded traffic exposed to harvest-now, decrypt-later attacks.

What this does not mean

It does not mean post-quantum cryptography is compromised, or that ML-KEM is broken, or that using it marks you as suspicious. Nothing in these disclosures says that. It means a strong, public standard is now available to everyone, including people you would rather it was not available to. That was always true of AES, of TLS, and of every good cryptographic tool before it. The strength of the math does not pick a side.

It also does not mean defenders are behind in some absolute sense. Many large networks already negotiate hybrid post-quantum key exchange by default. The gap is uneven: some teams have moved, some have not started, and attackers exploit the unevenness, not just the technology. The organisations in FlashHole were not necessarily careless. They were targeted with tailored lures and abused trusted software. That is a reminder that migration alone, without phishing resistance and endpoint visibility, is an incomplete answer.

The honest takeaway

When I started adding post-quantum key exchange to my messenger, I thought of it as future-proofing: something to do before it became urgent, so old messages would not be sitting around waiting for a future machine. FlashHole gives that idea a sharper edge. The future part is already here, and it is not arriving only through standards bodies and vendor roadmaps. It is arriving through attackers who read the same standards, implement the same algorithms, and use them to protect their own work.

That does not make the work pointless. It makes it normal. Post-quantum cryptography is becoming ordinary infrastructure, used by browsers, by cloud providers, by small builders like me, and by Lazarus. The builders who treat it as ordinary, unglamorous infrastructure, inventory first, hybrid where it makes sense, signatures on their own track, detection alongside migration, will be in much better shape than the ones waiting for a dramatic moment to act.

The dramatic moment already happened. It just did not look like a breakthrough. It looked like a malware report, published on a Tuesday in October, in which the attackers had simply kept up.

Sources: Kaspersky GReAT disclosure of Operation FlashHole, 21 October 2026, as reported by eWeek (https://www.eweek.com/news/lazarus-post-quantum-malware-apac-south-korea/); Check Point Research on Operation Dream Job, August 2026.

If anything here is wrong or unclear, I would rather hear it and fix it than leave it standing. That is how a small project earns trust it has not yet been audited to claim.

Your address should not be your key: what a post-quantum account upgrade gets right

Mohammad Taha Azizi Ahad — Thu, 29 Oct 2026 16:57:01 +0000

On 28 October 2026, a blockchain called Verona shipped an upgrade named Fermi. The headline feature is post-quantum signatures: accounts can now attach an ML-DSA-65 authenticator, the lattice signature standard from FIPS 204, and drop their old classical key if they want. For treasuries and cold vaults there is also SLH-DSA-128s, the hash-based standard from FIPS 205.

That part is not what caught my attention. Plenty of projects are adding post-quantum algorithms this year, and most of them will do it the hard way. What caught my attention is the part Verona did not have to do: nobody has to move. The address stays the same while the key underneath it changes.

That sounds small. It is the whole design lesson.

Most accounts are their key, and that is the trap

On most chains, your address is derived from your public key. Change the key and you change the address, which means you have to move everything: funds, permissions, history, every contract that knows you by that address. It is like changing the locks on your house by demolishing the house and building a new one next door, then telling everyone you know to update their address books.

Verona's announcement puts a number on what that costs at scale: it claims roughly a third of Bitcoin's supply sits in accounts with exposed keys. Whether that estimate is exact matters less than the shape of the problem. When the key and the identity are the same thing, a cryptographic migration becomes a mass relocation, and mass relocations do not happen cleanly. People miss the deadline, lose keys in the move, or simply never bother.

Verona avoided this by building accounts differently from the start. Every account is a smart contract that holds a set of pluggable authenticators. Today that set includes secp256k1 keys, passkeys, Ethereum wallets, JWT, and ZKEmail. Adding ML-DSA is, by their account, the same operation as adding a passkey. The contract owns the address, not the key, so the cryptography can change underneath while identity, history, and balances stay put. There is also a policy option that requires post-quantum authentication: an account can disable its classical keys, or force them to co-sign with a post-quantum key.

Read that as a vendor announcement, because that is what it is. It arrived as a GlobeNewswire press release, not an independent audit, and I have not verified their implementation. Phase two, moving validator keys to ML-DSA-65, is still ahead of them, and their convenience authenticators that depend on outside infrastructure, like JWT and ZKEmail, stay classical for now and cannot satisfy a post-quantum-required policy. The honest version of this story is that one project shipped a design that makes migration a key operation instead of a move, and the rest of the claims still need the usual scrutiny.

Even with that caveat, the design idea is worth stealing, because it is not really about blockchains.

I ran into the same shape of problem in a messenger

I build an encrypted messenger in the browser, and its protocol uses ML-DSA-65 identity signatures alongside a hybrid ML-KEM-768 and ECDH key exchange. When I added those signatures, the question that took the most thought was not which algorithm to pick. It was what happens to an identity when its keys change.

A messenger contact is, in practice, a key. If someone reinstalls the app, loses a device, or rotates keys after a scare, the other side sees a stranger unless something in the design says otherwise. Safety numbers, key transparency logs, and verification rituals are all patches over the same crack: the identity and the key material got fused together, and now every key event looks like an identity event to the user.

Verona's answer is to put a stable container between the two. The account is the container. Keys are members of it, added and removed by operations the container understands. That is a cleaner separation than most messengers have, and it maps directly: a contact identity that survives key rotation, with old keys revocable and new keys attachable, is strictly better than an identity that breaks every time cryptography moves.

It also changes how you think about algorithm agility. Verona ships lattice and hash-based signatures side by side, and says users can move between them if one assumption fails. It plans to add FN-DSA once NIST finalises FIPS 206. That is the right posture for a transition period. Nobody sane should bet a whole identity system on a single post-quantum algorithm in 2026. The bet should be on the ability to swap, not on the winner.

The migration problem is the problem

Verona's founder put it as "quantum resistance is a migration problem, not a technical problem." That line is marketing, but it is also accurate in a way that matters for builders outside crypto too.

The algorithms are standardised now. FIPS 203, 204, and 205 exist. NIST published its formal migration roadmap, IR 8547, on 28 October, the same week as Fermi, with federal deadlines for key establishment by 2030 and signatures by 2031. The UK's NCSC told organisations to finish cryptographic discovery and planning by 2028. The technical question, which algorithm, is largely settled. The operational question, how do you change the cryptography under a live system without stranding its users, is where projects will actually succeed or fail.

That is why I think Fermi is worth reading even if you never touch a blockchain. Ask of your own system the question Verona's design answers: can a user rotate to a post-quantum key without becoming a new user? If the answer is no, you do not have a migration plan. You have a moving day, and moving days are where things get lost.

Three practical things fall out of that question, and they apply to messengers, apps, and services alike:

First, separate the stable identifier from the key material, and make key rotation a first-class operation with its own audit trail, not a side effect of reinstalling or re-registering.

Second, support old and new algorithms at the same time during the transition, with a policy that can require the new one once you are confident, rather than a flag day where everything changes at once.

Third, make revocation as easy as enrollment. A post-quantum key you cannot remove is not much better than a classical key you cannot remove. The whole point is that keys are replaceable parts. Design them that way from the start, because retrofitting a container around a key-derived identity later is exactly the painful migration you were trying to avoid.

None of this makes quantum computers arrive sooner or later. No such machine exists today that breaks these signatures, and the timeline estimates keep moving. What it does is decide whether, when the migration becomes unavoidable, your users experience it as adding a key or as starting over. That difference is the difference between a system that survives a cryptographic transition and one that does not.

Verona still has to prove the rest: validator migration, real usage at scale, and the security of the contract layer that now guards every account. But the idea at the centre of Fermi is already portable, and it is free to copy. Build the container first. Keys come and go. The address, the contact, the account, that is what people actually need to keep.

India is about to tie WhatsApp to your SIM card. That changes what an account is.

Mohammad Taha Azizi Ahad — Wed, 28 Oct 2026 16:56:10 +0000

From 1 January 2027, using WhatsApp or Telegram in India may require something that has nothing to do with your password, your chats, or your encryption keys. Your registered SIM card will have to stay present and active in your phone. Take it out, let it go inactive, and access to the app may be blocked.

Web sessions get a second rule on top of that. WhatsApp Web and similar web clients will have to log out at least every six hours, and you will have to scan a fresh QR code from your primary phone to get back in.

This comes from India's Department of Telecommunications, under the Telecom Cyber Security Rules, 2024. The direction was first issued on 28 November 2025 to app-based communication services including WhatsApp, Telegram, Signal, Snapchat, Arattai, ShareChat, Josh and JioChat. Reports this month say the compliance deadline is 31 December 2026, with the operational rollout starting on 1 January 2027. Snapchat is reportedly exempt. Signal, according to the same reports, has not responded to the government notices.

The stated reason is fraud, and the numbers behind it are not small. Officials have linked scams run through untraceable or misused numbers to losses of more than 22,000 crore rupees a year. The specific scams named in the reporting are familiar ones: phishing, impersonation, and so-called digital arrest scams, where a caller pretends to be law enforcement and pressures a victim into paying. The logic of the rule is simple. If an account cannot be detached from a traceable SIM, it is harder to run a scam account at scale, and harder to keep using one after the number behind it is gone.

That logic is worth taking seriously, and so are its costs. Both are about the same question: what is an account, really?

A phone number was already an identity. A SIM check makes it a leash.

Most messengers already ask for a phone number at sign-up. That number is an identifier, and in many countries it is tied to a real person through SIM registration. But once you registered, the number mostly stayed in the background. You could move your SIM to another phone, leave an old phone at home on Wi-Fi, or use a tablet as your daily device, and the account kept working. Registration was a one-time check.

SIM binding turns that one-time check into a continuous one. The account is no longer just linked to a number. It is linked to a piece of hardware that must stay in the device, stay active, and stay in the right phone. That is a different kind of identity. It is not "you proved who you are once." It is "you keep proving, every day, that you still hold this SIM."

For many users, nothing will change. Their SIM is already in their main phone, and it stays there. The people who will feel it are the edge cases, and edge cases are where identity rules always break first:

Someone who uses an old phone as a Wi-Fi-only device, with the main SIM in a different handset.
Someone who keeps a work phone and a personal phone, and runs messaging on the one without the registered SIM.
Someone who switches handsets often, or who travels and swaps SIMs.
Someone who relies on a web client all day at a desk and will now be logged out every six hours, mid-work, and sent back to their phone for a QR code.

Reports say travellers on international roaming should be unaffected as long as the registered SIM stays active and inserted. That is reassuring, but it also shows where the line sits. The system does not care where you are. It cares whether the SIM is still in the phone. Presence has become the proof.

There is also an implementation gap that the reporting is honest about. How strictly each platform enforces the check, and on which devices, will vary. Apple reportedly shipped an iOS patch in September that can detect the absence of a SIM card, which helps developers implement the requirement on iPhones. Android is a more varied story, with different devices and configurations. A rule that lands differently on every phone is not quite one rule. It is a rule plus a set of platform quirks, and users will discover the quirks one failed login at a time.

A SIM proves a telecom account, not a person

This is the part builders should not blur. A SIM card proves that a device holds a subscription tied to a registered number. It does not prove that the person holding the phone is the person who registered that number. SIMs get swapped, stolen, handed to family members, and used in phones shared by a household. A fraudster who controls a SIM, or who socially engineers a carrier into issuing a replacement, passes a SIM check just as easily as a legitimate user does.

That does not make the rule useless. Raising the cost of running disposable accounts is a real gain against bulk scams. But it does mean SIM binding is an anti-abuse control, not an authentication upgrade. It answers "is this account still attached to a live, traceable number?" It does not answer "is this the right person?" or "is this the right key?" Those are different questions, and confusing them is how a fraud control gets sold as a security guarantee.

The same distinction applies to the six-hour web logout. As session hygiene, it is blunt but understandable. A stolen laptop, or a web session left open on a shared computer, stops being useful after six hours at most. As a daily experience, it is a tax on legitimate users, and a blunt timer is not the only way to get that hygiene. Per-device session lists, visible active sessions, one-tap revocation, and alerts when a new device links are all more precise tools. A timer that logs everyone out, careful user and careless user alike, is what you reach for when you do not trust the rest of the session system to do the job.

What this means for how I think about identity in my own messenger

I build a browser messenger, so I have had to make this choice in the other direction. My app does not use a SIM at all. A contact's identity in my app is tied to a key, and that key is checked with an ML-DSA-65 signature that the client verifies itself. If the signature does not verify, the contact does not get the verified badge, and a forged signature gets a loud warning instead of silent acceptance.

That design has its own trade-offs, and I do not want to pretend otherwise. A key you control is a key you can lose, and recovery is harder than calling a carrier for a replacement SIM. A SIM-tied account is easy to recover, precisely because a carrier can reissue it, but that also means the carrier is a gatekeeper over your account, and a point of failure if the carrier is tricked or compelled. A key-tied identity puts control and risk in the same place, with the user. A SIM-tied identity puts recovery in one place and control in another.

India's rule pushes the big commercial messengers further toward the carrier model. That is a policy choice with real benefits against a specific kind of fraud, and real costs for users whose setup does not match the assumed shape of one person, one phone, one SIM, always together. The question for builders watching this is not whether SIM binding stops some scams. It probably will. The question is what happens to the users it was not designed for, and whether the platforms will give them a clear path back in, or just an error screen.

There is a second question worth asking, and it is about precedent. India is a huge market for WhatsApp and Telegram. If a major market can require continuous SIM presence, other regulators will watch the rollout closely. A builder designing an identity system today should assume that phone-number identity may come with hardware strings attached in some markets, and that a design which only works when the SIM never leaves the phone is a design with a new failure mode built in.

A short, practical list

If you are in India and you use WhatsApp or Telegram, the reporting points to a few concrete steps before January:

Make sure the SIM linked to your account is active and inserted in the phone you actually use every day, not in a drawer or a second handset.
If you change your number, or move your SIM to another device, update your messaging registration promptly rather than leaving the old link in place.
If you depend on a web client, expect the six-hour logout and plan for the QR re-link. Do not leave a web session as your only way into an important conversation.
If you run a Wi-Fi-only tablet or a second phone as your main messaging device, rethink that setup now, while you still have time to move the SIM or the account.

If you build messaging software, the list is shorter and harder: decide what your account is tied to, say it plainly, and test what happens to a legitimate user when that thing disappears. A SIM, a key, a password, a device, each one fails differently, and your users will meet the failure mode you did not test.

India's rule is not about encryption. No message gets more or less encrypted because a SIM is in the phone. It is about the layer underneath encryption, the question of who is allowed to hold an account at all. That layer has always been a policy decision dressed up as a technical one. From January, in one of the world's largest messaging markets, the policy will be visible every time a SIM leaves a phone.

A note on honesty, as with my previous posts: my messenger is an experimental project built by one person. It has not been independently audited, and I do not present it as a finished product. This post is commentary on public reporting about India's Department of Telecommunications direction, not a claim about deployments I have not done.

Eight CA keys were guessable. The padlock never noticed.

Mohammad Taha Azizi Ahad — Tue, 27 Oct 2026 16:54:17 +0000

On Saturday 17 October 2026, a researcher who goes by Wayne ran a test over a public certificate corpus and found something that should not exist: intermediate certificate authority keys that could be recovered from their public certificates, near instantly.

Wayne reported it the same evening, with signed attestations to prove control of each key without publishing the private keys themselves. Chrome blocked the affected keys about 100 minutes later. Firefox followed the same night. Apple blocked them on 19 October, Microsoft on 20 October. Today, 27 October, Chrome is scheduled to remove the parent root, emSign ECC Root CA - G3, from its root store.

No browser broke. No padlock turned red for most users. That is the part worth sitting with. The system that is supposed to tell you who you are talking to failed at its root, and the fix arrived quietly, through update channels most users never see.

What actually broke

The eight keys belonged to eMudhra, an Indian certificate authority. Six were TLS intermediates, the kind that sign certificates for websites. Two were code signing intermediates, the kind that vouch for software publishers.

They were created at a key ceremony on 30 April 2025, inside hardware security modules. According to eMudhra's own account on Mozilla's bug tracker, an approved change to the key generation script, meant to test key wrapping, produced a second, weaker key pair. Because the labels looked alike, the weak keys were mistakenly used for the certificate requests, and then sent to Sectigo for cross signing.

The weakness was not a flaw in the elliptic curve math. It was a flaw in the randomness. Researchers described the private keys as effectively small integers, recoverable with a basic discrete logarithm attack in under a second. A P-384 private key is supposed to be a uniformly random number so large you cannot write it down casually. These were not.

That distinction matters. Nobody hacked a server and stole these keys. Nobody needed to. The keys were weak from the day they were made, and they stayed in the public record for more than a year before anyone tested the corpus in the right way. Anyone who had done the same test earlier could have recovered them too. We cannot prove they did not.

There is also a detail that made the response harder than "revoke the certificate." Each affected intermediate also existed as a copy cross signed by Sectigo, with the same public key. Blocking one certificate would not have been enough, because the same key would still be trusted through the other chain. Trust stores had to block the keys themselves, by their public key hash, not just one certificate in the chain. Chrome did that through CRLSet, its pushed blocklist. Firefox did it through OneCRL. That is why the fix could reach browsers without a browser update or a restart, and why it is also easy to overstate how complete the fix was.

The good news, stated carefully

So far, there is no public evidence of misuse. Google reported that no TLS certificates chaining to the affected intermediates had been logged in Certificate Transparency logs before the block. eMudhra says the affected intermediates issued no end user certificates at all, and that its infrastructure was not breached.

Both statements are worth believing and worth limiting. Certificate Transparency only helps if the client enforces it. A forged certificate that never enters a public log will be rejected by a browser that requires logging, but it can still be accepted by software that does not check. And there is no equivalent public log that would prove the two code signing keys were never used to sign malware. Absence of evidence in one log is not a clean bill of health for every client.

Chrome also checked the rest of its root store and reported no other CA with the same failure mode. Mozilla said the same. That limits the blast radius to one ceremony, at one CA. It does not change the structural point: the web's identity system rests on a few hundred private keys held by a long tail of organisations, and one bad script at one ceremony was enough to make any site forgeable, in principle, for anyone who recovered those keys.

Why a browser fix is not a full fix

This is the part that applies directly to builders, and it is the part most coverage skipped.

A distrust decision is not protection until every verifier that matters has consumed it. Chrome and Firefox have fast, pushed blocklists. That covers people browsing the web. It does not automatically cover:

A server or proxy with its own curated certificate bundle
A container image built months ago with an old trust store
A Python app shipping an old certifi bundle, a Java app with an old keystore, a Go binary built before its runtime update
A mobile app that bundles its own certificates, or a desktop app with an embedded browser that does not use the system store
An internal tool that never updates because nobody owns it

The Dart and Flutter advisory on 23 October made this concrete: apps on Android, Windows, and Linux needed a rebuild, not just a local SDK update, because the fix lived in the shipped runtime. Updating your own browser proves nothing about the app you shipped to someone else six months ago.

eMudhra's exit makes the long tail visible in another way. The company has decided to leave the global TLS certificate business, a segment it says is about 1 percent of its revenue, and to move customers to other providers at no cost. When Chrome removes the G3 root today, any legitimate site still chaining to it stops being trusted until it switches hierarchy. That is not a punishment. It is the cost of the only lever root programs have when a blocklist cannot reach every client: remove the root, and accept that legitimate sites break alongside the bad keys.

So the timeline of this incident is really two timelines. The browser timeline took hours. The long tail timeline will take months, and nobody will announce when it ends, because nobody owns a complete list of every trust store in the world.

What I am taking from this for my own project

I build a browser messenger, so I cannot pretend to stand outside the CA system. My app is served over TLS like everything else, and a forged certificate for my server's domain would be a real attack against a user who trusts the padlock alone.

That is exactly why I separated two questions that are easy to confuse. TLS answers "are you talking to the server this domain points to, according to the CA system?" My messenger's identity signatures answer a different question: "is this contact key signed by the identity it claims to be?" The second check uses ML-DSA-65 signatures that my client verifies itself, against identity keys, not against a CA chain. A forged TLS certificate does not forge a contact's identity signature.

I am not claiming that makes my app immune to a CA compromise. A forged server certificate could still serve a tampered client to a new visitor, which is why the server side still depends on the same CA system as everyone else, and why I am not going to dress this up as a solved problem. The point is narrower and, I think, more useful: if your only identity check is the padlock, then a CA failure is a total identity failure. If you have a second, independent check on the thing that actually matters, the contact's key, then a CA failure is still serious, but it is no longer the whole story.

The same logic applies to any app that pins its trust to one system. Pinning a certificate helps against a rogue CA, but it creates its own maintenance burden when the pinned certificate rotates. A transparency log helps detect forgery, but only for clients that enforce it. A second signature, verified by the client against a key the user already trusts, helps in a different direction. None of these replaces the others. The eMudhra week is a reminder to count how many independent checks stand between your user and a wrong key, and to be honest about which of them you actually enforce.

A short checklist, for this week

If you run anything that serves or consumes TLS, this incident gives you a concrete list, and it costs less than the next incident will:

Search your estate for eMudhra chains, especially the G3 roots, in server bundles, proxies, containers, and mobile app bundles. If you find a legitimate certificate chaining to the removed root, replace it now, not when users report errors.
Update the trust stores you actually ship, not just the browser on your laptop. Rebuild apps with bundled runtimes and certificate bundles, and check base images you have not rebuilt in months.
Find the clients that do not enforce Certificate Transparency and do not receive pushed blocklists. Those are the ones a forged, unlogged certificate could still fool. Decide what you will do about them, rather than assuming the browser fix covered them.
If you generate keys in a ceremony or a script, add the checks that would have caught this: verify that the public key in the request matches the key the hardware module actually generated, verify a test signature, and reject any key that is degenerate or suspiciously small. A ceremony is a process, and a process needs a check at the step where a human can pick the wrong label.

The deeper lesson is about where cryptography fails in practice. The math in this incident did not fail. The process around the math failed, quietly, at a step that looked administrative: a script change, a similar label, a wrong key selected. Then the failure sat in public for over a year, visible to anyone who ran the right test, because nobody had made that test routine.

Post-quantum migration gets most of the attention right now, and it should. But the next identity failure in your system is at least as likely to look like this one: not a broken algorithm, but a key that was never as strong as its label claimed, in a trust store nobody remembered to update.

Check yours. The browser already did its part. The rest of the list is yours.

A note on honesty, as with my previous posts: my messenger is an experimental project built by one person. It has not been independently audited, and I do not present it as a finished product. This post is commentary on a public incident, based on reports from Google, Mozilla, Apple, Microsoft, and eMudhra, not a claim about deployments I have not done.

Signal stopped asking you to compare safety numbers. That is the real story.

Mohammad Taha Azizi Ahad — Mon, 26 Oct 2026 16:54:25 +0000

Nobody compared safety numbers. That is the uncomfortable truth behind one of the best-known rituals in encrypted messaging.

Signal gave every conversation a safety number, a fingerprint of the two sides' keys. If the number changed unexpectedly, something might be wrong. The correct response was to meet the other person, or call them on a channel you trusted, and compare the numbers character by character. It was sound cryptography. It was also something almost no normal user ever did, because it asked people to interrupt a conversation to perform a chore they did not understand, for a threat they could not see.

In August 2026, Signal shipped a different answer: Automatic Key Verification. You can still compare safety numbers by hand if you want to. You no longer have to. That shift matters more than most feature announcements, because it fixes the part of encrypted messaging that was always weakest: not the encryption itself, but the question of whether you were given the right key in the first place.

Encryption answers one question. Key distribution answers another.

End-to-end encryption is usually explained as "only you and the other person can read the messages." That sentence hides an assumption. It assumes the key your app fetched for the other person really belongs to them.

If a server, or someone who compromised a server, hands you an attacker's key instead, your messages are still perfectly encrypted. They are just encrypted to the wrong person. The attacker reads them, re-encrypts them to the real recipient, and nobody notices. No cipher is broken. The directory lied, and the encryption did exactly what it was told to do.

That is why messengers invented safety numbers, and why WhatsApp later built its own key transparency system. The problem was never secret. The problem was that the only check on offer required human effort at exactly the moment humans are least likely to give it.

What Signal actually built

Automatic Key Verification is built on key transparency, and the idea is refreshingly simple once you strip away the terminology.

Every time a user registers, changes a phone number or username, or recreates an account, Signal records that change in an append-only log, a tree of entries that can only grow. A second structure, a set of prefix trees that act like index books, lets anyone look up the current entry for a given account without downloading the whole log.

On its own, that log would not prove much. Signal runs the log, so Signal could in principle show you one version of it and show someone else a different one. Both versions would look locally valid. That split-view attack is the whole reason the system has auditors.

Three auditors independently track the log and periodically sign its root: one run by Signal itself, one by Cloudflare, and one by Trail of Bits. A Signal client doing automatic verification requires recent signatures from all three before it shows the green checkmark and the words "Encryption verified." Trail of Bits has said the signatures must be no more than seven days old, which bounds the attack: a fully malicious server could maintain a split view for at most about a week before clients start warning. The auditors, importantly, do not see your phone number or username in plaintext. They check the structure of the log, not the identities inside it.

In practice, you turn the feature on under Settings, Privacy, Advanced, or verify a single contact from their safety number screen by choosing "Verify automatically." If it succeeds, you get a checkmark. If it fails, you fall back to the old manual comparison. If you do not want to trust Signal and the auditors at all, you can switch automatic verification off and keep doing it by hand.

What it does not do

A green checkmark is not a proof of who a person is in the real world. It proves consistency: that everyone on the network is seeing the same mapping between an account and a key, and that the mapping has not been quietly swapped for one person only. It does not prove that the account itself belongs to the friend you think it does. If someone takes over a legitimate account completely, the log will faithfully record the attacker's new key, and verification will pass.

There are practical limits too. Automatic verification currently depends on Signal having the contact's phone number, so it may not be available for a conversation started from a username alone. And the seven-day signature window is a trade-off, not a magic number: it is short enough to catch a sustained lie, long enough to survive an auditor being briefly offline. Anyone describing this as eliminating man-in-the-middle attacks entirely is overselling it. What it eliminates is the silent, targeted, long-term version, the one where only you get the wrong key and nobody else ever finds out.

That distinction is worth keeping. Security features that promise everything usually deliver a slogan. This one promises something specific, and delivers that.

Why this hit home for me as a builder

I ran into the same question from the other side while building my own browser messenger. Encryption was the easy part to explain. Authentication was where the real attack lived, so I added ML-DSA-65 identity signatures: a contact only earns the post-quantum badge in my app when both the ML-KEM key and the ML-DSA signature over it verify, and a forged signature gets a loud red warning instead of silent acceptance.

That is a direct check. It answers "is this key signed by the identity it claims?" Signal's approach answers a different question: "is everyone seeing the same key for this account?" Mine needs no auditor, but it gives you no global consistency proof. Signal's gives you the consistency proof, but asks you to trust a small set of auditors and a signature freshness window.

Neither is strictly better. They solve adjacent problems, and a serious messenger probably needs both kinds of answer eventually: a signature that ties a key to an identity, and a transparent record that ties that identity to the same key everywhere. What Signal got right, and what I am taking from it, is the shape of the user experience. Verification that happens automatically, with a clear pass state and a manual fallback when it fails, will protect more people than a perfect manual ritual that nobody performs.

There is a lesson here for small builders too. We tend to treat verification UX as polish, something to add after the protocol works. Signal's history suggests the opposite order. The protocol worked for years. The verification step was the part users skipped, which meant the protocol's guarantee quietly depended on a step that was not happening. When you design a messenger, the check is part of the security, not decoration around it. If your users cannot tell a verified contact from an unverified one at a glance, or if verifying takes more effort than sending the message, you have built a lock and left the key under the mat.

The question worth asking

Key transparency is spreading because the industry finally admitted something builders have known for a while: a key directory is a trust decision, and trust decisions need evidence, not just a server's word. WhatsApp went there first, Signal has now gone there with independent auditors and a public design, and the pattern is clear enough that any new messenger will have to answer it.

So the question is no longer whether your messages are encrypted. Every serious messenger can say that now. The question is: how would you know if you were given the wrong key, and how long would it take you to find out?

Signal's answer, as of August 2026, is: automatically, within about a week at most, without you having to compare anything. That is not a perfect answer. It is a much more honest one than asking you to compare safety numbers and hoping you bother.

If you have built key verification yourself, I would like to hear which side you chose: direct signatures, a transparency log, or both. That is the design decision I am least sure about in my own project, and Signal just gave all of us a serious reference point to argue against.

Post-quantum encryption just got a deadline: what the UK's October 2026 TLS guidance means for builders

Mohammad Taha Azizi Ahad — Sun, 25 Oct 2026 16:54:09 +0000

For years, post-quantum cryptography was easy to postpone. The standards were still moving, the libraries were still catching up, and "we will migrate when it is final" was a reasonable answer. On 15 October 2026, that answer got a lot weaker.

That day, the UK National Cyber Security Centre published updated TLS guidance that explicitly recommends hybrid ML-KEM key exchange. It follows the IETF finalising RFC 10024, which standardises hybrid post-quantum key agreement for TLS 1.3. The NCSC also set a date: organisations should have completed cryptographic discovery and migration planning by 2028.

This is not a story about a quantum computer arriving next Tuesday. It is a story about deadlines arriving before the threat does, and about what builders are supposed to do with the time in between.

What actually changed

RFC 10024 defines three hybrid key agreement mechanisms for TLS 1.3:

X25519MLKEM768
SecP256r1MLKEM768
SecP384r1MLKEM1024

Each one combines a classical key exchange with ML-KEM, the NIST-standardised post-quantum key encapsulation mechanism. The NCSC guidance treats these as suitable for general use and for OFFICIAL-tier government data. It also draws a clear line around TLS versions: only TLS 1.3, configured this way, gives you quantum protection. SSL and TLS 1.0 and 1.1 are deprecated and should be off. TLS 1.2 still protects against classical attacks when configured well, but the guidance says to plan a move to TLS 1.3 if you want post-quantum protection at all.

That last point matters more than it looks. A lot of migration talk focuses on swapping an algorithm. In practice, the first obstacle is usually the protocol version, the old client, or the load balancer nobody has touched in three years. The algorithm is the easy part to name. The inventory is the hard part to finish.

Why hybrid, and why that choice is honest

Pure post-quantum would be cleaner on paper. Hybrid is what got standardised, and I think that is the right call.

A hybrid exchange fails safe in two directions at once. If ML-KEM turns out to have a flaw nobody saw yet, the classical half still protects the connection today. If a quantum computer arrives sooner than expected, the ML-KEM half protects it tomorrow. Neither half has to be perfect on its own, because the combination only breaks if both break.

This is the same reasoning I used in my own messenger, where the key exchange pairs ML-KEM-768 with ECDH P-256. I did not choose hybrid because I could not decide. I chose it because migration is a transition, not a switch, and a transition needs a design that works in both worlds while it lasts. Seeing the same pattern in a national guidance document and an IETF standard is reassuring, but it is not a surprise. It is what careful migration looks like when it leaves the lab.

The honest label still matters. A hybrid connection is not "quantum-proof" in some absolute sense. It is protected against a quantum attacker as far as its post-quantum half holds, and it still depends on the implementation being correct, the keys being handled well, and the rest of the system not leaking the plaintext somewhere else. Anyone selling hybrid as a magic shield is selling something else.

The 2028 deadline is about homework, not a flip of a switch

Read the NCSC date carefully. 2028 is the deadline for discovery and migration planning, not for every system on earth to be fully post-quantum. That distinction is the whole plan.

Discovery means answering questions most teams cannot answer today: where do we use public-key cryptography, which libraries and certificates depend on it, which data stays sensitive for ten years or more, and which vendors need to move before we can? If you cannot list your cryptography, you cannot migrate it, and no deadline will fix that for you.

Then comes the prioritisation, and here the old phrase "harvest now, decrypt later" finally earns its keep. An attacker can record encrypted traffic today and decrypt it later, once a capable quantum computer exists. That only matters for data that will still be sensitive then. A chat message about lunch plans is not the same as a medical record, a trade secret, or a credential that stays valid for a decade. The systems carrying long-lived secrets go first. Everything else follows in order of exposure, not in order of panic.

The rest of the world is moving on a similar clock, which makes the UK guidance part of a pattern rather than an outlier. Reports of the 2026 migration landscape point to 1 January 2027 for new US national security system purchases, 2030 for quantum-safe key exchange in high-value federal and EU critical systems, and 2035 for most of the remainder, with France planning to stop certifying products that are not quantum-safe from 2027. The exact dates differ by country and sector. The direction does not.

What this means if you are a small builder, not an enterprise

Guidance written for government and enterprise can feel remote if you are one person with a side project. It should not. Three things from this month's news apply directly at small scale.

First, the infrastructure is already there. Chromium-based browsers have shipped hybrid X25519MLKEM768 by default since version 131. Cloudflare reported in April 2026 that more than two-thirds of human-generated TLS traffic to its network was already protected with hybrid ML-KEM, and moved its target for full post-quantum security forward to 2029. If you deploy behind a modern CDN or proxy, you may already be closer than you think. Check, do not assume.

Second, the work starts with a list, not a purchase. Open your project and write down every place a public key appears: TLS termination, certificates, signed updates, API tokens, backup encryption, the database connection. That list is your migration plan in its first draft, and it costs nothing but an evening.

Third, do not forget authentication. Key exchange is only half the story, and it is the half that got standardised first. Signatures are the other half: a connection encrypted to the wrong person is still a failure, even if nobody can read it in transit. ML-DSA is the post-quantum signature standard, and the same inventory exercise applies to it. I wrote about adding ML-DSA signatures to my messenger precisely because encryption without verified identity left the most obvious attack open. The NCSC guidance is about TLS key exchange; it does not magically fix who you are talking to.

What this does not fix

A guidance document does not patch your code, rotate your keys, or protect data that leaks through metadata, logs, backups, or an endpoint that was never encrypted in the first place. Post-quantum TLS protects data in transit between two endpoints that both support it. It says nothing about what those endpoints do with the data afterwards, who else can read it on the server, or how long it is kept.

That is not a criticism of the guidance. It is a reminder that cryptography is one layer, and the layer most likely to fail in a real project is usually the boring one: key storage, access control, old backups, a debug endpoint left open. The teams that do well in this migration will be the ones that treat the algorithm swap as one item on a longer list, not as the list itself.

The takeaway

The era of "post-quantum is a research topic" ended this month, at least officially. The standards exist. A major national authority has recommended them. The deadlines are written down, and the first one, 2028, is about knowing what you have.

If you build anything that encrypts data, start the inventory this week. Find your long-lived secrets first, move the TLS 1.3 and hybrid ML-KEM work up the list, and keep the labels honest about what is hybrid and what is not yet migrated.

The quantum computer is not here yet. The homework is, and for once it arrived early enough to actually do.

A note on honesty, as with my previous posts: my messenger protocol is an experimental project built by one person. It has not been independently audited, and I do not present it as a finished product. This post is commentary on public guidance and standards, not a claim about enterprise deployments I have not done.

When someone leaves the group: how my messenger rotates group keys

Mohammad Taha Azizi Ahad — Sat, 24 Oct 2026 17:43:27 +0000

One-to-one chats are the easy case. Group chats are where key management gets genuinely hard, because the group itself changes. Someone joins. Someone leaves. Someone's phone is replaced. Every one of those events has to change what the group can read — without breaking the messages already in flight.

This post is about how my protocol, PQ-MPRBA, handles that: a small state machine called the Group Epoch FSM.

The two promises a group chat has to keep

When a member leaves, they must not be able to read future messages. That is forward secrecy for groups.

When a member joins, they must not be able to read past messages. That is backward secrecy for groups.

Both sound obvious. Both are easy to get wrong. The classic failure is rotating the key but letting old messages stay decryptable with the old key, or rotating so aggressively that half the group loses messages during the transition.

Epochs instead of one key

Instead of one group key, the group moves through epochs. Each epoch has its own key material, and the group is always in one of three states:

STABLE — normal chatting, one current epoch.
ROTATING — a membership change has triggered a rotation, and the new epoch is being distributed.
STABLE again — everyone has the new epoch, and the old one is retired.

The state machine is deliberately boring. There are no clever shortcuts, just three states and clear transitions. In security code, boring is a feature.

The grace buffer that saves your messages

The tricky part is the transition. When rotation starts, some messages encrypted under the old epoch are still traveling through the network. If you delete the old key the instant rotation begins, those messages arrive undecryptable and the chat looks broken.

So the protocol keeps a grace buffer of three epochs. During rotation, the group can still decrypt messages from the previous epochs while everyone moves to the new one. Once the transition is complete and the buffer slides forward, the old keys are wiped — with the same zeroization discipline as the one-to-one ratchet.

Three epochs is a judgment call, not a law of nature. One would break messages. Ten would keep old keys alive too long. Three covers a realistic transition window without turning the buffer into an archive.

Why this matters beyond groups

The same pattern shows up everywhere keys have a lifetime: sessions, devices, teams. The lesson is general — a key rotation is not an event, it is a transition, and transitions need a defined state machine, a bounded grace period, and a real deletion at the end. Skip any of the three and you get either broken messages or keys that never die.

What is still honest to say

As with the rest of PQ-MPRBA, this is experimental work by one person, not independently audited. The group rotation is implemented and used in my messenger, but I will not claim it has survived adversarial review. The design is public so it can be criticized — that is the point of publishing it.

The code is open source: https://github.com/indirect-b/chat-app

If you have built group key rotation yourself, I would love to hear how you sized your grace window — that is the number I am least sure about.

Forward secrecy in practice: how my messenger's ratchet works

Mohammad Taha Azizi Ahad — Sat, 24 Oct 2026 17:42:43 +0000

In my last two posts I introduced my browser messenger and the identity signatures I added to it. This one is about the machinery underneath both: the ratchet. It is the part that decides what happens when something goes wrong — when a key leaks, when messages arrive out of order, when an attacker records everything today and hopes to decrypt it tomorrow.

Why forward secrecy is the whole point

Most people think encryption is about keeping a message secret right now. Forward secrecy is about keeping it secret forever. If someone steals your phone, or a server log, or a session key next year, they should not be able to rewind and read last year's messages.

A ratchet gives you that by never reusing a key. Every message gets a fresh one-time AES-256-GCM key, derived from a chain that moves forward and never goes back. Old keys are not stored anywhere. There is nothing to steal that unlocks the past.

A hybrid chain

My protocol, PQ-MPRBA, builds the chain from two shared secrets at once: ML-KEM-768, the post-quantum key encapsulation mechanism, and classical ECDH P-256. Both feed HKDF-SHA256, which drives a symmetric ratchet chain.

Why both? Because migration is a transition, not a switch. ML-KEM protects against a future quantum attacker. ECDH keeps the whole thing working with today's infrastructure and libraries. The honest label is hybrid — and the day the classical half is no longer needed, it can be dropped without redesigning the chain.

Out-of-order messages and skipped keys

Real networks do not deliver messages in order. If message 5 arrives before message 4, you cannot just throw message 5 away — but you also cannot rewind the chain to decrypt it later without keeping old keys around, which is exactly what forward secrecy forbids.

The standard answer is a bounded skipped-key cache: when a message arrives early, you derive and hold its key just long enough for the missing messages to catch up, then wipe it. In my implementation the cache is deliberately small — at most 100 skipped keys, with a 10-minute lifetime. Anything older than that is gone, and a late message past that window simply cannot be decrypted. That is a real trade-off, and I chose the strict side of it: a lost message is better than a kept key.

Zeroization is not optional

Deleting a key in most languages just marks memory as free. The bytes can sit there until something overwrites them. So after a key is used, my implementation explicitly zeroes the memory that held it.

This is the least glamorous part of the whole protocol and one of the most important. Forward secrecy fails silently if old keys linger in RAM, in a swap file, or in a crash dump. The ratchet only works if "deleted" actually means deleted.

Post-compromise recovery

The other direction matters too. Suppose an attacker does compromise a session key — not the past, but the present. A ratchet heals: as soon as new messages flow, the chain advances past the compromised state, and the attacker is locked out again without anyone having to notice or re-authenticate.

That self-healing property is why ratchets beat the simpler alternative of one long-lived session key. A single key is a single point of failure forever. A chain is a failure with an expiry date.

What is still honest to say

This is an experimental protocol built by one person, and it has not been independently audited. The hybrid design still carries a classical ECDH half, so the whole thing is not purely post-quantum yet — it is labeled as hybrid, on purpose.

But the principles are not experimental: fresh keys per message, bounded skipped keys, real zeroization, and a chain that heals. Those four ideas are what forward secrecy actually is, and they are all in the code.

The code is open source: https://github.com/indirect-b/chat-app

Next time I will write about the group side of the same protocol — what happens to the keys when someone joins or leaves a group chat.

Post-quantum messaging in the browser: why I added ML-DSA signatures to my messenger

Mohammad Taha Azizi Ahad — Sat, 24 Oct 2026 17:05:46 +0000

A few days ago I wrote about building a post-quantum encrypted messenger that runs entirely in the browser. The encryption part got the most attention — and rightly so. But encryption alone was never the whole story. This post is about the part I added next, and why it mattered just as much: identity signatures.

Encryption is not authentication

My protocol, PQ-MPRBA, started with a hybrid key exchange: ML-KEM-768 combined with ECDH P-256, feeding into HKDF-SHA256 and AES-256-GCM. That gives you confidentiality — nobody in the middle can read your messages, not today and not with a future quantum computer.

But confidentiality answers only one question: can anyone read this? It does not answer a harder one: am I really talking to you?

If an attacker can swap in their own public key, they can sit in the middle of a conversation that is perfectly encrypted — just encrypted to the wrong person. Classical signatures like ECDSA would not save you here either, because a sufficiently powerful quantum computer breaks those too. So a post-quantum messenger needs post-quantum signatures, not just a post-quantum key exchange.

What I added: ML-DSA-65 identity signatures

The upgrade signs each identity bundle: the ML-KEM-768 public key is now published together with an ML-DSA-65 signature over it, and the other side verifies that signature before trusting the key.

In practice this changed three things in the app:

A real badge, not a vibe. A contact only earns the PQ badge when both pieces check out: a valid ML-KEM key and a valid ML-DSA signature. Either one missing, no badge.
Forged keys get called out. If a signature does not verify, the UI says so loudly — in Persian, in red — instead of silently accepting the key.
Classical fallback stays honest. Where a contact has no PQ material at all, the app still shows the classical fallback state instead of pretending otherwise.

Three lessons from the upgrade

Signatures are as important as encryption. Everyone talks about key exchange when they talk about post-quantum migration. In a messenger, authentication is where a real attacker actually starts.

Hybrid is pragmatic, not impure. Keeping ECDH alongside ML-KEM during the transition is not a weakness to hide — it is how you ship something that works with both today's infrastructure and tomorrow's threats. The honest thing is to label exactly what is quantum-safe and what is not.

Users need to see trust, not just have it. A badge and a warning in plain language do more for real security than a perfect protocol nobody understands. If users cannot tell a verified contact from a forged one, the cryptography does not matter.

What is still honest to say

This is still an experimental protocol built by one person. It has not been independently audited, and I will not pretend otherwise. The bundle still carries a classical ECDH ephemeral key, so calling the whole thing "fully post-quantum" would be an overstatement — the direction is fully post-quantum, the current state is hybrid and clearly labeled.

That honesty is the point. Post-quantum migration is not a switch you flip; it is a series of steps, each one labeled, each one verified.

The code is open source: https://github.com/indirect-b/chat-app

If you are building something similar, I would love to hear how you handled the authentication side — that is where I learned the most.

I built a post-quantum encrypted messenger in the browser — here's how it works

Mohammad Taha Azizi Ahad — Wed, 21 Oct 2026 00:42:46 +0000

I built a post-quantum encrypted messenger in the browser

Most web messengers either skip end-to-end encryption entirely, or bolt on a classical key exchange that a future quantum computer will retroactively break. I wanted to see how far you can push real, post-quantum E2EE inside a browser — so I built one.

Meet chat-app: a real-time Persian web messenger where every message is protected by PQ-MPRBA, an original browser-native protocol combining a hybrid post-quantum ratchet with blinded authentication. The server never sees plaintext — and never learns who is talking to whom.

🚀 Try it live: https://chatapp-server-1i2a.onrender.com — hit ⚡ Quick Test Login, no sign-up needed.
⭐ Source: https://github.com/indirect-b/chat-app

Why post-quantum, and why now?

Classical elliptic-curve cryptography (ECDH, RSA) is fine against today's computers. It is not fine against an adversary who records your encrypted traffic today and decrypts it later, once a sufficiently powerful quantum computer exists. This is the "store now, decrypt later" problem, and for a messenger, it's the whole ballgame: chat history is exactly the kind of data that stays sensitive for decades.

The fix is a hybrid approach: combine a post-quantum key encapsulation mechanism with a classical one, so breaking a session requires breaking both hard problems. That's what chat-app does.

The protocol: PQ-MPRBA

PQ-MPRBA stands for Post-Quantum Multi-Party Ratchet with Blinded Authentication. It runs entirely in the browser, on top of the Web Crypto API.

Layer 1 — Hybrid post-quantum ratchet

Each session combines ML-KEM-768 (NIST FIPS 203, lattice-based) with classical ECDH P-256. Both shared secrets feed HKDF-SHA256 into a symmetric ratchet chain, and every message gets a fresh one-time AES-256-GCM key. That gives forward secrecy and post-compromise recovery: even if a key leaks, past messages stay safe and future ones heal.

Two hard engineering problems hide inside that sentence:

Out-of-order messages. On unstable networks, message #3 can arrive before #2. A naive ratchet would lose #2 forever. chat-app's ratchet fast-forwards and caches skipped one-time keys in a bounded in-memory vault (100 keys per room, 10-minute TTL). Consumed keys and ML-KEM secrets are zeroized in RAM the moment they're used.

Group key rotation. When someone joins or leaves a group, the group key must rotate — without corrupting messages already in flight. A deterministic finite state machine (STABLE → ROTATING → STABLE) queues outgoing messages during rotation, and a 3-epoch grace buffer keeps messages sent milliseconds before the change decryptable.

Layer 2 — Blinded authentication (Ristretto255-VOPRF)

Standard E2EE hides message content, but the server still sees who authenticates. chat-app uses a Verifiable Oblivious Pseudorandom Function over Ristretto255 (RFC 9497): the client blinds its identity locally, the server evaluates it with its secret key and returns a DLEQ zero-knowledge proof, and the client unblinds the result into an unlinkable routing token. The server can authenticate users without ever seeing — or linking — their identities, using compact 32-byte group elements instead of heavy RSA blind signatures.

What the app actually does

Beyond the cryptography, it's a complete messenger:

Real-time direct & group messaging (Socket.IO, WebSocket + long-polling fallback)
Login with Bale ID (OTP delivered by a Bale bot) plus a 1-click quick test login
Typing indicators, presence, reactions, message edit/delete/pin/forward, read receipts
Voice notes & file attachments up to 50 MB, processed off the main thread in Web Workers
PBKDF2 room passphrases (100,000 iterations)
A stealth admin dashboard at an obfuscated, server-side-only path
Dual-mode persistence: PostgreSQL when configured, otherwise an atomic, mutex-guarded JSON store — so it survives free-tier redeploys

The stack

Layer	Technology
Frontend	React 19, TypeScript, Vite, modular RTL CSS
Crypto	Web Crypto API, `@noble/post-quantum`, `@noble/curves`, Web Workers
Backend	Node.js, Express, Socket.IO, Helmet, CORS, rate limiting
Auth	Bale OTP bot + Ristretto255-VOPRF blinded tokens
Storage	PostgreSQL or atomic JSON fallback; hybrid media blobs + disk

The server is deliberately a zero-knowledge forwarder: it routes ciphertext and blinded tokens, nothing more.

An honest disclaimer

PQ-MPRBA is an original, experimental protocol I designed and implemented for this project. It has not been independently audited. I built it to learn, to push what's possible in a browser, and to invite scrutiny — not to claim it's production-grade for high-risk use. If you're a cryptographer, I'd genuinely love your review: the core lives in src/utils/crypto.ts.

What's next

Independent review of the protocol
Better group UX and message search
A proper audit of the server-side hardening

If this kind of thing interests you, try the demo, star the repo, and tell me what breaks. That's how it gets better.

⭐ https://github.com/indirect-b/chat-app