Post-quantum cryptography is reshaping how secure communication protocols establish shared secrets. While today's TLS and SSH deployments continue to rely on classical public-key cryptography, .NET developers should begin preparing for future transitions by understanding existing key exchange mechanisms, designing for cryptographic agility, maintaining supported dependencies, and monitoring vendor support for emerging post-quantum standards.
Before encrypted application data can be exchanged, secure communication protocols must establish shared cryptographic secrets between systems that have never communicated before. For decades, this process has relied on public-key cryptography and mathematical problems that remain computationally infeasible for conventional computers.
As organizations prepare for post-quantum cryptography, understanding how classical key exchange works provides important context for evaluating protocol support, library capabilities, and long-term migration planning.
How Classical Key Exchange Actually Works
Secure communication protocols use public-key cryptography to establish shared secrets between systems that have not previously exchanged secret keys.
Three classical approaches have played important roles in this process:
- RSA key transport: Encrypts a session secret using the recipient's public key.
- Finite-field Diffie-Hellman: Allows two parties to derive the same shared secret from publicly exchanged values.
- Elliptic-Curve Diffie-Hellman (ECDH): Performs a similar exchange using elliptic-curve groups, enabling smaller keys and efficient computation.
These approaches rely on mathematical problems that are considered computationally infeasible for conventional computers at appropriately selected key sizes. RSA relies on the difficulty of factoring large composite integers, while finite-field Diffie-Hellman and ECDH rely on forms of the discrete logarithm problem.
Protocols such as TLS, SSH, and IPsec have historically used classical public-key cryptography to establish shared secrets before protecting application data with faster symmetric encryption.
SSH provides an extensible key-exchange framework. RFC 4253 defines the SSH Transport Layer Protocol and describes how SSH performs key exchange, server authentication, encryption, and integrity protection. Additional RFCs define further Diffie-Hellman and elliptic-curve key-exchange methods for SSH.
The specific algorithms negotiated during a connection depend on the protocol implementation, its configuration, and the algorithms supported by both endpoints.
What This Means for .NET File Transfer
A .NET application transferring data over SFTP, FTPS, or HTTPS depends on the security protocol beneath that transfer.
- SFTP: Runs over SSH.
- FTPS: Uses TLS with FTP.
- HTTPS: Uses TLS with HTTP.
Each protocol establishes cryptographic parameters before protected application data is exchanged. However, SSH and TLS use different handshake mechanisms and expose different diagnostic information.
This distinction matters when assessing post-quantum readiness. A TLS example cannot be used to demonstrate the capabilities of an SSH or SFTP library, and an SSH library's API should not be assumed to expose a particular algorithm or connection property unless its documentation confirms that capability.
Applications that protect data with a long confidentiality lifetime should also account for the harvest now, decrypt later threat. An attacker could retain encrypted traffic and attempt to decrypt it in the future if sufficiently capable quantum computers become available.
Design for Cryptographic Agility
The practical response is cryptographic agility: designing software so that cryptographic algorithms, protocol versions, certificates, and supporting libraries can change without requiring a major rewrite of business logic.
For .NET applications, this can include:
- Keeping security-sensitive dependencies on supported versions.
- Avoiding application logic that depends on one hard-coded algorithm.
- Separating protocol configuration from file-processing or business logic.
- Maintaining an inventory of systems that use public-key cryptography.
- Recording relevant protocol and connection information where the platform or library safely exposes it.
- Reviewing vendor documentation and release notes for security updates.
Diagnostic capabilities vary between TLS, SSH, and SFTP implementations. When evaluating a third-party library, ask whether its documentation identifies supported cryptographic algorithms, explains how security configuration is managed, and describes how security updates are delivered. Do not assume that a particular API exposes the negotiated key-exchange algorithm unless that API is documented.
Inspecting Negotiated TLS Parameters with SslStream
The following example demonstrates how to use the built-in .NET SslStream class from the System.Net.Security namespace to establish a TLS connection and inspect the negotiated protocol version and cipher suite. The example illustrates standard .NET APIs only and is not specific to any SSH, SFTP, or third-party library.
C# Example
using System.Net.Sockets;
using System.Security.Authentication;
using var client = new TcpClient();
await client.ConnectAsync(host, port);
using var ssl = new SslStream(client.GetStream(), false);
await ssl.AuthenticateAsClientAsync(new SslClientAuthenticationOptions
{
TargetHost = host,
EnabledSslProtocols = SslProtocols.Tls13
});
Console.WriteLine($"TLS protocol: {ssl.SslProtocol}");
Console.WriteLine($"Cipher suite: {ssl.NegotiatedCipherSuite}");
Microsoft documents SslStream as the .NET API for establishing authenticated SSL/TLS connections. The negotiated protocol version and cipher suite shown above are provided by the underlying TLS implementation after a successful handshake.
Important Note
This example should only be used with services that expect TLS on the selected port. It does not connect to an SFTP server because SFTP uses SSH rather than TLS. Applications that use SSH or SFTP should consult the documentation for their chosen library to determine which negotiated algorithms and connection properties are available for inspection.
Building Secure File Transfer on .NET
Secure file transfer depends on more than selecting strong cryptographic algorithms. Long-term resilience also requires maintainable architecture, supported software dependencies, controlled configuration, and a process for responding to changes in cryptographic guidance.
When selecting a .NET file-transfer implementation, consider:
- Whether it supports the protocols your application requires.
- How cryptographic configuration is managed.
- Which protocol versions and algorithms are supported.
- How security updates are delivered.
- The quality of the vendor's documentation and support.
- How configuration changes can be tested before deployment.
Avoid relying on undocumented APIs or assuming that a library exposes specific cryptographic details unless those capabilities are explicitly documented by the vendor.
In addition to evaluating technical capabilities, review the product's official license agreement to understand its permitted use, deployment rights, support terms, and any other licensing conditions that apply to your organization. Licensing terms vary between vendors and products and should always be confirmed using the vendor's current documentation rather than assumed.
Designing applications with cryptographic agility, maintaining supported dependencies, and understanding both the technical and licensing requirements of the software you adopt will help reduce operational risk and simplify future migrations as cryptographic standards continue to evolve.
Preparing for Post-Quantum Migration
1. Build a Cryptographic Inventory
Identify systems that use public-key cryptography, including:
- TLS endpoints
- SSH clients and servers
- VPN infrastructure
- Certificate-management systems
- Authentication services
- Digital-signature workflows
- Code-signing infrastructure
- Third-party services and embedded dependencies
The inventory should record where cryptography is used, what it protects, who maintains it, and which systems or vendors control the implementation.
2. Prioritize by Risk and Data Lifetime
Not every system requires the same migration schedule. Give greater priority to systems that protect highly sensitive information or data that must remain confidential for many years. These systems face greater exposure to harvest-now-decrypt-later scenarios.
3. Track Platform and Vendor Support
Application teams do not control every layer of the cryptographic stack. Support may depend on operating systems, protocol libraries, cloud services, appliances, external partners, or managed platforms.
- Which post-quantum standards they plan to support.
- Whether upgrades require configuration, software replacement, or new infrastructure.
- How interoperability will be maintained during migration.
- Which versions will continue receiving security updates.
4. Use Standardized Transition Mechanisms
Migration may involve a transition period in which classical and post-quantum mechanisms are used together. Hybrid deployment should be implemented through standardized protocol mechanisms and supported libraries rather than custom algorithm combinations.
5. Test Before Production Rollout
Post-quantum changes can affect handshake sizes, latency, certificate sizes, interoperability, memory usage, hardware requirements, and monitoring systems.
- Handshake sizes
- Latency
- Certificate and message sizes
- Interoperability
- Memory use
- Hardware requirements
- Monitoring and troubleshooting systems
Test representative workloads and integration points before enabling new algorithms in production.
6. Maintain Agility After Migration
Post-quantum migration is not a one-time task. Standards, implementations, and attack research will continue to evolve. Keep cryptographic choices replaceable, monitor authoritative standards bodies, maintain dependency inventories, and periodically test whether systems can transition to updated configurations without significant application changes.
Practical Checklist
- Inventory: Identify where public-key cryptography is used.
- Prioritize: Focus first on systems protecting long-lived sensitive data.
- Modernize: Keep cryptographic libraries and dependencies current.
- Verify: Confirm vendor support for post-quantum standards.
- Test: Validate interoperability before production rollout.
- Design for Agility: Avoid hard-coded algorithms and tightly coupled cryptographic logic.
Looking for reliable .NET components for secure file transfer? Explore Xceed's professional libraries and evaluate their capabilities for your application's security and deployment requirements.
Preguntas frecuentes
Does SFTP use TLS?
No. SFTP runs over SSH, while FTPS and HTTPS use TLS. Because SSH and TLS use different handshake mechanisms, examples and diagnostics for one protocol generally do not apply to the other.
Can SslStream inspect SSH connections?
No. SslStream is a .NET API for SSL/TLS connections. SSH and SFTP applications must use the APIs provided by their chosen SSH library to inspect negotiated connection properties, where supported.
What is cryptographic agility?
Cryptographic agility is the practice of designing software so algorithms, protocol versions, certificates, and supporting libraries can be updated without requiring major changes to application logic.
Why should organizations prepare now if quantum computers cannot yet break modern cryptography?
Cryptographic migrations often require years of planning, testing, and coordinated deployment. Organizations that maintain inventories, modernize dependencies, and build cryptographic agility today will be better positioned as post-quantum standards and platform support continue to mature.