Harvest now, decrypt later: a post-quantum threat model for network engineers

1.1 Harvest now, decrypt later

NIST describes the threat directly: adversaries collect encrypted data now in order to decrypt it once quantum technology matures, and because sensitive data keeps its value for years, this is one of the main reasons the transition to post-quantum cryptography is urgent [1]. The attack is passive today, so copying traffic from a link or a mirrored port leaves no trace on either endpoint, and its cost is paid later, against a recording that no longer changes. Protection must therefore last as long as a session's contents are worth reading.

This paper applies the threat to a network engineer's daily traffic, administrative SSH, often through bastion hosts, and uses GHOSTSHELL 0.2.0, a terminal and session manager for Windows, to show what a client can and cannot change. Companion papers cover the SSH key exchange and the vault.

1.2 What a quantum computer breaks

Shor's algorithm factors integers and computes discrete logarithms in polynomial time on a large enough quantum computer [2]. That breaks RSA and Diffie–Hellman, and the approach extends to the elliptic curves behind X25519, P-256, P-384, ECDSA and Ed25519. NIST lists these families as quantum-vulnerable, to be deprecated after 2030 and disallowed after 2035 [1]. Grover's algorithm gives only a square-root speed-up for search [3], so a 256-bit symmetric key keeps roughly 128 bits of strength, and NIST's highest post-quantum security category is defined by key search on a 256-bit block cipher [1]. The 256-bit ciphers that carry an SSH session's data are not the weak link. The key exchange that produced their keys is.

1.3 How close such a machine is

No cryptanalytically relevant quantum computer exists [1], and no source cited here dates one, but the estimated cost has fallen. Gidney and Ekerå estimated that factoring RSA-2048 takes about 20 million noisy qubits [4]; six years after that estimate first appeared as a preprint, Gidney put it under one million under the same hardware assumptions [5]. Both are estimates for RSA; the elliptic curves GHOSTSHELL pairs with post-quantum algorithms have separate estimates, not covered here. Table 1 shows how fast the estimates move, not a date.

1.4 Why the date does not settle the question

NIST restates Mosca's theorem as a planning rule [1]: with X the years data must stay secret and Y the years needed to migrate, migration must start before X + Y exceeds Z, the time until such a computer exists (Figure 1). For management traffic, X is the useful life of what a session carries: a typed device password until it is changed, a configuration's keys and community strings for as long as the network keeps them. Y is long, because the SSH server on a router changes only with its firmware, and NIST notes that past migrations have taken more than a decade [1]. Z is unknown, and it does not have to be near for X + Y to exceed it.

2.1 What a recording of an SSH session holds

An SSH connection starts in the clear: version strings, then KEXINIT messages listing each side's algorithms, then the key exchange [6]. Everything after it, user authentication included, is encrypted with keys derived from the exchange's shared secret K [6]. Passwords typed at a login, enable or sudo prompt, commands, output, SFTP files and forwarded ports all travel under those keys.

A recording holds everything except K. With a classical exchange such as curve25519-sha256, both ephemeral public values are in the recording, and K follows from them by a discrete logarithm, which Shor's algorithm computes [2]. Forward secrecy does not help: the attacker needs no stored key, only the transcript. With K, the session keys follow by the protocol's own derivation [6], and every later rekey is another exchange in the same recording.

2.2 Signatures are a different problem

Host-key and user signatures prove identity during the handshake. Breaking them later decrypts nothing recorded: NIST notes that signatures are not vulnerable to harvest-now-decrypt-later attacks and lets authentication migrate on its own timeline [1]. They matter only to an attacker who can forge them during the connection, which takes a quantum computer at that moment.

2.3 Hybrid key exchange

A hybrid key exchange runs a classical exchange and a post-quantum key-encapsulation mechanism (KEM) together and derives the session secret from both, so it stays secret while either half holds. Bindel et al. gave this a formal footing, including attackers whose quantum capability arrives later [7], and NIST describes hybrids the same way [1]. SSH has four published hybrids: mlkem768x25519-sha256, mlkem768nistp256-sha256 and mlkem1024nistp384-sha384 (RFC 10042 [8]), pairing ML-KEM (FIPS 203 [9]) with X25519, P-256 or P-384, and sntrup761x25519-sha512 (RFC 9941 [10]), pairing Streamlined NTRU Prime with X25519. Each hashes the two secrets together, K = HASH(K_PQ ‖ K_CL). The cost is size: the client's first value for mlkem768x25519-sha256 is 1,216 bytes, where curve25519-sha256 sends 32.

2.4 Why keep a classical half

Post-quantum algorithms are young. SIKE, in the fourth round of NIST's process, fell to a classical attack that breaks its smallest parameter set in about ten minutes on one core [11]. Rainbow, a finalist signature scheme, lost a key at its lowest security level in about 53 hours on a laptop [12]. Kyber implementations, the reference code among them, leaked keys through secret-dependent division timings [13]. A hybrid whose young half fails must still be broken classically, which no one can do today; NIST gives the same reason for hybrids [1].

3.1 The adversary

The adversary records traffic on any path between the workstation and the equipment, such as an access network, a transit provider or a mirrored port, stores it, and at some unknown time Z gains a quantum computer that runs Shor's algorithm at the size needed. It may also copy files: a backup, a synced folder, a lost laptop's disk. Malware on the workstation defeats any transport protection and is out of scope, as is an active quantum attacker at connection time (section 3.3).

