GitHub has introduced a hybrid post-quantum key exchange algorithm for SSH access, in order to better protect Git data in transit. The new algorithm is named sntrup761x25519-sha512 (also known under the OpenSSH namespace as sntrup761x25519-sha512@openssh.com) and merges a post-quantum component (Streamlined NTRU Prime) with the classical X25519 elliptic-curve exchange.
This change applies specifically to SSH access when interacting with Git over SSH; HTTPS transports are not affected. GitHub began rolling it out on September 17, 2025 for GitHub.com and for non-US GitHub Enterprise Cloud regions. The U.S. region is deferred, because stricter FIPS cryptographic requirements apply there and the new algorithm is not yet FIPS-approved. Support will also be added to GitHub Enterprise Server 3.19.
Why this matters
The shift toward a hybrid post-quantum key exchange is motivated by the “store now, decrypt later” threat: an adversary might record SSH traffic today, then wait until sufficiently powerful quantum computers exist to break classical key exchanges. By combining classical and post-quantum methods, GitHub aims to ensure that the negotiated shared secret is at least as secure as the classical algorithm alone, while gaining quantum resistance.
From an engineering perspective, the core SSH protocol flow remains the same, and clients and servers negotiate which key exchange they share. If both ends support the new hybrid algorithm, it will generally be preferred by default (unless overridden). SSH clients lacking support will fall back to classical key exchanges, preserving compatibility.
If you rely on SSH for Git operations, your main task is to confirm whether your SSH client supports the new algorithm. Modern versions of OpenSSH (from 9.0 onward) include support for sntrup761x25519-sha512.
You can use:
ssh -Q kexto list supported key exchange algorithms, and check whether sntrup761x25519-sha512 or sntrup761x25519-sha512@openssh.com is present.
You can also see which algorithm an SSH connection actually used by running:
ssh -v git@github.com exit 2>&1 | grep 'kex: algorithm:'If your client already supports it, it should negotiate automatically without requiring configuration changes. If you’ve modified default SSH settings (for example in ~/.ssh/config), ensure those overrides do not disable or deprioritize the new algorithm. If your client does not support it, your connection will continue under a classical algorithm until you upgrade.
For SSH server or comparable infrastructure contexts (e.g. CI runners, bastion hosts, self-hosted Git mirrors), you may want to verify whether your SSH implementation supports hybrid PQ key exchanges, and plan for upgrades if not.
What to watch next
GitHub has stated that it will monitor developments in post-quantum cryptography and intends to support additional quantum-secure key exchange methods, particularly once algorithms achieve FIPS compliance.
OpenSSH itself is already evolving: since version 9.9, it includes support for another hybrid method, mlkem768x25519-sha256, and in version 10.0 that has become the default key exchange scheme. This broader movement in the SSH ecosystem reflects a gradual transition toward post-quantum readiness.
In parallel, experimentation in open-source forks and research projects (such as OQS-OpenSSH) is ongoing. Tools like pqcscan allow scanning of SSH or TLS servers to detect whether they advertise PQC support.
As the standards and implementations mature, further adoption of hybrid and pure-post-quantum algorithms should become seamless to users, reducing the window of exposure before quantum-resistant cryptography becomes the norm.
