OpenSSH Post-Quantum Cryptography

Status of Quantum Computing and Motivation for PQC

  • The referenced “dog factoring RSA” paper is widely seen as satire targeting hype, not a serious argument against quantum computing or PQC.
  • Participants are split on timelines: some argue quantum computers have been “5–10 years away” for decades and may never scale; others point to clear theoretical and engineering progress (better factoring estimates, fault-tolerant codes).
  • Intelligence agencies’ guidance (e.g., protect against “store now, decrypt later” attacks by ~2030) is cited as a strong reason to start deploying PQC now for data that must remain secret for decades.
  • Skeptics stress that zero real-world progress has been made on actually breaking deployed crypto; proponents counter that low migration cost justifies hedging.

Overhead and Practicality in SSH and Other Protocols

  • OpenSSH’s PQC work is limited to key agreement (KEX), not bulk encryption, so overhead is per-connection, not per-packet.
  • Many commenters emphasize that asymmetric crypto has always been expensive relative to symmetric; PQ KEMs mainly affect the handshake.
  • ML‑KEM is said to be very fast, faster than classic DH at equivalent security and close to X25519; its public keys (~1 kB) are larger but “lost in the noise” for typical SSH sessions.
  • There is some concern that at very high connection rates (e.g., DNS, TLS with many short sessions) larger handshakes and signatures matter more, especially in TLS certificate chains.

Hybrid Schemes and Security Tradeoffs

  • OpenSSH uses hybrids (e.g., mlkem768x25519‑sha256) that combine a classical and a PQ algorithm, so security is at least as good as the classical part if PQ is later broken.
  • Hybrids improve robustness against algorithmic flaws but increase code surface, potentially raising implementation/side‑channel/DoS risk; others argue modern verified implementations mitigate this.
  • Some discussion explores whether “encrypting twice” can ever weaken security; consensus is that with independent keys and proper combiners, it should not.

Algorithm Choices and Ecosystem Direction

  • Question of “better” KEX: ML‑KEM‑based hybrids have better performance/smaller keys; NTRU Prime (sntrup) has different security assumptions and a strong pedigree.
  • NTRU Prime’s presence in SSH is partly historical; broader standards (TLS, IPsec, NIST PQC) are converging on ML‑KEM, suggesting it will be the dominant choice.
  • NSA’s CNSA 2.0 set is purely PQ without requiring hybrids, but hybrids remain allowed in practice and widely used during transition.