Inhaltsverzeichnis

1.3 Comparison with .NET 10

1.3 Comparison with .NET 10

Why WvdS.System.Security.Cryptography instead of .NET 10 PQC?

.NET 10 PQC Support

Microsoft has built native PQC support into .NET 10 (Preview, GA November 2025)¹⁾:

MLDsa / MLDsaCng / MLDsaOpenSsl - ML-DSA signatures
MLKem / MLKemCng / MLKemOpenSsl - ML-KEM key encapsulation
SlhDsa / SlhDsaCng / SlhDsaOpenSsl - SLH-DSA signatures
CompositeMLDsa - Hybrid approach (manual)

Advantages of Our Solution

Aspect	Microsoft .NET 10	WvdS Solution
Availability	.NET 10+ (November 2025)	.NET 8.0+ (available now)
Migration Strategy	New API, code changes	Drop-in replacement, 2 lines
Hybrid Mode	Manual via `CompositeMLDsa`	Automatic with `CryptoMode.Hybrid`
Existing Code	Must be rewritten	Works unchanged
X.509 Integration	New classes	Extends existing `X509Certificate2`
CMS/PKCS#7	Not documented	Full support
RSA/ECDSA Extensions	Separate classes	Extends existing `RSA`, `ECDsa`

Migration: .NET 10 vs. WvdS

With .NET 10 (new API)

// .NET 10: Completely new code required
using var mlDsa = MLDsa.Create(MLDsaAlgorithm.MLDsa65);
byte[] signature = mlDsa.SignData(data);
 
// Hybrid implemented manually
using var composite = CompositeMLDsa.Create(
    CompositeMLDsaAlgorithm.MlDsa65Ecdsa256);
byte[] hybridSig = composite.SignData(data);
 
// Existing RSA code NO LONGER works
// using var rsa = RSA.Create(); // -> no PQ signature

With WvdS Solution (Drop-in)

using WvdS.System.Security.Cryptography;
 
// Two lines - done!
CryptoConfig.DefaultMode = CryptoMode.Hybrid;
 
// Existing code automatically works with PQ
using var rsa = RSA.Create(4096);
byte[] signature = rsa.SignData(data,
    HashAlgorithmName.SHA256,
    RSASignaturePadding.Pkcs1);
// -> Automatically contains RSA + ML-DSA signature

Scenario Comparison

Scenario 1: Migrate Existing Project

Problem: Large project with hundreds of RSA/ECDSA calls.

.NET 10	Change every location in code, use new classes
WvdS	`CryptoConfig.DefaultMode = CryptoMode.Hybrid;` - done

Scenario 2: Backward Compatibility Required

Problem: Partners don't support PQC yet.

.NET 10	Two code paths: classical for old, PQ for new partners
WvdS	Hybrid mode: Old partners ignore PQ extension, new ones validate it

Scenario 3: CMS/PKCS#7 Document Signatures

Problem: Existing SignedCms integration.

.NET 10	Not documented, likely manual integration
WvdS	`SignedCmsExtensions` extends existing API transparently

Scenario 4: X.509 Certificate Chains

Problem: X509Chain.Build() should validate PQ signatures.

.NET 10	New chain classes required (unclear)
WvdS	Existing `X509Chain` works, PQ validation automatic

When to Choose .NET 10?

Microsoft .NET 10 PQC can make sense when:

Greenfield project (no existing codebase)
Only .NET 10+ will be supported
No hybrid strategy needed
No CMS/PKCS#7 requirements

When to Choose WvdS?

WvdS.System.Security.Cryptography is better when:

Existing project needs migration
.NET 8.0 or earlier LTS versions are used
Backward compatibility is important (Hybrid mode)
CMS/PKCS#7 signatures are needed
Minimal migration effort is desired
Immediate availability (not waiting for .NET 10 GA)

Summary

Criterion	Recommendation
Existing project	WvdS
.NET 8.0 LTS	WvdS
Hybrid strategy	WvdS
CMS/PKCS#7	WvdS
Greenfield + .NET 10 only	.NET 10 or WvdS
PQ only (no hybrid)	Either works

Conclusion: For most real-world migration scenarios, WvdS.System.Security.Cryptography offers the simplest and lowest-risk path to post-quantum cryptography.