Inhaltsverzeichnis

1.3 Vergleich mit .NET 10

1.3 Vergleich mit .NET 10

Warum WvdS.System.Security.Cryptography statt .NET 10 PQC?

.NET 10 PQC-Unterstützung

Microsoft hat in .NET 10 (Preview, GA November 2025) native PQC-Unterstützung eingebaut¹⁾:

MLDsa / MLDsaCng / MLDsaOpenSsl – ML-DSA Signaturen
MLKem / MLKemCng / MLKemOpenSsl – ML-KEM Schlüsselkapselung
SlhDsa / SlhDsaCng / SlhDsaOpenSsl – SLH-DSA Signaturen
CompositeMLDsa – Hybrid-Ansatz (manuell)

Vorteile unserer Lösung

Aspekt	Microsoft .NET 10	WvdS-Lösung
Verfügbarkeit	.NET 10+ (November 2025)	.NET 8.0+ (jetzt verfügbar)
Migrationsstrategie	Neues API, Code-Änderungen	Drop-in Replacement, 2 Zeilen
Hybrid-Modus	Manuell via `CompositeMLDsa`	Automatisch mit `CryptoMode.Hybrid`
Bestehender Code	Muss umgeschrieben werden	Funktioniert unverändert
X.509 Integration	Neue Klassen	Erweitert bestehende `X509Certificate2`
CMS/PKCS#7	Nicht dokumentiert	Volle Unterstützung
RSA/ECDSA Extensions	Separate Klassen	Erweitert bestehende `RSA`, `ECDsa`

Migration: .NET 10 vs. WvdS

Mit .NET 10 (neues API)

// .NET 10: Komplett neuer Code erforderlich
using var mlDsa = MLDsa.Create(MLDsaAlgorithm.MLDsa65);
byte[] signature = mlDsa.SignData(data);
 
// Hybrid manuell implementieren
using var composite = CompositeMLDsa.Create(
    CompositeMLDsaAlgorithm.MlDsa65Ecdsa256);
byte[] hybridSig = composite.SignData(data);
 
// Bestehender RSA-Code funktioniert NICHT mehr
// using var rsa = RSA.Create(); // → keine PQ-Signatur

Mit WvdS-Lösung (Drop-in)

using WvdS.System.Security.Cryptography;
 
// Zwei Zeilen – fertig!
CryptoConfig.DefaultMode = CryptoMode.Hybrid;
 
// Bestehender Code funktioniert automatisch mit PQ
using var rsa = RSA.Create(4096);
byte[] signature = rsa.SignData(data,
    HashAlgorithmName.SHA256,
    RSASignaturePadding.Pkcs1);
// → Enthält automatisch RSA + ML-DSA Signatur

Szenarien-Vergleich

Szenario 1: Bestehendes Projekt migrieren

Problem: Großes Projekt mit hunderten RSA/ECDSA-Aufrufen.

.NET 10	Jede Stelle im Code ändern, neue Klassen verwenden
WvdS	`CryptoConfig.DefaultMode = CryptoMode.Hybrid;` – fertig

Szenario 2: Rückwärtskompatibilität benötigt

Problem: Partner unterstützen noch kein PQC.

.NET 10	Zwei Code-Pfade: klassisch für alte, PQ für neue Partner
WvdS	Hybrid-Modus: Alte Partner ignorieren PQ-Extension, neue validieren sie

Szenario 3: CMS/PKCS#7 Dokumentensignaturen

Problem: Bestehende SignedCms-Integration.

.NET 10	Nicht dokumentiert, wahrscheinlich manuelle Integration
WvdS	`SignedCmsExtensions` erweitert bestehende API transparent

Szenario 4: X.509-Zertifikatsketten

Problem: X509Chain.Build() soll PQ-Signaturen validieren.

.NET 10	Neue Chain-Klassen erforderlich (unklar)
WvdS	Bestehende `X509Chain` funktioniert, PQ-Validierung automatisch

Wann .NET 10 wählen?

Microsoft .NET 10 PQC kann sinnvoll sein wenn:

Greenfield-Projekt (keine bestehende Codebasis)
Nur .NET 10+ unterstützt wird
Keine Hybrid-Strategie benötigt wird
Keine CMS/PKCS#7-Anforderungen

Wann WvdS wählen?

WvdS.System.Security.Cryptography ist besser wenn:

Bestehendes Projekt migriert werden soll
.NET 8.0 oder frühere LTS-Versionen verwendet werden
Rückwärtskompatibilität wichtig ist (Hybrid-Modus)
CMS/PKCS#7-Signaturen benötigt werden
Minimaler Migrationsaufwand gewünscht ist
Sofortige Verfügbarkeit (nicht auf .NET 10 GA warten)

Zusammenfassung

Kriterium	Empfehlung
Bestehendes Projekt	WvdS
.NET 8.0 LTS	WvdS
Hybrid-Strategie	WvdS
CMS/PKCS#7	WvdS
Greenfield + .NET 10 only	.NET 10 oder WvdS
Nur PQ (kein Hybrid)	Beides möglich

Fazit: Für die meisten realen Migrationsszenarien bietet WvdS.System.Security.Cryptography den einfachsten und risikoärmsten Weg zu Post-Quantum-Kryptographie.

Weiterführend

Migration – Phasen-basierte Umstellung
Erste Schritte – Schnellstart

Wolfgang van der Stille @ EMSR DATA d.o.o. - Post-Quantum Cryptography Professional

konzepte, vergleich, dotnet10, migration

¹⁾

Microsoft .NET 10 PQC: https://learn.microsoft.com/en-us/dotnet/api/system.security.cryptography?view=net-10.0