GitHub Strengthens SSH Security with Post-Quantum Key Exchange: What You Need to Know

GitHub is taking a proactive step to protect your Git data from future quantum threats. Starting September 17, 2025, it will enable a new hybrid post-quantum secure SSH key exchange algorithm on its services. This change ensures that even if attackers record encrypted sessions today, they cannot decrypt them later using powerful quantum computers. Below, we answer common questions about this update, how it works, and what you need to do to prepare.

What exactly is changing with SSH access on GitHub?

GitHub is adding a new post-quantum secure SSH key exchange algorithm called sntrup761x25519-sha512 (also known as sntrup761x25519-sha512@openssh.com) to its SSH endpoints used for accessing Git data. This algorithm will be available alongside existing options and, for clients that support it (like OpenSSH 9.0 or newer), it will be automatically preferred during the SSH handshake. The change only affects SSH-based Git operations; HTTPS access remains completely unaffected. If you use GitHub Enterprise Cloud with data residency in the United States, this algorithm won’t be enabled because FIPS-approved cryptography is required in that region and this algorithm hasn’t received FIPS approval.

Why is GitHub adopting a post-quantum algorithm now?

Traditional SSH key exchange algorithms are secure against today’s computers, but they are vulnerable to what’s known as a “store now, decrypt later” attack. An adversary could record your encrypted SSH sessions today and, if a sufficiently powerful quantum computer is ever built, decrypt them years later. By adding a post-quantum-secure algorithm now, GitHub ensures that your Git data remains protected long into the future, even as quantum computing capabilities evolve. The algorithm used—sntrup761x25519-sha512—is a hybrid that combines a post-quantum component (Streamlined NTRU Prime) with the classical Elliptic Curve Diffie-Hellman (ECDH) over Curve25519 (X25519). This hybrid approach means that even if future quantum attacks break the NTRU component, the classical ECDH layer still provides the same level of security as today’s best algorithms.

When will these changes take effect?

The new post-quantum key exchange algorithm will be enabled on September 17, 2025 for GitHub.com and for GitHub Enterprise Cloud customers with data residency, except those in the United States region (where it is not approved). Additionally, the algorithm will be included in GitHub Enterprise Server 3.19, which is scheduled for release around the same time. Starting from that date, any SSH connection to GitHub that uses a compatible client will automatically negotiate this stronger algorithm. No action is required on your part unless you need to update your SSH client to support it (e.g., using OpenSSH 9.0 or newer).

Who is affected by this change?

This change only affects users who access Git data over SSH. If your Git remotes start with https://, your workflow remains entirely unchanged. For SSH users, the impact is minimal: clients that support the new algorithm (like OpenSSH 9.0+) will automatically use it by default. Older clients will continue to use the existing, still-secure classical algorithms. The change does not affect GitHub Enterprise Cloud with United States data residency, where FIPS-approved cryptographic algorithms are mandatory. For all other GitHub.com users and non-US GitHub Enterprise Cloud customers, the new algorithm will be available and preferred.

How can I prepare for this update?

For most users, no preparation is needed. The algorithm is automatically used when your SSH client supports it. To ensure you benefit from the enhanced security, verify your SSH client version: check OpenSSH version. If you use OpenSSH 9.0 or later, you’re all set. If you use an older version, consider upgrading to the latest OpenSSH release. You can also test by connecting to GitHub with verbose logging: ssh -vT git@github.com and look for messages about sntrup761x25519-sha512. If you manage server-side configurations, you may need to update FIPS-related settings if you’re in a regulated environment, but for most personal or enterprise use, the change is transparent.

Why isn’t this algorithm enabled in the United States region for GitHub Enterprise Cloud?

The United States region of GitHub Enterprise Cloud with data residency is required to use only FIPS-approved cryptographic algorithms (Federal Information Processing Standards). The post-quantum algorithm sntrup761x25519-sha512 has not yet received FIPS approval. Because GitHub must comply with these federal standards for customers in this region, the algorithm cannot be offered there. For other regions and GitHub.com, FIPS restrictions do not apply, so the new algorithm can be deployed. GitHub continues to monitor the FIPS certification process and may enable the algorithm in the United States region once it is approved.

What is a “store now, decrypt later” attack and how does this algorithm defend against it?

A “store now, decrypt later” attack is a long-term threat where an attacker captures encrypted communications today and stores them, waiting for future technology—such as a powerful quantum computer—to break the encryption. Even if your session is secure now, it could be decrypted years later. The new hybrid algorithm defends against this by combining a post-quantum secure key encapsulation mechanism (Streamlined NTRU Prime) with classical elliptic-curve cryptography (X25519). The post-quantum component provides security even if a quantum computer can solve discrete logarithms, while the classical component ensures that even if the post-quantum algorithm proves weaker than expected, your security won’t drop below current standards. This dual protection makes it extremely unlikely that any future decryption attempt will succeed.

How do I check if my SSH client supports the new algorithm?

To see if your SSH client supports sntrup761x25519-sha512, open a terminal and run: ssh -Q kex (on OpenSSH 9.x and newer). This will list all supported key exchange algorithms. Look for sntrup761x25519-sha512@openssh.com or sntrup761x25519-sha512 in the output. If it appears, your client is ready. Alternatively, you can test a verbose SSH connection to GitHub: ssh -vT git@github.com. If the new algorithm is used, you’ll see a debug line like debug1: kex: algorithm: sntrup761x25519-sha512@openssh.com. If you don’t see this, you may need to update to a newer SSH client (e.g., OpenSSH 9.0 or later) or your system may not have enabled the algorithm by default.