3.2 What a network engineer exposes

Table 2 lists what an engineer's sessions and files hold and what a later decryption would reveal. The first five rows depend on the key exchange, the next three on encryption at rest, and the last on protocols whose encryption, if any, is not GHOSTSHELL's.

3.3 What a hybrid defends, and what it does not

A hybrid key exchange defends the confidentiality of a recorded session against a later break of one of its halves: the first five rows of Table 2, on every hop whose server supports a post-quantum method. It does not:

• protect a connection to a server without a post-quantum method;
• change authentication, so classical host keys stay open to an active quantum attacker at connection time;
• add encryption to Telnet, to VNC as GHOSTSHELL implements it, or to a serial line;
• reach connections other programs make: Windows' Remote Desktop client, a proxy command, WinSCP;
• hide metadata: who connected where, when, and how much data moved;
• protect files at rest, which need their own encryption (section 4.4).

4.1 SSH key exchange

By default, GHOSTSHELL 0.2.0 offers four post-quantum hybrids, under five names, ahead of every classical method on every SSH connection: mlkem768x25519-sha256, mlkem1024nistp384-sha384, mlkem768nistp256-sha256, sntrup761x25519-sha512 and its older name sntrup761x25519-sha512@openssh.com, which together are every post-quantum SSH key exchange published as an RFC [8] [10]. The server runs the first method in the client's list that it supports [6], so any server sharing one gets a post-quantum exchange; OpenSSH made sntrup761x25519-sha512@openssh.com its default in 9.0 and mlkem768x25519-sha256 its default in 10.0 [14].

The default policy, Quantum-safe preferred, keeps classical methods after these for older equipment; Quantum-safe only refuses a server without one. After the handshake, before any password prompt, the terminal names the key exchange and host key the server chose, with a warning when the exchange is classical, and the tab's toolbar shows the same state. The quantum-safe policies offer only 256-bit ciphers. Post-quantum by default gives the details.

4.2 Jump chains, shared connections and proxy commands

Each connection in a jump chain is a separate recording target (Figure 2). The outer connection to the bastion carries the bastion login and a channel naming the device; the inner connection runs end to end through that channel and carries the device session. GHOSTSHELL gives the outer connection at least the inner one's policy, recursively along a chain, and names the profile that set it. Tabs share an open connection only when address, user, proxy, policy and algorithm lists all match, so a stricter profile never inherits a weaker connection, and Connection security… lists what every hop negotiated.

A proxy command hands the outer hop to another program, outside the policy. When that program is Windows' built-in ssh.exe, there is nothing post-quantum to choose: on the development machine, ssh -Q kex for OpenSSH_for_Windows_9.5p2 lists twelve methods, none of them post-quantum. GHOSTSHELL says so in the terminal, the profile settings and Connection security…, and suggests a jump host, which keeps the policy on every hop. WinSCP, which makes its own connection, gets the same notice.

4.3 HTTPS

TLS that GHOSTSHELL makes through Node, for plugin installs and plugins' own requests, offers every post-quantum group its TLS library accepts first. Electron 43.7.0's BoringSSL accepts X25519MLKEM768 and MLKEM1024 but not the NIST-curve hybrids of RFC 10024 [15], so the default offer is X25519MLKEM768:MLKEM1024:X25519:P-256:P-384:P-521. Chromium's own network stack keeps Chromium's defaults, which offer X25519MLKEM768 first.

4.4 Stored secrets and vault files

Files on disk can be attacked at leisure, so the vault avoids public-key cryptography where it can. The everyday path, Argon2id and AES-256-GCM, is symmetric: it leaves nothing for Shor's algorithm, and a 256-bit key keeps about 128 bits against Grover's [3]. Only what must open without the passphrase or for someone else, namely the recovery and escrow slots and shared bundles, uses public keys: ML-KEM-1024 with P-384 to encrypt, and ML-DSA-87 with P-384 to sign the bundles, as Sealed twice describes. Encryption of command history and session logs is off by default; without it they are plain text.

4.5 Releases

A release is not a recording target, but its signature must hold as long as the release is trusted. From 0.2.0, releases carry an SSHSIG signature from a hybrid ML-DSA-44 + Ed25519 key, SHA256:wcsMR20+ZSY6dRrHBgco/FFH9pOnyjqRh8A5u2s+C0M, built as the IETF composite-signature draft describes [16] on FIPS 204's ML-DSA [17]; it counts only when both halves verify. The Download page checks it in the browser, as does ssh-keygen from OpenSSH 10.4 or 10.5. OpenSSH 10.6 renamed the key type [14] and its ssh-keygen will not check these signatures, so a new key will follow once a 10.6 build is available. The installer is not Authenticode-signed, and the app's updater checks no signature.

4.6 Where the protection stops

RDP sessions run in Windows' own Remote Desktop client, whose hybrid TLS groups are off by default, so they are protected classically. The VNC viewer (RFB 3.3, 3.7 and 3.8, without VeNCrypt or TLS), Telnet and raw sockets are unencrypted, and labeled or warned as such; recording them needs no quantum computer. A serial console has no cryptography and no network path. A server with no post-quantum method gets a classical exchange with a warning, or a refusal under Quantum-safe only: the server decides. Table 3 sums up the mapping.