Post-quantum security for SSH access on GitHub¶
Summary¶
GitHub announced (effective 2025-09-17) the addition of
sntrup761x25519-sha512 / sntrup761x25519-sha512@openssh.com
as a new SSH key-exchange algorithm on github.com's SSH endpoints
for accessing Git data. The primitive is a hybrid post-quantum
KEM: Streamlined NTRU Prime (post-quantum-secure) combined with
classical Elliptic-Curve Diffie-Hellman on the X25519 curve. The
stated goal is protection against store-now-decrypt-later attacks
— an adversary recording encrypted SSH sessions today could decrypt
them later if a cryptanalytically-relevant quantum computer is ever
built. The rollout touches github.com and non-US-region GitHub
Enterprise Cloud (data-residency regions); the US region is
excluded because its FIPS-approved-cryptography-only constraint
does not currently include this PQ primitive. HTTPS is unaffected.
GitHub Enterprise Server 3.19 will ship the change. No client-side
configuration is needed — SSH's algorithm negotiation auto-selects
the new primitive on OpenSSH 9.0+ clients and falls back gracefully
on older clients.
Key takeaways¶
-
Store-now-decrypt-later is the motivating threat model. "We don't know if it will ever be possible to produce a quantum computer powerful enough to break traditional key exchange algorithms. Nevertheless, an attacker could save encrypted sessions now and, if a suitable quantum computer is built in the future, decrypt them later." Symmetric-session recordings today have a long-tail decryption risk — this is a classic concepts/telemetry-ttl-one-way-door-class irreversibility, but applied to wire-captured ciphertext rather than emitted telemetry. (Source: sources/2025-09-15-github-post-quantum-security-for-ssh-access-on-github)
-
Hybrid construction = "no weaker than classical" guarantee.
sntrup761x25519-sha512combines Streamlined NTRU Prime (a PQ-secure KEM, less battle-tested) with X25519 ECDH (classical, heavily battle-tested). The session key is derived from both exchanges concatenated and hashed with SHA-512. The critical property: even if Streamlined NTRU Prime is later found broken, the hybrid is at least as strong as the classical half. This is the concepts/hybrid-key-encapsulation pattern. (Source: sources/2025-09-15-github-post-quantum-security-for-ssh-access-on-github) -
Only SSH, not HTTPS. "This only affects SSH access and doesn't impact HTTPS access at all." HTTPS to github.com goes through a different TLS stack (CDN/edge-terminated) with its own PQ-rollout cadence; SSH-to-Git is a direct connection to GitHub's Git endpoints. Different transport stacks → independent crypto- agility timelines. (Source: sources/2025-09-15-github-post-quantum-security-for-ssh-access-on-github)
-
FIPS carve-out for US-region GHEC (data residency). "Only FIPS-approved cryptography may be used within the US region, and this post-quantum algorithm isn't approved by FIPS." The US-region GHEC operates under a stricter cryptographic-module policy than the rest of the fleet. A single product thus has different cryptographic surface depending on deployment region — a concepts/fips-cryptographic-boundary distinct from data residency (same data, different allowed primitives). Tracks the pattern from concepts/digital-sovereignty — regulatory-driven partition-like surfaces. (Source: sources/2025-09-15-github-post-quantum-security-for-ssh-access-on-github)
-
SSH algorithm negotiation is the non-breaking-rollout mechanism. "The SSH protocol automatically picks an algorithm that both sides support." Clients advertise supported KEX algorithms; server advertises supported KEX algorithms; the intersection picks the highest-preference shared one. GitHub adds
sntrup761x25519-sha512to the server's supported list; OpenSSH 9.0+ already has it in the client list with higher preference than classical alternatives → auto-selected. Older clients not supporting it fall back to classical ECDH-X25519 or similar — no connection break, just no PQ benefit. This is patterns/protocol-algorithm-negotiation — the reusable shape for rolling out new cryptographic primitives into a deployed ecosystem without a flag day. (Source: sources/2025-09-15-github-post-quantum-security-for-ssh-access-on-github) -
OpenSSH 9.0 (2022-04) is the capability threshold. OpenSSH 9.0 made
sntrup761x25519-sha512@openssh.comthe default KEX; earlier versions either don't support it or don't prefer it. The client-side rollout is thus effectively gated by Linux-distro / macOS / Git-for- Windows OpenSSH version. Users test viassh -Q kex(list supported KEX) orssh -v git@github.com exit 2>&1 | grep 'kex: algorithm:'(observe negotiated KEX on a real connection). (Source: sources/2025-09-15-github-post-quantum-security-for-ssh-access-on-github)
Systems, concepts, patterns extracted¶
Systems
- systems/openssh — the SSH implementation on both client and
server sides of github.com SSH connections; 9.0+ is the PQ-capable
version; @openssh.com algorithm-name suffix is the OpenSSH vendor
namespace convention (later dropped when promoted to standard name).
- systems/github — the SaaS that runs the SSH endpoint serving
Git-over-SSH; US-region GHEC has the FIPS carve-out.
- systems/git — the underlying protocol whose transport is being
secured (Git-over-SSH specifically).
Concepts - concepts/post-quantum-cryptography — cryptographic primitives designed to resist cryptanalytic attack by quantum computers; motivated by the store-now-decrypt-later threat model; Streamlined NTRU Prime and ML-KEM (NIST standard, formerly Kyber) are the canonical KEM instances. - concepts/hybrid-key-encapsulation — combining a PQ-secure KEM with a classical one so the composite is at least as strong as the stronger of the two; hedge against under-matured PQ primitives. - concepts/fips-cryptographic-boundary — the deployment-topology surface defined by which regions / environments require FIPS-140-validated cryptographic modules; distinct from data residency though often co-located; limits which primitives can be rolled out in which regions.
Patterns - patterns/protocol-algorithm-negotiation — the protocol-design pattern where both sides advertise a list of supported algorithms and the mutual intersection picks the one used; enables non-breaking rollout of new primitives into an installed base. SSH KEX / TLS cipher-suites / HTTP content-negotiation / codec negotiation in WebRTC are all instances.
Operational numbers¶
Explicitly disclosed in the post: - Effective date: 2025-09-17 for github.com + non-US-region GHEC. - GHES 3.19: ships the new algorithm. - OpenSSH client floor: 9.0 (released 2022-04-08). - Not disclosed: traffic volume over SSH, share of SSH-vs-HTTPS for Git, per-handshake CPU cost of the hybrid vs classical KEX (NTRU Prime + X25519 are both cheap, but bytes-on-the-wire for the KEM are measurably larger than classical), US-region GHEC proportion of total fleet.
Caveats / open items¶
- No internals on the SSH-endpoint fleet. The post doesn't disclose: SSH-endpoint topology (load balancer termination? direct connection?), how many regions/PoPs, how SSH-host-key trust is managed, connection-age distribution, how the server builds its KEX-algorithm-preference list, whether the addition is atomic across the fleet or staged.
- FIPS-compliant PQ primitives are coming. "As the SSH libraries we use begin to support additional post-quantum algorithms, including ones that comply with FIPS, we'll update you on our offerings." NIST's ML-KEM (FIPS 203) was finalised 2024-08-13 — once OpenSSH (or whatever SSH library GitHub uses) ships ML-KEM-backed hybrid KEX, the US-region carve- out can close. GitHub isn't naming a date.
- Hybrid does not erase PQ-primitive risk for other failure modes. The hybrid property is about the shared secret; the post-quantum component still consumes CPU, bandwidth, and memory per handshake, and a flaw in its code (parsing, side-channel) can still manifest. "Newer and thus have received less testing" is the post's own framing.
- HTTPS gap. Users who want PQ protection for Git-over-HTTPS have to wait for a separate, presumably CDN-layer rollout. The post doesn't hint at timing or stack.
- No quantitative attacker model. "We don't know if it will ever be possible to produce a quantum computer powerful enough" — PQ deployment is a hedge; the cost is real today, the benefit accrues only in the contingent future.
Related sources¶
- None ingested yet on PQ cryptography specifically; this is the first PQ-deployment source in the wiki.
- sources/2026-04-07-cloudflare-targets-2029-for-full-post-quantum-security
— signature-side / authentication-side counterpart to this
KEM-side rollout. Cloudflare's 2026 roadmap articulates why the
algorithm-negotiation-based enablement pattern this GitHub post
canonicalises is sufficient for PQ encryption (HNDL mitigation,
65% of Cloudflare traffic today) but not sufficient for PQ authentication — disabling classical + rotating secrets are required on top. Together the two sources bracket the full 2-axis PQ threat model (confidentiality + authentication).
- sources/2025-03-15-github-sign-in-as-anyone-bypassing-saml-sso-authentication-with-parser-differentials — different class of cryptographic-boundary failure (parser differential in SAML signature verification), but same author mindset (GitHub Security/Platform-Security posts treat crypto rollout as a first-class engineering topic).
- sources/2026-01-30-aws-sovereign-failover-design-digital-sovereignty — concepts/digital-sovereignty and regional carve-outs; the FIPS-boundary here is a narrower sibling of the partition boundary there.
Raw¶
- Raw file:
raw/github/2025-09-15-post-quantum-security-for-ssh-access-on-github-6f9c5349.md - Original URL: https://github.blog/engineering/platform-security/post-quantum-security-for-ssh-access-on-github/
- Authors: brian m. carlson (Git Systems engineer, Git contributor), Taylor Blau (Principal Software Engineer, works on Git)