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.

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

The thing I already knew

Here’s the embarrassing part: I know about post-quantum cryptography. I’ve read the papers. I know what ML-KEM is. I know NIST finalized their 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, focused on getting the chat working, the voice working, the moderation working, the 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, isn’t it? You learn something, you file it away, and then when it actually matters, it doesn’t surface. Your brain is busy with the immediate problem.

The moment it clicked

The article talked about how intelligence agencies are already collecting encrypted communications today, banking on quantum computers being able to break them within the next decade or two. The data they’re harvesting doesn’t expire. Your messages from 2026 could be decrypted in 2036.

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

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 entire Voidcom stack. Here’s what changed:

Hybrid X25519 + ML-KEM-768 key exchange. Instead of relying solely on X25519, every key exchange now combines classical elliptic curve Diffie-Hellman with ML-KEM-768 — a lattice-based key encapsulation mechanism that’s resistant to quantum attacks. The “hybrid” part is important: even if ML-KEM turns out to have an unforeseen weakness, X25519 is still there as a safety net. And 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 are already end-to-end encrypted with per-channel keys before they ever hit the wire — the server forwards opaque ciphertext it can’t decrypt. But the QUIC transport layer that carries those packets is now also quantum-resistant: we’ve configured it to use 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, the lot.

The uncomfortable lesson

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

I’m one person building this thing. I read security papers. I care deeply about getting the crypto right. And I still missed something that, in hindsight, I should have implemented from day one. Not because I didn’t know about it — because I did. I just didn’t connect the knowledge to the work at the right time.

That’s a humbling realization. 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 to revisit the decisions you’ve already made. Security isn’t a feature you ship once. It’s a discipline you practice continuously.

What this means for the beta

Let’s address the elephant in the room: this work is going to push 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 thoroughly test the new key exchange, make sure performance is solid, validate that the FFI layer works correctly 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 both 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 actually keep it.

Keep learning, keep improving

If there’s one takeaway from this whole experience, it’s this: never assume your work is done. The security landscape 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.

— Max