Cryptography · post-quantum algorithms
Post-quantum cryptography for the software you already have: ML-DSA and ML-KEM
Bring new algorithms into existing systems—without rewriting them. In your process, or as a process of its own.
Two products: a .NET library adds the ML-DSA signature and the ML-KEM key encapsulation mechanism to existing code, one call site at a time. A crypto service offers the same algorithms as a separate process, for embedded and industrial systems on L4Re or Windows. Both are published as previews.
- Your application or component
- Library or crypto service
- OpenSSL 3.5 or later
Either way, OpenSSL does the post-quantum work. The products differ in where the cryptography runs and who holds the keys.
The starting point
The migration starts in software that runs on RSA and ECDSA today
Why now? Because of “store now, decrypt later”: anyone who captures encrypted data today can decrypt it once a capable quantum computer exists. That's why the EU's post-quantum roadmap calls for high-risk use cases to move to post-quantum cryptography by the end of 2030 at the latest. The other deadlines, and where each comes from, are on BSI TR-02102 and post-quantum deadlines.
The first question is which algorithm runs where in your systems. The second is how the new algorithm gets in. Usually, several conditions come together:
- Certificates, signatures, and encrypted messages need to hold up against future quantum computers.
- Rewriting the application is off the table.
- Peers only know classical algorithms and still have to read the data.
- In embedded systems, every component that bundles its own crypto library brings its own key storage, error handling, and updates.
Which product?
What do you want to do?
- Add post-quantum algorithms to a .NET applicationCertificates, signatures, and encrypted messages on .NET Framework 4.6.2 or later, .NET Core 3.1, or .NET 8—call by call. The WKL.System.Security.Cryptography library.
- Create your first hybrid certificate chainRSA or ECDSA plus ML-DSA: certificates that classical verifiers can still read.
- Sign or encrypt messages and documentsSign data, CMS messages, and XML documents, encrypt CMS, agree on a hybrid key, use it in Blazor.
- Run cryptography as a separate processComponents send a request and get the result back; private keys never leave the service. The WvdS Crypto Service.
- Call the service from your programOver the binary protocol on L4Re, or with JSON lines on a named pipe on Windows.
- Check your own integrationTest vectors show complete requests and responses, byte by byte.
- Secure connections to partner organizationsAgree on trust per partner, for a defined purpose and revocable, and add an independent post-quantum secret to TLS 1.3. TrustBridge, in development.
When neither helps: post-quantum HTTPS is the job of a separate transport layer; the library doesn't include a TLS handshake. For connections between organizations, TrustBridge adds an independent post-quantum secret to TLS 1.3. Long-lived signing keys, such as a certificate authority's, belong in a hardware security module. And code that hard-codes key sizes or bypasses the .NET abstractions gains no protection from an extra argument.
Two ways
In your process, or as a process of its own
Both hand the post-quantum work to OpenSSL. What sets them apart is where the cryptography runs and who holds the keys.
The library: inside your .NET application's process
Your .NET application
- Certificates
- CMS messages
- XML signatures
a call without CryptoMode goes to .NET, unchanged
the same call with the CryptoMode argument
WKL.
- classical part: .NET
- post-quantum part: OpenSSL 3.5 or later
- formats classical verifiers read
keys in the operating system's key store or in a PFX file
The crypto service: a process of its own
Your component
- a task on L4Re, such as a gateway
- a program on Windows
no crypto library; an ID instead of the private key
L4Re: binary protocol over shared memory · Windows: JSON lines over a named pipe
WvdS Crypto Service
- AES-256-GCM
- ML-DSA
- ML-KEM
- HKDF-SHA256
keys in memory only; lost on restart
What "without rewriting" means for the library: its extension methods have the same names and parameters as in .NET and add one argument.
The C# compiler always binds a call without that argument to .NET, so existing code behaves bit for bit as before. You extend an application one call at a time. Crypto modes and call binding
// Binds to .NET – unchanged.request.CreateSelfSigned( notBefore, notAfter); // Binds to the library:// classical plus ML-DSA.request.CreateSelfSigned( notBefore, notAfter, CryptoMode.Hybrid);
CryptoMode routes it into the library.Library and service compared
| Aspect | WKL. | WvdS Crypto Service |
|---|---|---|
| Built for | .NET applications: .NET Framework 4.6.2 through 4.8, .NET Core 3.1, .NET 8, Blazor | embedded and industrial systems on the L4Re microkernel (x86_64, aarch64) or on Windows x86_64 |
| How you call it | extension methods with the same names as in .NET plus an extra CryptoMode argument | L4Re: binary protocol over shared memory · Windows: JSON lines over a named pipe |
| Algorithms | ML-DSA and ML-KEM, combined with RSA, ECDSA, or ECDH; for certificates, CRLs, CMS, XML signatures, and PFX | AES-256-GCM, ML-DSA-44, -65, and -87, ML-KEM-512, -768, and -1024, HKDF-SHA256 |
| Hybrid | yes; the defaults follow BSI TR-02102-1 and produce post-quantum output only alongside a classical algorithm | no; if you need hybrid, you combine the secrets yourself |
| Keys | in the operating system's key store (Windows, Linux with Secret Service) or in a PFX file | in the service's memory only; lost on restart |
| OpenSSL | 3.5 or later, not included; installing and patching it is part of your operations | 3.5 or later; the L4Re build compiles OpenSSL along with the service |
Go to the library · Go to the crypto service · Deployment forms compared
What to know before you start
Preview
Both products are published as previews. Interfaces, protocols, and data formats may change before the first release.
- No certification. Neither the library nor the service is certified under FIPS 140-3 or any other evaluation scheme. Defaults that follow BSI TR-02102-1 are not an approval.
- No silent fallback. If a library call asks for a post-quantum part and can't produce it, the call fails—it never hands back a purely classical result.
- OpenSSL is part of your operations. The library doesn't ship OpenSSL; you install version 3.5 or later and apply its security updates yourself.
- Provisional identifiers. No standard assigns identifiers for post-quantum signatures in CMS and XML yet. Only peers using this library can verify those messages; classical verifiers still read them.
- Two protocols for the service. The L4Re and Windows builds don't understand the same messages; a program that talks to both needs two integrations.
The overview pages list every limitation: library · crypto service
Find your way into the docs
| You want to … | Library | Crypto service |
|---|---|---|
| check what you need | Prerequisites | Prerequisites |
| get a first result | Create your first hybrid certificate chain | Build and test |
| understand how it works | Crypto modes and call binding | Keys and key storage |
| choose algorithms and parameters | Post-quantum algorithm policy | Algorithms and parameter sets |
| look something up | Reference | Reference |
| fix a problem | Troubleshooting | Troubleshooting |
Between organizations
TrustBridge: trust per partner, protected by an additional post-quantum secret
For companies in a supply chain whose systems have to work together – without a shared network, central accounts, or certificates of unclear origin. Each organization keeps its own identities, keys, and rules; trust is agreed per partner, for a defined purpose, and can be revoked at any time. Connections run over TLS 1.3, and key agents on both sides additionally agree on a post-quantum secret with ML-KEM that goes into the handshake. Anyone recording the connection today would later have to break both.
In development
The documentation describes the full feature set.
Overview · PQ key exchange for TLS · Federation · Operating models
Every migration starts with one question: which algorithm runs where in your systems. The library is in the shop, with its requirements and limitations.
See the library in the shop