Abstract

Falcon, the NIST-selected lattice-based signature scheme standardized as FIPS 206 (ML-DSA) in 2024, is now making its way into SSH implementations as operators begin hardening host authentication against quantum adversaries. Unlike ECDSA or Ed25519, Falcon’s security rests on the hardness of the NTRU lattice problem, making it resistant to Shor’s algorithm. This article examines the practical steps and tradeoffs involved in enabling Falcon-based host keys in OpenSSH, with attention to signature size, key generation time, and interoperability with older clients.

Why SSH Host Authentication Is a Priority

Most post-quantum SSH discussions focus on key exchange, where hybrid KEMs like mlkem768x25519 have shipped in OpenSSH 9.0+. Host authentication is the quieter vulnerability. A quantum adversary who records today’s handshakes can later forge host signatures offline if the authentication algorithm is ECDSA or RSA. The “harvest now, decrypt later” threat is well understood for confidentiality, but the analogous “harvest now, forge later” scenario for host keys is less discussed. For long-lived server identities, rotating host key algorithms now closes this window.

Falcon vs. Dilithium for SSH

NIST finalized two primary signature schemes: ML-DSA (based on Dilithium) and SLH-DSA (SPHINCS+), with Falcon (ML-DSA’s lattice cousin using NTRU) specified separately as a compact-signature option. For SSH, signature size matters less than in TLS because only a few handshake messages are signed, but key generation time is relevant for ephemeral host provisioning. Falcon-512 produces 666-byte signatures; Dilithium2 produces 2420-byte signatures. Both fit comfortably in an SSH_MSG_USERAUTH_REQUEST packet. Falcon’s key generation is slower and less constant-time than Dilithium’s, which is a concern on shared infrastructure where timing side-channels are a risk. The libpqcrypto and liboqs libraries from the Open Quantum Safe project both implement Falcon with mitigations, but operators should audit their deployment platform before choosing it over Dilithium.

Enabling Falcon Host Keys in Practice

The Open Quantum Safe fork of OpenSSH (openssh-oqs) supports falcon512 and falcon1024 host key types via the HostKey directive. Generating a host key follows the standard pattern:

ssh-keygen -t falcon512 -f /etc/ssh/ssh_host_falcon512_key

The sshd_config entry HostKeyAlgorithms falcon512-sha512 instructs the daemon to advertise the algorithm. Clients must also run the OQS fork to complete the handshake; stock OpenSSH 9.7 does not yet include post-quantum signature algorithms in the mainline release as of mid-2025. This means operators should maintain both classic and Falcon host keys during the transition window, using HostKeyAlgorithms to prefer the new key when both parties support it.

Operational Considerations

Certificate authorities issuing OpenSSH host certificates will need to upgrade their CA signing keys as well. An ECDSA-signed certificate over a Falcon host key provides no post-quantum benefit for authentication, since an adversary can forge the CA signature. Organizations using Teleport, Smallstep, or Vault’s SSH secrets engine should verify that their CA backend can issue Falcon-signed certificates before rolling out new host keys fleet-wide. Monitoring key rotation across large fleets via inventory tools like Ansible or Salt remains the same operationally, but the larger key material sizes should be accounted for in certificate distribution bandwidth estimates.

Outlook

Mainline OpenSSH inclusion of post-quantum signature algorithms is expected in late 2025 or 2026, following the stabilization of FIPS 206 tooling in distributions. Early adopters using the OQS fork gain the operational experience needed to prepare rollout runbooks now, reducing the scramble when algorithm support becomes a compliance requirement.