Richtlinie für Post-Quanten-Verfahren

graph TD
    OP["Operation mit PQ-Anteil"]
    REC{"Empfiehlt die Richtlinie das Verfahren?"}
    KIND{"Erzeugt die Operation neue Daten?"}
    PURE{"CryptoMode.PostQuantum?"}
    FLAG{"Freischaltung in PostQuantumConfig.Exemptions gesetzt?"}
    RUN["Operation läuft"]
    EVT["Ereignis PolicyDeviation, dann läuft die Operation"]
    ERR["CryptographicException mit Abschnitt der Richtlinie und Name der Freischaltung"]
    OP --> REC
    REC -- "ja" --> RUN
    REC -- "nein" --> PURE
    PURE -- "ja" --> FLAG
    PURE -- "nein" --> KIND
    KIND -- "ja: erzeugen, signieren, kapseln, verschlüsseln" --> FLAG
    KIND -- "nein: prüfen, entkapseln, entschlüsseln" --> EVT
    FLAG -- "ja" --> EVT
    FLAG -- "nein" --> ERR

Bild: Empfohlene Verfahren laufen ohne Weiteres. Andere Verfahren erzeugen neue Daten nur mit einer Freischaltung. Vorhandene Daten bleiben ohne Freischaltung prüf- und lesbar, außer in der Betriebsart PostQuantum. Jede Abweichung meldet das Ereignis PolicyDeviation.

Die Bibliothek setzt für Post-Quanten-Verfahren (PQ) die Empfehlungen der Technischen Richtlinie BSI TR-02102-1 „Kryptographische Verfahren: Empfehlungen und Schlüssellängen“, Version 2026-01, als Voreinstellung durch. Verfahren, die die Richtlinie nicht empfiehlt, sind weiter vorhanden, weil Normen und Gegenstellen sie verlangen. Eine Anwendung verwendet sie aber nur, wenn sie das beim Start ausdrücklich erlaubt.

• Voreinstellung nach BSI TR-02102-1 (2026-01): PostQuantumConfig.Policy nennt die Richtlinie. Ohne weitere Angabe erzeugt die Bibliothek nur Daten mit empfohlenen Verfahren.
• Freischaltungen in PostQuantumConfig.Exemptions für drei Regeln: reine PQ-Verfahren, reduzierte Parametersätze, nicht empfohlene Kombinierer.
• Lesbarkeit vorhandener Daten: Prüfen, Entkapseln und Entschlüsseln mit reduzierten Parametersätzen und nicht empfohlenen Kombinierern bleiben ohne Freischaltung möglich.
• Ereignis PostQuantumConfig.PolicyDeviation bei jeder Verwendung über die Empfehlung hinaus, zum Protokollieren, Zählen oder Abweisen.
• KeyCombine nach NIST SP 800-227 als Voreinstellung aller hybriden Schlüsselvereinbarungen der Bibliothek, öffentlich nutzbar als KeyCombiner.Combine.

Die Tabelle trennt drei Fragen: Was empfiehlt die Richtlinie, was setzt die Bibliothek um, und was lässt sie ohne Freischaltung zu.

„Gesperrt“ heißt: Die Operation wirft eine CryptographicException. „Erlaubt“ bei einem nicht empfohlenen Verfahren heißt: Die Operation läuft und meldet das Ereignis PolicyDeviation.

PostQuantumConfig.Exemptions ist eine Aufzählung von Schaltern (PostQuantumExemptions). Jeder Schalter erlaubt das Erzeugen neuer Daten nach einer Regel, die die Richtlinie nicht empfiehlt:

Setzen Sie die Schalter einmal beim Start der Anwendung, vor der ersten kryptografischen Operation. Sie gelten für den ganzen Prozess:

// Die Anwendung stellt ML-DSA-Zertifikate nach RFC 9881 aus.
PostQuantumConfig.Exemptions = PostQuantumExemptions.PurePostQuantum;

Fehlt der Schalter, nennt die CryptographicException den Abschnitt der Richtlinie, die empfohlene Alternative und den Schalter. Die Meldung für ML-DSA-44 lautet:

ML-DSA-44 is not recommended by BSI TR-02102-1 (2026-01), §5.3.4.2, Table 5.7; use ML-DSA-65 or ML-DSA-87. To create data with it anyway, permit it at startup with PostQuantumConfig.Exemptions |= PostQuantumExemptions.ReducedParameterSets. Verifying and decapsulating existing data needs no exemption.

PostQuantumConfig.PolicyDeviation meldet jede Verwendung über die Empfehlung hinaus, unmittelbar bevor die Operation läuft. Die Argumente vom Typ PostQuantumPolicyEventArgs beschreiben die Abweichung:

