DEV Community

Eric-Octavian
Eric-Octavian

Posted on

I wrote a Post-Quantum SSH server in Rust — from scratch, in the kernel

#networking #rust #security #showdev

No OpenSSH. No OpenSSL. Just Rust and a kernel.

I've been building IONA OS — a sovereign operating system written entirely in Rust — for the past 13 years.

Last week, I finished one of the most complex components I've ever written: a full SSH server and VPN stack, both with post-quantum cryptography, running inside the kernel itself.

No external libraries. No OpenSSH. No OpenSSL. Just Rust, bare metal, and a lot of math.

Here's how I did it.

Why post‑quantum?

Quantum computers are coming. When they arrive, they will break RSA and ECC — the cryptographic foundations of almost everything on the internet.

The US government has set a deadline: by 2035, all federal systems must be post‑quantum ready.

I didn't want to wait. I wanted IONA OS to be post‑quantum from day one.

So I implemented Dilithium (ML-DSA) — a lattice‑based signature scheme standardised by NIST — from scratch, in Rust, in the kernel.

What "from scratch in the kernel" actually means

Most people use libraries:

  • OpenSSH for SSH
  • OpenVPN for VPN
  • OpenSSL for crypto
  • pqcrypto-dilithium for post‑quantum

I used none of them.

Everything was written from zero, in Rust, with no std, no heap allocator (in the critical paths), and no external dependencies.

This means:

  • No libc
  • No rand crate
  • No sha2 crate
  • No x25519-dalek
  • No curve25519-dalek
  • No pqcrypto-dilithium

Every bit of crypto — every NTT transform, every modular reduction, every Keccak round — was written by me.

What I built

1. Post‑Quantum SSH Server

A full SSH server running inside the kernel, listening on port 2222.

Implemented correctly:

  • mpint encoding — big integer serialisation
  • ChaCha20‑Poly1305 AEAD — with round‑trip encryption and tamper rejection
  • KEX (Key Exchange) — using Curve25519 + Dilithium
  • Host‑key signature — signed with Dilithium
  • KDF — key derivation for session keys

2. Post‑Quantum VPN

A VPN protocol running alongside SSH, with:

  • Control framing
  • Mutual signatures — both sides authenticate with Dilithium
  • Data‑channel AEAD — ChaCha20‑Poly1305 for packet encryption
  • Tamper rejection — modified packets are dropped

3. Post‑Quantum Crypto

  • Dilithium (ML-DSA) — for signatures
  • Kyber (ML-KEM) — for key encapsulation (planned/partial)
  • ChaCha20‑Poly1305 — for symmetric encryption
  • Curve25519 — for elliptic curve Diffie‑Hellman
  • SHA‑256 / SHA‑384 — for hashing

All written from zero.

The boot log that proves it works

Here's what happens when IONA OS boots:

[SSH] self-test passed: mpint encoding, cipher round-trip + tamper rejection, KEX agreement, host-key signature, KDF
[VPN] self-test passed: control framing, KEX agreement, mutual signatures, key derivation, data-channel AEAD + tamper rejection
[SEC] PQ crypto: ... SSH=OK OpenVPN=OK RSA=OK
[SCHED] spawn 'ssh-accept-loop' tid=16 ...
[BOOT-SEQ] ssh-server OK 2272ms

What this means:

  • self-test passed — every cryptographic component was verified at boot
  • tamper rejection — modified packets are detected and dropped
  • KEX agreement — the key exchange works correctly
  • mutual signatures — both sides authenticate using Dilithium
  • PQ crypto: SSH=OK OpenVPN=OK — post‑quantum crypto is active
  • 2272ms — the entire stack initialises in just 2.27 seconds

The hardest part: Dilithium from scratch

Dilithium is a lattice‑based signature scheme.

It's not just "hard" — it's one of the most complex cryptographic algorithms ever standardised.

What makes it hard:

  • NTT (Number Theoretic Transforms) — you need fast polynomial multiplication
  • Fiat‑Shamir with Aborts — the signing algorithm can fail and retry
  • Modular arithmetic — strict, no overflow, no timing leaks
  • Side‑channel resistance — the code must run in constant time
  • Memory constraints — no heap, no Vec, no Box

Writing it in Rust, in no_std, in the kernel, without any external help, took months.

But it works.

Why this matters

Most operating systems depend on:

  • OpenSSH for remote access
  • OpenVPN / WireGuard for VPN
  • OpenSSL / LibreSSL for crypto

IONA OS has none of these dependencies.

It is completely sovereign.

If you want to connect to an IONA OS machine, you use its native SSH server — with post‑quantum security, running directly in the kernel.

No Linux. No userspace. No OpenSSL.

What's next

This is not the end. It's the foundation.

  • Mesh networking — combine VPN with peer discovery to build a fully encrypted mesh between IONA OS devices
  • Zero‑trust authentication — mutual signatures make every connection verifiable
  • Post‑quantum TLS — same stack, used for HTTPS

But that's for another article.

The code

You can find the full source code (including Dilithium, SSH, and VPN) in the IONA OS repository:

github.com/Ionablokchain/Iona-OS

The project is not yet production‑ready — but the foundation is solid.

Final thoughts

When I started building IONA OS, people told me:

"You can't build an OS alone."

"You can't write your own crypto."

"You can't implement Dilithium from scratch."

I did all three.

This SSH server is proof that one person can build sovereign infrastructure — if they have the patience, the discipline, and the belief that it's possible.

IONA OS launches on September 15, 2026.

Website: iona.zone

GitHub: github.com/Ionablokchain

13 years of research. Every line written from scratch. And it works.

Top comments (0)