Vergleich von SLH-DSA, LMS und XMSS für Firmware- und Codesignierung

Wer Software oder Firmware signiert, ist vom Übergang zur Post-Quanten-Technologie fast schneller betroffen als alle anderen und steht vor einer Entscheidung, die in der übrigen Diskussion um Post-Quanten-Technologie weitgehend unbeachtet bleibt. Die meiste Aufmerksamkeit gilt TLS und Zertifikaten, die bei Änderungen innerhalb weniger Stunden neu ausgestellt werden können. Bei der Firmware-Signierung verhält es sich genau umgekehrt. Die Signatur eines Firmware-Images muss zehn bis fünfzehn Jahre lang verifizierbar bleiben – auf Geräten, die man möglicherweise nie wieder physisch berührt, und gegen einen Angreifer, der bis zum Auslaufen dieser Geräte bereits über einen Quantencomputer verfügen könnte.

Wenn diese Signatur auf RSA oder ECDSA basiert, kann ein Quantencomputer sie fälschen. Gefälschte Firmware ist dann Firmware, der das Gerät vertraut und die es ausführt. Sobald die Vertrauensbasis fest in die Hardware integriert ist, lässt sich das Problem in der Regel nicht nachträglich beheben. Dadurch sind die Geräte, die Sie dieses Jahr ausliefern, am anfälligsten und am schwierigsten zu reparieren, sobald sie im Einsatz sind. Dieser Teil der Post-Quanten-Migration ist dringend und muss unbedingt aufgeschoben werden. Aus diesem Grund hat die Firmware-Signierung den frühesten Stichtag im gesamten Übergangsprozess.

Der Druck ist groß, doch die Antworten liegen auf der Hand. Die quantensicheren Signaturalgorithmen für diese Aufgabe – SLH-DSA , LMS und XMSS – basieren alle auf Hash-Funktionen, sind standardisiert und gründen auf Kryptographie, die seit Jahrzehnten erforscht wird. Die Frage, vor der Signaturteams im Jahr 2026 stehen, ist also nicht, ob eine Lösung existiert, sondern welche. Und die ehrliche Antwort auf diese Frage ist komplexer, als es zunächst scheint. Dieser Beitrag erläutert die Unterschiede zwischen diesen Algorithmen, den zentralen Konflikt zwischen zustandsbehafteten und zustandslosen Verfahren sowie die regulatorische Richtlinie, die die Entscheidung oft erleichtert.

Post-Quanten-Signaturalgorithmen für die Codesignierung, definiert: SLH-DSA (FIPS 205), LMS und XMSS (beide NIST SP 800-208) sind die Hash-basierten Signaturverfahren, die für die Signierung von Artefakten standardisiert sind, die über ein Jahrzehnt oder länger verifizierbar bleiben müssen; die Wahl zwischen ihnen hängt davon ab, ob Ihr Signiervorgang den kryptografischen Zustand sicher verwalten kann, nicht von der Rohleistung.

Wichtige Erkenntnisse

• LMS und XMSS sind zustandsbehaftet: Jeder private Schlüssel kann nur eine begrenzte Anzahl von Signaturen erzeugen, und die Wiederverwendung einer einmaligen Komponente aus einem wiederhergestellten Backup oder durch parallele Signierung kann es einem Angreifer ermöglichen, Signaturen zu fälschen. SLH-DSA ist zustandslos und beseitigt diese Gefahr vollständig, allerdings auf Kosten größerer Signaturen.
• FIPS 205 (SLH-DSA) ist seit August 2024 ein endgültiger NIST-Standard; NIST SP 800-208 (LMS, XMSS) ist seit Oktober 2020 endgültig. Die Unterschiede liegen in der HSM-Firmware-Unterstützung und der Verifiziererkompatibilität für jeden spezifischen Algorithmus, nicht im Standard selbst.
• CNSA 2.0 genehmigt SLH-DSA nicht für nationale Sicherheitssysteme. Falls CNSA 2.0 für Sie relevant ist, stehen Ihnen LMS, XMSS oder ML-DSA zur Verfügung, nicht jedoch SLH-DSA.
• Den vollständigen, datierten Zeitplan für den CNSA 2.0-Übergang und die Migrationsarchitektur finden Sie hier: Gestaltung der CNSA 2.0-ÜbergangsstrategienDieser Artikel konzentriert sich speziell auf die Wahl zwischen SLH-DSA, LMS und XMSS.
• Welchen Algorithmus Sie auch wählen, vergewissern Sie sich vor dem Start eines Pilotprojekts, dass die Firmware Ihres HSM diesen namentlich unterstützt und Ihre Verifizierungswerkzeuge ihn überprüfen können.

