Editor’s note (2026-04-29): the work this post describes was correct at the time but wasn’t the end of the story. The voice keying described below, per-channel symmetric keys distributed via the same X25519+ML-KEM-768 hybrid wrap as DM text, was already post-quantum. It just wasn’t standardized. We’ve since replaced it with MLS 1.0, the same protocol family Discord DAVE, Wire and Element use. That keeps the post-quantum property and adds per-sender authenticity, forward secrecy on leave, and an audit pedigree we couldn’t have built ourselves. The follow-up explains what changed and why.

Last week I was scrolling through my news feed, half paying attention, half eating lunch, when a headline stopped me mid-bite. Something about nation-state actors stockpiling encrypted traffic for future quantum decryption. “Harvest now, decrypt later,” they called it.

I sat there, fork in hand, thinking: oh no.

The thing I already knew

The embarrassing part: I know about post-quantum cryptography. I’ve read the papers. I know what ML-KEM is. I know NIST finalized its post-quantum standards. I know the BSI, Germany’s federal cybersecurity authority, published TR-02102 with clear recommendations for hybrid key exchange. I’ve had conversations about this stuff.

And yet, when I built Voidcom’s encryption stack, I used X25519 for key exchange and called it a day. Good, solid, industry-standard elliptic curve cryptography. The same thing Signal uses. The same thing every serious messaging app uses.

Completely vulnerable to a sufficiently powerful quantum computer.

It’s not that I didn’t know better. I did. I just didn’t think about it at the right moment. I was heads-down building features: getting chat working, voice working, moderation working, permissions working. Crypto was “done” in my head. I’d picked strong algorithms, implemented them correctly, written the tests. Check the box, move on.

That’s the trap. You learn something, file it away, and when it actually matters it doesn’t surface, because your brain is busy with the immediate problem.

The moment it clicked

The article described how intelligence agencies are already collecting encrypted communications today, betting that quantum computers will break them within the next decade or two. The data they harvest doesn’t expire. Your messages from 2026 could be decrypted in 2036.

I thought about Voidcom users. People who trust us with their private conversations. People who chose Voidcom because we promised encryption that means something. If a quantum computer cracks X25519 ten years from now, every DM encrypted with our current key exchange could be exposed after the fact.

That’s not a theoretical risk. That’s a promise I’d be breaking.

What we did about it

I spent the weekend reading the BSI TR-02102-1 recommendations cover to cover and implementing hybrid post-quantum key exchange across the whole Voidcom stack. What changed:

Hybrid X25519 + ML-KEM-768 key exchange. Instead of relying on X25519 alone, every key exchange now combines classical elliptic curve Diffie-Hellman with ML-KEM-768, a lattice-based key encapsulation mechanism that resists quantum attacks. The hybrid part matters. If ML-KEM turns out to have an unforeseen weakness, X25519 is still there as a safety net. If quantum computers break X25519, ML-KEM protects you. Both have to fail for the system to be compromised.

Upgraded key derivation. We moved from SHA-256 to SHA-512 for HKDF, following BSI’s updated guidance on hash function security margins.

Quantum-resistant QUIC connections. Voice packets were already end-to-end encrypted with per-channel keys before they hit the wire; the server forwards opaque ciphertext it can’t decrypt. Now the QUIC transport layer that carries those packets is quantum-resistant too: it uses the X25519MLKEM768 key exchange group. Two layers of encryption, both protected against future quantum attacks.

Stronger certificate fingerprints. SHA-256 fingerprints for QUIC certificate verification have been upgraded to SHA-384, again following BSI recommendations.

This isn’t a half-measure or a marketing checkbox. It’s a ground-up upgrade to every cryptographic handshake in the system: DM key exchange, voice channel keys, QUIC transport, all of it.

The uncomfortable lesson

I’m not writing this to brag about our new cryptography. I’m writing it because I want to be honest about how this happened.

We’re five friends building this thing, three writing code and two testing, and the crypto sits with me. I read security papers. I care about getting it right. And I still missed something that, in hindsight, I should have implemented from day one. Not because I didn’t know about it. I did. I just didn’t connect the knowledge to the work at the right time.

That’s humbling, and I think it applies to anyone building software: knowing something isn’t the same as doing something about it. The gap between “I’ve read about this” and “I’ve actually implemented this” is where real-world vulnerabilities live.

The only fix is to keep reading, keep learning, and keep going back over the decisions you’ve already made. Security isn’t a feature you ship once. It’s a discipline you keep practicing.

What this means for the beta

The elephant in the room: this work pushes the beta launch back a bit. We were close, and adding post-quantum cryptography to every layer of the stack is not a small change. We need to test the new key exchange thoroughly, make sure performance holds, validate that the FFI layer works across platforms, and update the Flutter client to handle the new hybrid key format.

We’re now targeting May for the beta launch. I know that’s later than some of you were hoping, and I’m sorry for the delay. But I’d rather launch with cryptography that protects you against today’s threats and tomorrow’s than rush out the door with a known gap.

When you send a DM on Voidcom, I want that message to be unreadable by anyone except the person you sent it to. Not just today, but in ten years, twenty years, whenever quantum computers actually arrive. That’s the promise, and now we can keep it.

Keep learning, keep improving

If there’s one takeaway from this, it’s: never assume your work is done. Security changes. New research gets published. Standards get updated. What was best practice last year might have a known weakness today.

I’ll keep reading. I’ll keep auditing. And when I inevitably miss something again, because I will, everyone does, I’ll fix it and tell you about it. That’s the deal.

Thanks for your patience with the beta delay. It’ll be worth the wait.