In backend development, choosing between Windows and Linux often feels like a matter of preference.
But under the hood, that choice determines something much deeper:
Do you control your cryptography — or does your OS vendor?
In a world moving toward post-quantum cryptography (PQC), that question is no longer theoretical.
What Is Post-Quantum Cryptography (PQC)?
Today’s internet security relies heavily on cryptographic algorithms like:
- RSA
- ECC (Elliptic Curve Cryptography)
These are used in TLS to:
- exchange keys
- secure HTTPS traffic
They are considered secure against classical computers.
However, a sufficiently powerful quantum computer could break these algorithms using techniques like Shor's algorithm.
That leads to a well-known threat model:
Store now, decrypt later
An attacker can:
- Capture encrypted traffic today
- Store it
- Decrypt it in the future once quantum capabilities exist
Post-Quantum Cryptography (PQC) refers to new algorithms designed to:
remain secure even against quantum computers
These are currently being standardized and gradually introduced into TLS (often in hybrid form).
The Hidden Detail Most Developers Miss
On Windows, TLS is handled by Schannel, a built-in OS component.
On Linux, TLS is handled in user space:
- OpenSSL
- BoringSSL
- wolfSSL
This difference is invisible in code — but critical in practice.
Same Code, Different Reality
.NET (Windows → Schannel)
var client = new HttpClient();
var response = await client.GetAsync("https://example.com");
- Uses Schannel
- No control over TLS
PowerShell
Invoke-WebRequest https://example.com
- Uses WinHTTP → Schannel
Python (Partial Independence)
import requests
requests.get("https://example.com")
- Uses OpenSSL
- But often embedded in Windows-based infrastructure
Go (Independent)
resp, _ := http.Get("https://example.com")
- Uses Go’s
crypto/tls - Fully independent
Rust (rustls)
let body = reqwest::get("https://example.com").await?.text().await?;
- Can use
rustls - Fully independent
Node.js
https.get('https://example.com', res => {
res.on('data', chunk => process.stdout.write(chunk));
});
- Uses OpenSSL internally
- Not Schannel
curl (Two Worlds)
curl https://example.com
- Windows → often Schannel
- Linux → OpenSSL
Check:
curl -V
The Asymmetry
| Stack | TLS Backend (Windows) | Control |
|---|---|---|
| .NET | Schannel | None |
| PowerShell | Schannel | None |
| IIS | Schannel | None |
| Python | OpenSSL (usually) | Partial |
| Go | crypto/tls | High |
| Rust | rustls/OpenSSL | High |
| Node.js | OpenSSL | High |
| curl | Schannel (default) | Low |
Why PQC Changes Everything
To defend against quantum threats:
- TLS must support new algorithms
- systems must migrate before attackers catch up
On Linux / Go / Rust:
- you can upgrade
- experiment
- deploy early
On Windows:
- you cannot replace Schannel
- you cannot add new algorithms
- you must wait
You do not control when you become quantum-resistant
A Concrete Scenario: The Netherlands Falls Behind
Imagine the following:
- PQC support is rolled out globally
- Microsoft introduces PQC in Schannel
- but rollout is delayed or restricted
Now assume:
The Netherlands does not receive these updates in time
Meanwhile:
-
Dutch hospitals run:
- Windows Server
- IIS
- .NET APIs
All protected by:
classical TLS
Outside the Netherlands
Other regions:
- adopt PQC-enabled TLS
- deploy hybrid cryptography
- reduce exposure
The Result
| Region | Crypto State |
|---|---|
| Netherlands | Classical TLS |
| Others | PQC / Hybrid |
The Risk
Attackers can:
- Target Dutch systems
- capture encrypted traffic
- store it
Years later:
- quantum capabilities mature
- classical crypto breaks
Result:
historical medical data becomes decryptable
Not because systems failed.
But because:
they could not evolve
Why This Is Hard to Fix
Organizations cannot simply:
- replace Schannel
- rewrite .NET systems
- migrate instantly
Especially:
- hospitals
- large enterprises
- government systems
They are constrained by:
- legacy systems
- vendor software
- operational risk
This Is Not Just Technical — It’s Geopolitical
Microsoft is a US-based company.
That means:
- it operates under US law
- it can be compelled by the US government
- legal and political pressure can be applied
If Microsoft controls:
- TLS capabilities (Schannel)
- PQC rollout
- algorithm availability
Then:
external influence can affect when entire countries become quantum-safe
Conclusion: Rethink Your Stack Before It’s Too Late
The core issue is not theoretical.
It is architectural.
If your systems depend on Schannel:
- you do not control your cryptography
- you do not control when new algorithms arrive
- you cannot react independently
That is not security.
That is dependency.
This Forces a Strategic Question
Organizations must ask:
Do we control our cryptographic evolution?
If not:
you are exposed to delays you cannot fix.
Architecture Matters
Platform
- Windows → vendor-controlled crypto
- Linux → operator-controlled crypto
Programming languages
Control differs per ecosystem:
- Go → full control
- Rust → full control
- Node.js → strong control
- Python → partial
- .NET → none (on Windows)
TLS boundaries
- Move TLS out of OS-controlled layers
- prefer user-space TLS stacks
Tooling Matters Too
Even curl is not neutral.
On Windows:
- it often uses Schannel
A Practical Alternative: kemforge
If you want to avoid Schannel:
- kemforge
Features:
- written in Go → independent TLS stack
- not tied to Schannel
- same CLI arguments as curl
- open source
Repository:
Includes:
- installation steps
- usage examples
Final Takeaway
This is the uncomfortable reality:
Cryptography is not just math, it is control.
If you:
- depend on Schannel
- cannot upgrade independently
- cannot adopt PQC when needed
Then your systems are not just technically constrained.
They are:
strategically constrained
And in a post-quantum world:
that constraint can turn into exposure faster than you expect.
Top comments (0)