Warum Hash-basierte Signaturen, und warum gerade jetzt?

Die Signierung von Code und Firmware besitzt eine Eigenschaft, die die meisten kryptografischen Verfahren nicht aufweisen: Die Signatur muss nahezu alles um sie herum überdauern. Ein Firmware-Image wird einmal signiert, und diese Signatur muss unter Umständen während der gesamten Lebensdauer der Hardware korrekt verifiziert werden können, selbst lange nachdem sich die Signaturinfrastruktur geändert hat. Wird der zugrunde liegende Algorithmus in diesem Zeitraum kompromittiert, kann ein Angreifer eine gefälschte Signatur erstellen und manipulierte Firmware verbreiten, der die Geräte uneingeschränkt vertrauen. Bei einer fest in die Hardware integrierten Vertrauensbasis gibt es möglicherweise keine Möglichkeit, diese vor Ort zu reparieren.

Dieser lange Zeithorizont ist genau der Grund, warum Quantenresistenz hier von größter Bedeutung ist. Aus diesem Grund werden Hash-basierte Signaturen auch als Mittel der Wahl eingesetzt. Anders als RSA und ECDSA , die auf zahlentheoretischen Problemen beruhen, die ein Quantencomputer lösen kann, basieren Hash-basierte Signaturen ausschließlich auf der Sicherheit einer Hash-Funktion wie SHA-256. Hash-Funktionen sind durch Quantencomputer nicht ernsthaft gefährdet, abgesehen von einer geringfügigen Reduzierung der Sicherheit, die durch größere Datenmengen kompensiert wird. Sie sind bewährt, gut erforscht und waren bereits lange vor der Entwicklung gitterbasierter Verfahren einsatzbereit. Für etwas, das fünfzehn Jahre lang sicher bleiben muss, ist diese Erfolgsbilanz von großem Wert.

SLH-DSA, LMS und XMSS basieren alle auf Hash-Funktionen und haben dieselbe Grundstruktur: Viele Einmalsignaturen werden mithilfe eines Merkle-Baums zu einem einzigen öffentlichen Schlüssel kombiniert. Die Unterschiede zwischen ihnen sind ausschlaggebend für die Entscheidung.

Die eigentliche Trennlinie: staatlich oder staatenlos

Der wichtigste Unterschied liegt nicht in der Leistung oder der Größe der Unterschrift. Es ist der Zustand.

LMS und XMSS sind zustandsbehaftet. Jeder private Schlüssel kann nur eine begrenzte Anzahl von Signaturen erzeugen, und der Unterzeichner muss genau nachverfolgen, welche davon verwendet wurden. Diese Nachverfolgung ist entscheidend. Wird der Zustand falsch verwaltet, beispielsweise wenn eine einmalig verwendbare Komponente zweimal verwendet wird, weil ein Schlüssel aus einem Backup wiederhergestellt, auf einen zweiten Server kopiert oder parallel ausgeführt wurde, kann ein Angreifer, der beide Signaturen sieht, neue fälschen. Die Sicherheit dieser Systeme beruht zwingend darauf, dass eine einmalig verwendbare Komponente niemals wiederverwendet wird. Fehlerhafte Zustandsverwaltung führt unbemerkt zum Verlust der Sicherheit.

SLH-DSA ist zustandslos. Es wurde speziell entwickelt, um diese Gefahr zu beseitigen. Anstatt verwendete Signaturen zu verfolgen, trifft es zufällige Auswahlen und verlässt sich darauf, dass die Wahrscheinlichkeit einer Kollision vernachlässigbar gering ist. Es gibt keinen Zustand, der beschädigt werden könnte, keinen Zähler, der verloren gehen könnte, und kein Risiko durch ein wiederhergestelltes Backup. Diese einzelne Designentscheidung hat weitreichende operative Konsequenzen, die als Nächstes abzuwägen sind.

Was man aufgibt und was man auf jedem Weg gewinnt

Zustandsbehaftete Signaturen (LMS und XMSS) sind im Vergleich zu zustandslosen Signaturen effizient und kompakt und haben sich in der Firmware-Signatur seit Langem bewährt. Der Nachteil liegt in der erforderlichen Betriebsdisziplin. Da der Signierer den Zustand lückenlos verwalten muss, ist die Signierung an eine einzige kontrollierte Instanz des Schlüssels gebunden. Eine parallele Ausführung der Signierung auf mehreren Rechnern ist nicht möglich, da dies die Wiederverwendung des Zustands zur Folge hätte.

