build 2.4.5 · aes-256-gcm / ml-kem-768 · eu/de · ram only
POST-QUANTUM · SSH BOOTSTRAP

SSH key delivery, post-quantum.

OpenSSH 10.0 already encrypts your session with ML-KEM. Paramant encrypts the delivery of the key itself.

The problem

The gap.

OpenSSH has supported hybrid post-quantum key exchange since version 10.0, released April 2025. Every modern server, every recent macOS, every updated Linux distribution now negotiates SSH sessions using ML-KEM-768 combined with X25519. The session traffic is safe against harvest-now-decrypt-later attacks.

The initial keypair, however, still has to travel from one machine to another before the first SSH connection can happen. That delivery happens over email, Slack, a password manager, a shared drive, or a USB stick. Every one of those channels stores the key. Every one of those channels can be breached. The post-quantum SSH session is only as strong as the channel that delivered its key.

The fix

What Paramant adds.

ParaShare encrypts the key delivery with the same ML-KEM-768 hybrid KEM that OpenSSH uses for the session. The encrypted blob lives in RAM on the Paramant relay until the recipient picks it up, then is wiped. A signed receipt (ML-DSA-65, FIPS 204) proves cryptographically which key was delivered, to whom, and when.

The sender never stores the key in email, Slack, or a shared drive. The recipient never sees it in a channel that keeps logs. The relay itself cannot decrypt what it holds. After pickup, the key exists only in the two places it was always supposed to be: the sender's secure store, and the recipient's SSH agent.

Workflow

How it looks in practice.

01
Generate. Recipient runs ssh-keygen -t ed25519 on their new machine. Public key goes to sender.
02
Pack. Sender places the authorized_keys entry or keybundle into ParaShare. Relay encrypts with recipient's ML-KEM public key.
03
Deliver. Recipient receives a one-time link. Browser decrypts locally. Key lands in ~/.ssh/ directly.
04
Verify. ML-DSA-65 receipt proves the key arrived intact, from the expected sender, without modification.

No plaintext ever touches the relay. No intermediate channel keeps a copy.

Fit

Where this matters most.

Onboarding developers and operators. New team members need SSH access to staging, production, or customer servers. The current default (Slack or email) leaves the key in two logged channels forever. ParaShare leaves it in neither.

Bootstrapping OT and air-gapped devices. Industrial control systems, medical equipment, and isolated datacenters need initial configuration delivery through a channel that does not imply ongoing remote access. One-way, burn-on-read, signed delivery matches the operational model.

Rotating keys across a fleet. When a key is compromised or an operator leaves, the replacement has to reach every device. Paramant makes the rotation step auditable with per-device signed receipts, without broadcasting the new key through a channel that retains it.

Threat model

A different threat model than SSH itself.

SSH is designed for interactive sessions. Paramant is designed for one-shot file delivery. The two threat models overlap where people use SSH for file transfer it was never optimized for. The architectural difference is not about which protocol is stronger, but about which attack surface each one exposes.

Control plane and data plane.

SSH terminal emulators share a single channel for control messages and user data. The terminal PTY carries both the bytes the user types and escape sequences that reconfigure the terminal itself. This coupling is efficient but creates a class of vulnerability where seemingly passive output (a text file, a log, a login banner) can drive the terminal into unexpected states. The iTerm2 disclosure of April 2026, where DCS 2000p and OSC 135 sequences in a readme file could trigger local code execution, is one example of this class.

Paramant separates the two channels entirely. Protocol control (ML-KEM handshake, fingerprint verification, ML-DSA-65 signature validation) runs on one path. Encrypted payload delivery runs on another. Neither path interprets escape sequences, neither path executes helper scripts injected via user data, and neither path inherits trust from a long-lived session. A malicious payload sitting in Paramant's relay cannot reconfigure the client that picks it up, because the client does not parse the payload through any protocol-sensitive surface.

Control plane vs data plane: SSH vs Paramant Left side shows Classic SSH plus scp: a single PTY channel carries commands, file bytes, escape sequences, and conductor traffic between client and server. Right side shows Paramant: two separate narrow channels connect client to relay -- one cobalt channel for control (ML-KEM, ML-DSA, verify) and one lime channel for payload (ciphertext only). CLASSIC SSH + SCP Client PTY commands file bytes escape seq. conductor Remote server One channel. Mixed traffic. PARAMANT Client control ML-KEM ML-DSA verify payload ciphertext only Paramant relay Two channels. No shared surface.

What this means concretely.

When you scp a config file and cat it on your Mac. The file crosses an SSH channel, lands on disk, and gets read by your terminal. Every one of those steps carries the original bytes, including any escape sequences hidden in them. When you deliver the same file through ParaShare, the browser decrypts the payload outside the terminal's parsing surface. If you then cat the file in iTerm2, you have chosen to pipe it through the terminal, and the same risk applies as if you had downloaded it from anywhere else. Paramant does not remove that choice. It does remove the delivery channel as an attack vector.

When a MOTD on a transit server gets modified. SSH to a compromised jump host, the MOTD renders on your local terminal, attack surface is open. ParaShare has no equivalent pathway because there is no interactive session, no banner, no server-controlled text rendered in a privileged emulator. The relay holds a ciphertext blob. The blob cannot impersonate a conductor protocol because Paramant does not have a conductor protocol.

When you rotate a key across a fleet. SCP-based rotation pushes the key through each device's SSH session. Every one of those sessions is a live, trusted channel with a large attack surface. Paramant pushes a signed, encrypted artifact to each device's pickup endpoint. The artifact is verified against the sender's public key before it lands. Compromising the relay does not let an attacker substitute keys, because the signature would not verify against the expected sender.

Honest limits of this claim.

Paramant does not patch bugs in your terminal, your SSH client, your shell, or your operating system. It does not protect against malware that is already on the endpoint. It does not change the attack surface of an active SSH session you open in parallel. What it does is remove file delivery and key delivery from the list of workflows that share an attack surface with your interactive session. That is a real reduction in risk, but it is a specific reduction, not a total solution.

Honest scope

What Paramant is not.

Paramant is not an SSH replacement. It is not a jumphost, a bastion, or a tunnel. The SSH protocol has 25 years of hardening and, as of version 10.0, post-quantum key exchange by default. Paramant handles the step before SSH begins: delivering the key that makes the first connection possible. Once the key is in place, standard OpenSSH does the work it has always done.

Try ParaShare for key delivery.

Burn-on-read delivery. ML-KEM-768 encryption. ML-DSA-65 signed receipts. Free for individual use.

Create free account → Read the ParaShare docs →

OpenSSH 10.0 · ML-KEM-768 · RFC 9142