Der Handler läuft synchron im Thread der Operation. Wirft er eine Ausnahme, bricht die Operation ab, und der Aufrufer erhält diese Ausnahme. So kann eine Anwendung auch das Prüfen alter Daten mit nicht empfohlenen Verfahren abweisen. Operationen, die mangels Schalter scheitern, melden kein Ereignis.

PostQuantumConfig.PolicyDeviation += (_, e) =>
    Console.WriteLine($"{e.Algorithm} in {e.Operation} ({e.Reference}), freigeschaltet: {e.IsExempted}");

Eine hybride Schlüsselvereinbarung rechnet ein PQ-Verfahren und ein klassisches Verfahren nebeneinander und leitet aus beiden Geheimnissen einen Schlüssel ab. Der Schlüssel soll sicher bleiben, solange eines der beiden Verfahren sicher ist. Das gelingt nur, wenn der Kombinierer außer den Geheimnissen auch die Chiffrate und die öffentlichen Schlüssel einbindet; die Richtlinie empfiehlt dafür CatKDF und KeyCombine (§2.2, Tab. 2.1).

Die Bibliothek setzt KeyCombine nach NIST SP 800-227, Abschnitt 4.6.2, Gleichung (15) um und realisiert die Funktion H mit HKDF-SHA256 (RFC 5869), wie es die Richtlinie empfiehlt:

• Eingabe: die beiden Geheimnisse als Schlüsselmaterial; die Längen der Geheimnisse, die beiden Chiffrate, die beiden öffentlichen Schlüssel und eine Domänentrennung als Kontext. Jeder Wert steht mit seiner Länge davor, damit sich keine zwei Eingaben zu derselben Bytefolge verbinden.
• Domänentrennung: eine feste Kennung der Konstruktion, die Namen beider Verfahren mit Parametersatz und der Kontext des Aufrufers.
• Verwendung: HybridKeyAgreement (ECDH mit ML-KEM), EncryptHybrid (RSA-OAEP mit ML-KEM) und EncryptEcdhPq verwenden KeyCombine als Voreinstellung. KeyCombiner.Combine steht für eigene Protokolle bereit.

HybridEncryptedData vermerkt den Kombinierer im Kopf der Daten. Daten einer früheren Fassung der Bibliothek mit HybridKeyCombiner.Version1 lassen sich deshalb weiter entschlüsseln.

• Eine Richtlinie, nicht austauschbar. Die Bibliothek kennt nur BSI TR-02102-1 in der Version 2026-01. Eine neue Version der Richtlinie kommt mit einer neuen Fassung der Bibliothek; das CHANGELOG nennt dann die geänderten Regeln.
• Nur PQ-Verfahren. Die Richtlinie wirkt auf ML-DSA, ML-KEM, ihre Kombinationen und die Kombinierer. Klassische Verfahren und ihre Schlüssellängen, etwa RSA-2048 statt RSA-3072, prüft die Bibliothek nicht. Aufrufe ohne CryptoMode und ohne PQ-Schlüssel berührt die Richtlinie nicht.
• Bausteine für ein einzelnes Verfahren. MLDsaKey, MLKemKey und die Methoden der Anbieter (ICryptoProvider, etwa SignMlDsaAsync in Blazor WebAssembly) rechnen ein Verfahren allein, als Baustein für eine Kombination. Sie prüfen die Parametersätze, nicht die Betriebsart. Dass ein solcher Baustein in Ihrem Protokoll zusammen mit einem klassischen Verfahren arbeitet, stellt Ihre Anwendung sicher.
• Eigene Schlüssel für hybride Signaturen. Die Richtlinie empfiehlt, Schlüssel für hybride Signaturen nur dafür zu erzeugen und nicht auch für einfache Signaturen zu verwenden (§5.3.4). Ohne eigenen Schlüssel erzeugt die Bibliothek für jedes hybride Zertifikat einen neuen ML-DSA-Schlüssel. Übergeben Sie selbst einen, etwa mit X509CertificateBuilder.AlternativeKey, kann sie nicht prüfen, ob er auch anderswo verwendet wird.
• Kein Ersatz für eine Prüfung. Die Voreinstellung setzt die Empfehlungen der Richtlinie zu Verfahren und Parametersätzen um. Sie ist keine Zulassung und keine Zertifizierung der Bibliothek oder einer Anwendung.
• PBKDF2 in PFX-Dateien. PKCS#12 kennt kein Argon2id. PFX-Dateien leiten ihren Schlüssel deshalb mit PBKDF2 ab; siehe Schlüssel und ihre Ablage.
• Prozessweite Schalter. Exemptions gilt für alle Threads. Eine Änderung, während Operationen laufen, wirkt ohne festgelegte Reihenfolge auf diese Operationen.

• Betriebsarten und Aufrufbindung
• Schlüssel und ihre Ablage
• So vereinbaren Sie einen hybriden Schlüssel
• So stellen Sie reine ML-DSA-Zertifikate aus
• Die Richtlinie weist eine Operation ab