Bei Firmware-Signaturverfahren, bei denen die Anzahl der Signaturen bekannt und begrenzt ist, stellt diese Einschränkung in der Regel eine akzeptable Bedingung dar. Daher eignen sich diese Verfahren so gut für Firmware. Es wird jedoch dringend empfohlen, den Schlüssel und dessen Zustandsverwaltung in Hardware, einem HSM, zu implementieren, um ein versehentliches Duplizieren oder Zurücksetzen des Zustands zu verhindern.

Von den beiden zustandsbehafteten Optionen ist LMS die einfachere und schnellere Standardlösung. Es benötigt weniger Taktzyklen für Schlüsselerzeugung, Signierung und Verifizierung und verbraucht weniger Speicher. XMSS verwendet zusätzlich eine Bitmaskenkonstruktion, die von manchen Teams aufgrund ihrer höheren Sicherheitsstandards bevorzugt wird, allerdings auf Kosten von mehr Hashing und höherem Speicherverbrauch. Für die meisten Signiervorgänge ist der praktische Unterschied gering, und LMS ist ein sinnvoller Ausgangspunkt, sofern Sie nicht explizit die Vorteile von XMSS benötigen.

Zustandlose Signaturen (SLH-DSA) tauschen Größe gegen Sicherheit. SLH-DSA -Signaturen sind größer, was bei bandbreitenbeschränkten Geräten oder speicherbeschränkten Aktualisierungsmechanismen relevant sein kann, und das Signieren ist rechenintensiver. Im Gegenzug erhält man die vollständige Zustandsfreiheit. Da nichts beschädigt werden kann, lässt sich SLH-DSA parallelisieren und in einem verteilten Signatursystem ausführen, ohne die Wiederverwendungsgefahr, die LMS und XMSS einschränkt. Bei einem hohen Signaturaufkommen oder einem verteilten Signaturvorgang, bei dem die Zustandsverwaltung zwischen verschiedenen Rechnern problematisch wäre, rechtfertigt diese Freiheit die größeren Signaturen.

SLH-DSA vs. LMS vs. XMSS: Seite an Seite

Abmessungen	BMS	XMSS	SLH-DSA
Standard	NIST SP 800-208 (2020)	NIST SP 800-208 (2020)	FIPS 205 (August 2024)
Staat	Zustandsbehaftet; einmalige Schlüssel, dürfen sich niemals wiederholen	Zustandsbehaftet; einmalige Schlüssel, dürfen sich niemals wiederholen	Staatenlos; kein Staat, der verwaltet werden könnte
Relativgeschwindigkeit	Die schnellste der drei; die wenigsten Zyklen	Langsamer als LMS aufgrund der Bitmaskenkonstruktion	Langsamste; aufwändigste Vorzeichenberechnung
Relative Signaturgröße	Compact	Kompakt, etwas größer als LMS	Deutlich größer als LMS/XMSS
Parallele/verteilte Signierung	Ohne hardwareseitig erzwungene Zustandskoordination nicht sicher.	Ohne hardwareseitig erzwungene Zustandskoordination nicht sicher.	Sicher; kein gemeinsamer Staat, der korrumpiert werden könnte.
CNSA 2.0 für die Unterzeichnung des NSS genehmigt	Ja; der von der NSA bevorzugte Parametersatz (SHA-256/192).	Ja	Nein; verwenden Sie stattdessen ML-DSA, wenn für NSS eine zustandslose Option erforderlich ist.
Optimale Bildschirmwahl	Firmware-Signierung mit begrenztem Volumen und einem einzigen kontrollierten Signierer	Dasselbe gilt für LMS, wenn der Sicherheitsspielraum der Bitmaskenkonstruktion speziell gewünscht ist.	Bei hohem Volumen oder verteilter Unterzeichnung, wo die staatliche Koordination fragil wäre

Der Haken, der oft den Ausschlag gibt: CNSA 2.0

Hier stößt der einfache Dreiervergleich an seine Grenzen, und genau dieses Detail wird in den meisten Zusammenfassungen verschwiegen. Wenn Ihre Unterschrift nationale Sicherheitssysteme betrifft oder Ihre Kunden an diese verkaufen, ist die CNSA 2.0- Suite der NSA für Ihre Wahl maßgebend, und CNSA 2.0 genehmigt SLH-DSA nicht.

Für die Signierung von Software und Firmware empfiehlt CNSA 2.0 die zustandsbehafteten Verfahren LMS und XMSS aus NIST SP 800-208, wobei LMS SHA-256/192 als bevorzugten Parametersatz verwendet. SLH-DSA ist ein finaler NIST-Standard gemäß FIPS 205 und für kommerzielle Signaturen uneingeschränkt zulässig, jedoch nicht Teil von CNSA 2.0 und nicht für NSS zugelassen. ML-DSA, der gitterbasierte Standard für zustandslose Signaturen, ist ebenfalls von CNSA 2.0 anerkannt und die sinnvolle Option, wenn das Signiervolumen die Kapazität eines einzelnen zustandsbehafteten Schlüssels übersteigt oder wenn verteilte Signaturen benötigt werden.

Die Entscheidung lässt sich also eindeutig in eine Richtung lenken. Wenn Sie unter CNSA 2.0 fallen, ist Ihre zustandslose Option effektiv ML-DSA und nicht SLH-DSA, und Sie werden wahrscheinlich auf LMS oder XMSS mit hardwarebasierter Zustandsverwaltung aufbauen. Wenn Sie sich für den kommerziellen Bereich entscheiden, steht Ihnen die volle Auswahl an Optionen zur Verfügung, und die oben beschriebene Abwägung zwischen zustandsbehafteten und zustandslosen Architekturen ist eine echte technische Entscheidung und keine Compliance-Beschränkung.

Der Zeitdruck ist in jedem Fall real. Die Firmware-Signatur hat die früheste Frist im gesamten Übergang nach der Quantencomputertechnologie, da die Vertrauensanker der Firmware nach der Auslieferung am schwierigsten zu ändern sind. Gemäß CNSA 2.0 wurde erwartet, dass diese Signaturen bereits jetzt eingeführt werden, wobei die Frist für die Software- und Firmware-Signatur deutlich vor dem umfassenderen Rollout 2035 liegt. Unabhängig davon, ob CNSA 2.0 für Sie gilt oder nicht, bleibt die zugrunde liegende Logik bestehen: Je länger Ihre Signaturen gültig bleiben müssen, desto weniger Zeit bleibt Ihnen für die Umstellung.

Datierter Fahrplan für die Software- und Firmware-Signierung

Milestone	Datum
FIPS 205 (SLH-DSA) und NIST SP 800-208 (LMS, XMSS) Status	Endgültige Standards seit August 2024 bzw. Oktober 2020
CNSA 2.0-Unterstützung und bevorzugtes Datum für die Software-/Firmware-Signatur	2025 (bereits verstrichen)
CNSA 2.0 verwendet ausschließlich das Datum für die Signierung von Software/Firmware.	2030
Vollständiger NSS-Übergang (gemäß NSM-10)	2035

Den vollständigen, in mehrere Kategorien unterteilten CNSA 2.0-Zeitplan und die dahinterstehende fünfphasige Migrationsarchitektur finden Sie unter Architecting the CNSA 2.0 Transition Strategies.

Migrationsabhängigkeiten

Die Wahl eines Algorithmus auf dem Papier ist der einfache Teil. Bevor er etwas Reales bewirken kann:

1. Vergewissern Sie sich anhand des Namens, dass die Firmware Ihres HSM den von Ihnen gewählten Algorithmus (LMS, XMSS oder SLH-DSA) unterstützt; allgemeine Marketingfloskeln wie „post-quantum ready“ reichen dafür nicht aus.
2. Bei zustandsbehafteten Systemen (LMS, XMSS) sollte sichergestellt werden, dass das HSM die Zustandsverwaltung selbst durchsetzt, anstatt sich darauf zu verlassen, dass ein externes System diese korrekt erfasst.
3. Vergewissern Sie sich, dass der Bootloader, der Aktualisierungsmechanismus oder der Plattformverifizierer, der die Signatur überprüft, tatsächlich den gewählten Algorithmus erkennt; eine korrekt generierte LMS-Signatur ist für einen Verifizierer, der nur ECDSA versteht, nutzlos.
4. Erst wenn sowohl die Unterstützung durch das HSM als auch die Unterstützung durch den Verifizierer bestätigt sind, macht ein Pilotprojekt Sinn.

Überprüfung der Kompatibilität

Dies ist die Einschränkung, die die meisten Algorithmenvergleiche außer Acht lassen. Die Signierung mit LMS, XMSS oder SLH-DSA ist heutzutage nur dann sinnvoll, wenn das Gerät oder die Plattform, die die Signatur prüft, diese auch versteht. Viele bestehende Bootloader und Firmware-Update-Mechanismen wurden für die RSA- oder ECDSA-Verifizierung entwickelt und erkennen Hash-basierte Post-Quanten-Signaturen nicht nativ. Bei neuen Hardware-Designs sollte die Unterstützung für den gewählten Verifizierungsalgorithmus von Anfang an in den Boot-ROM oder das Secure Element integriert werden. Für eine bestehende Geräteflotte sorgt die duale, parallele Signierung (klassisch und Post-Quanten-Algorithmus) dafür, dass ältere Geräte weiterhin funktionieren, während neuere Geräte von einer quantenresistenten Verifizierung profitieren – das gleiche praktische Vorgehen, das auch bei anderen Post-Quanten-Codesignaturen angewendet wird.

Testen und Rollback

Insbesondere bei zustandsbehafteten Systemen müssen die Tests über einen normalen Signaturtest hinausgehen: Es müssen gezielt Szenarien zur Wiederherstellung nach einem Absturz sowie zur Sicherung und Wiederherstellung anhand des Zustandsmanagements des HSM getestet werden, da ein Zustandsreset genau der Fehlermodus ist, der die Sicherheit von LMS und XMSS beeinträchtigt. Sollte ein Test zeigen, dass das gewählte HSM oder die Signaturplattform keinen absturzsicheren Zustand gewährleisten kann, ist es sicherer, den Signaturstrom auf SLH-DSA (kein zu beschädigender Zustand) umzustellen, anstatt ein zustandsbehaftetes System ohne verifizierte Zustandsmanagementgarantie weiter zu betreiben. Da die doppelte Signatur die klassische Signatur unabhängig gültig hält, erfordert die Rücknahme einer Algorithmuswahl keine Änderungen an bereits ausgelieferten Artefakten, sondern nur an der Art und Weise, wie zukünftige Artefakte signiert werden.

Wie Verschlüsselungsberatung helfen kann

Die Wahl zwischen zustandsbehafteter und zustandsloser Signatur und deren sicherer Betrieb erfordern strategische Überlegungen und die Berücksichtigung detaillierter Implementierungsfragen. Genau das ist unser Fachgebiet.

CodeSign Secure , unsere Lösung für die Codesignierung, wurde entwickelt, um Signaturschlüssel zu schützen und kontrollierte Signaturprozesse zu gewährleisten – genau das, was quantensichere Systeme erfordern. Sie bietet Ihnen einen geregelten Signaturprozess für Software, Firmware und andere Artefakte mit den Richtlinien und dem Schlüsselschutz, die beim Umstieg auf LMS, XMSS oder zustandslose Algorithmen entscheidend sind. Bei zustandsbehafteten Systemen, bei denen ein einziger Fehler im Zustand das gesamte Sicherheitsmodell zunichtemachen kann, verhindert die Signatur über ein diszipliniertes, zentrales System anstelle von Ad-hoc-Skripten die Wiederverwendung eines Einmalschlüssels.

Da zustandsbehaftete Verfahren im Wesentlichen hardwaregestütztes Schlüssel- und Zustandsmanagement erfordern, bildet HSM-as-a-Service die natürliche Grundlage dafür. Es isoliert Ihre Signaturschlüssel in einem Hardware-Sicherheitsmodul, sodass der Zustand, auf dem LMS und XMSS basieren, nicht einfach kopiert, aus einem Backup wiederhergestellt oder parallel ausgeführt werden kann – genau jene Fehlermodi, die eine zustandsbehaftete Signatur fälschbar machen.

Die Entscheidung, welcher Algorithmus am besten zu Ihren Geräten, Ihrem Signaturvolumen und Ihren Compliance-Anforderungen passt, ist der Punkt, an dem unsere Post-Quantum-Kryptografie-Beratungsdienste ansetzen. Wir helfen Ihnen, die Vor- und Nachteile zustandsbehafteter bzw. zustandsloser Verfahren unter Berücksichtigung Ihrer tatsächlichen Einschränkungen abzuwägen, gegebenenfalls CNSA 2.0 zu berücksichtigen und einen Migrationsplan für Ihre Signaturinfrastruktur zu erstellen, der zu Ihrem Zeitplan passt.

Wenn Sie die quantensichere Signatur Ihrer Produkte planen oder sich vor Ihrer endgültigen Entscheidung zwischen LMS, XMSS und einem zustandslosen Verfahren entscheiden müssen, kontaktieren Sie uns . Wir unterstützen Sie bei der Auswahl und dem Aufbau der dazugehörigen Infrastruktur.

Fazit

Die Umstellung auf quantensichere Code- und Firmware-Signatur ist einer der wenigen Aspekte des PQC-Übergangs, bei denen die Algorithmen feststehen und der Stichtag naht. SLH-DSA, LMS und XMSS sind allesamt sicher, hashbasiert und quantenresistent. Die Wahl zwischen ihnen hängt letztlich davon ab, ob die Zustandsverwaltung sicher ist und ob es Bestrebungen hin zu einem zustandslosen Design gibt.

Für die meisten Teams sind Compliance und Betrieb die entscheidenden Faktoren. Gilt CNSA 2.0, ist ML-DSA die zustandslose Lösung, und als hashbasierte Optionen stehen LMS und XMSS mit hardwaregestütztem Zustand zur Verfügung. Gilt CNSA 2.0 nicht, ist SLH-DSA eine legitime Möglichkeit, den Aufwand für die Zustandsverwaltung vollständig zu vermeiden, allerdings auf Kosten größerer Signaturen. Beide Wege funktionieren, jedoch nur, wenn die Signaturschlüssel geschützt sind und der Prozess so diszipliniert abläuft, dass ein Einmalschlüssel niemals zweimal verwendet wird.

Firmware, die Sie dieses Jahr signieren, könnte noch lange nach der Markteinführung von Quantencomputern im Einsatz sein und verifiziert werden müssen. Deshalb ist diese Entscheidung dringend und sollte gleich beim ersten Mal richtig getroffen werden.

Häufig gestellte Fragen

Ist SLH-DSA dasselbe wie ML-DSA?

Nein. SLH-DSA (FIPS 205) ist ein zustandsloses, hashbasiertes Signaturverfahren. ML-DSA (FIPS 204) ist ein zustandsloses, gitterbasiertes Signaturverfahren. Beide sind zustandslos und dienen als Signaturalgorithmen, basieren jedoch auf unterschiedlichen mathematischen Annahmen. Nur ML-DSA ist gemäß CNSA 2.0 für nationale Sicherheitssysteme zugelassen.

Kann ich SLH-DSA für die Firmware-Signierung auf einem nationalen Sicherheitssystem verwenden?

Nein. CNSA 2.0 unterstützt SLH-DSA nicht. Für die Signierung von NSS-Software und -Firmware sind LMS, XMSS oder ML-DSA als Optionen zugelassen.

Was passiert, wenn der Zustand eines zustandsbehafteten Schlüssels beschädigt oder wiederverwendet wird?

Wird eine einmalige Komponente eines LMS- oder XMSS-Schlüssels zweimal verwendet, beispielsweise nach einer Backup-Wiederherstellung oder parallelen Signierung, kann ein Angreifer, der beide Signaturen beobachtet, neue fälschen. Aus diesem Grund benötigen zustandsbehaftete Systeme eine hardwaregestützte Zustandsverwaltung und nicht nur eine prozessorientierte Vorgehensweise.

Unterstützen aktuelle Firmware-Verifizierer LMS, XMSS oder SLH-DSA?

Die Unterstützung ist uneinheitlich. Viele bestehende Bootloader und Update-Mechanismen wurden für die RSA- oder ECDSA-Verifizierung entwickelt. Prüfen Sie vor der Implementierung, ob Ihr spezifischer Verifizierer diese unterstützt, und erwägen Sie die parallele Signatur, um die Funktionsfähigkeit älterer Geräte während der Umstellung zu gewährleisten.

Soll ich LMS oder XMSS wählen, wenn mir beide zur Verfügung stehen?

LMS ist die einfachere und schnellere Standardeinstellung und der von der NSA bevorzugte Parametersatz. XMSS verwendet eine Bitmaskenkonstruktion, die von einigen Teams aufgrund ihrer höheren Sicherheit bevorzugt wird, allerdings auf Kosten von mehr Hashing und Speicherbedarf. Für die meisten Signaturvorgänge empfiehlt sich LMS, es sei denn, Sie haben einen bestimmten Grund, die Vorteile von XMSS zu nutzen.