To signaturstandarder fra IETF og NIST konkurrerer om å sikre fastvare, oppstartskjeder og lange forsyningskjeder mot en fremtidig kvantedatamaskin: XMSS (RFC 8391) og LMS/HSS (RFC 8554). Begge er godkjent i NIST SP 800-208 fra oktober 2020, begge bygger på Merkle-trær og hash-funksjoner, og begge krever noe de fleste kryptografiske signaturer ikke krever: at systemet ditt husker nøyaktig hvilke nøkler som allerede er brukt. Forskjellen mellom dem handler ikke om hvem som er “best”, men om hvilke byte-, ytelses- og driftsavveininger som passer et gitt system best. For norske og nordiske virksomheter som signerer fastvare til nettverksutstyr, industrielle styringssystemer eller IoT-enheter, er valget mellom XMSS og LMS i ferd med å bli en praktisk beslutning, ikke bare en akademisk øvelse.
Hva er stateful hash-baserte signaturer?
De fleste kjente signaturalgoritmer, som RSA, ECDSA eller Ed25519, er “stateless”. Du kan signere så mange meldinger du vil med samme private nøkkel, uten å holde styr på noe mellom signeringene. XMSS og LMS bryter med dette mønsteret. De er bygget på engangssignaturer (one-time signatures, OTS) organisert i et Merkle-tre, der hvert blad i treet bare kan brukes til å signere én gang. Signeringsprosessen krever derfor at systemet holder styr på en tilstand, en teller som forteller hvilke blader som allerede er brukt opp.
Fordelen med denne konstruksjonen er at sikkerheten kun hviler på egenskapene til hash-funksjonen (typisk SHA-256), ikke på matematiske antagelser om heltallsfaktorisering eller diskrete logaritmer som kan knekkes av en kvantedatamaskin med Shors algoritme. Det gjør XMSS og LMS til noen av de mest konservative post-kvante signaturvalgene som finnes i dag, i motsetning til gitterbaserte alternativer som ML-DSA. Ulempen er at feil tilstandshåndtering, altså gjenbruk av et allerede brukt blad, kan kompromittere hele signaturens sikkerhet. Det er en type sårbarhet stateless signaturer aldri møter, og det er også grunnen til at NIST SP 800-208 eksplisitt advarer mot bruk av disse skjemaene i miljøer der tilstanden kan klones, tilbakestilles eller kjøres samtidig flere steder.
Begge skjemaene ble standardisert av IETF før NIST ga dem sin offisielle velsignelse: XMSS gjennom RFC 8391 i mai 2018, og LMS gjennom RFC 8554 i april 2019. NIST fulgte opp med SP 800-208, “Recommendation for Stateful Hash-Based Signature Schemes”, publisert i oktober 2020, som godkjenner begge for bruk i føderale systemer under strenge driftsbetingelser.
Den kryptografiske ideen bak begge er langt eldre enn selve RFC-ene. Merkle-trær ble beskrevet av Ralph Merkle allerede i 1979, i samme periode som Leslie Lamport publiserte konseptet med engangssignaturer. Det som gjorde XMSS og LMS praktisk anvendelige nesten fire tiår senere, var forbedrede konstruksjoner som Winternitz-signaturer (som reduserer signaturstørrelsen ved å la hver hash-kjede representere flere biter om gangen) og effektive traverseringsalgoritmer som gjør det mulig å generere autentiseringsstier uten å holde hele treet i minnet samtidig. Denne historiske konteksten er ikke bare en kuriositet, den er en del av grunnen til at NIST og IETF stoler på disse konstruksjonene: sikkerhetsbeviset hviler på over 45 år med kryptoanalyse av hash-funksjoner og Merkle-trestrukturer, betydelig lenger enn de gitterbaserte problemene som ligger til grunn for nyere post-kvante-algoritmer som ML-KEM og ML-DSA.
XMSS forklart: Slik fungerer RFC 8391
XMSS (eXtended Merkle Signature Scheme) ble utviklet ved TU Eindhoven, TU Darmstadt og flere andre akademiske institusjoner, og er dokumentert i RFC 8391. Et enkelt XMSS-tre har en høyde h, og kan signere opptil 2^h meldinger. Hvert blad i treet inneholder en WOTS+-nøkkel (Winternitz One-Time Signature Plus), som er selve engangssignaturen. Når du signerer en melding med XMSS, bruker du én WOTS+-nøkkel og legger ved en autentiseringssti opp gjennom treet slik at mottakeren kan verifisere at nøkkelen faktisk hører til den offentlige roten.
For store nøkkelmengder tilbyr RFC 8391 også XMSS^MT (multi-tree), der treet deles i flere lag. Dette gjør det mulig å nå svært høye signaturbudsjetter, for eksempel opptil 2^60 signaturer i en konfigurasjon som XMSSMT-SHA2_60/3_256, uten at ett enkelt tre blir uhåndterlig stort å generere. Prisen er et mer komplekst signaturformat: hver signatur inneholder nå flere reduserte XMSS-signaturer, én for hvert lag i hierarkiet.
WOTS+ selv fungerer ved å dele en meldingshash opp i et sett med tallverdier, og bygge én hash-kjede per verdi. Signereren avslører et punkt et stykke inn i hver kjede, avhengig av verdien som skal signeres, mens verifisereren fullfører kjeden frem til et kjent sluttpunkt og sammenligner. En innebygd sjekksum sørger for at en angriper ikke kan forfalske en gyldig signatur ved å bare fortsette å hashe videre i kjedene. Denne konstruksjonen er effektiv, men den er også hovedgrunnen til at XMSS-signaturer blir større enn LMS-signaturer: WOTS+ krever flere kjeder og en lengre samlet representasjon enn LM-OTS-formatet som LMS bruker for samme sikkerhetsnivå.
XMSS sin offentlige nøkkel er liten og fast i størrelse uavhengig av trehøyde: 4 + 2n byte i RFC-kodet format, som for n=32 (SHA-256, 256-bit sikkerhetsnivå) blir 68 byte. Signaturstørrelsen derimot vokser med trehøyden, fordi hver ekstra nivå legger til én hash-verdi i autentiseringsstien. Det er nettopp denne veksten som gjør XMSS relativt tungt sammenlignet med LMS ved samme signaturkapasitet, noe vi går gjennom i detalj lenger ned.
LMS og HSS forklart: Slik fungerer RFC 8554
LMS (Leighton-Micali Signatures) er dokumentert i RFC 8554, forfattet blant annet av D. McGrew og S. Fluhrer fra Cisco Systems. Konstruksjonen ligner XMSS: et Merkle-tre av høyde h, med LM-OTS (Leighton-Micali One-Time Signature) i hvert blad. Den viktigste tekniske forskjellen ligger i hvordan engangssignaturene og selve treet er kodet, noe som gir LMS et enklere og mer kompakt signaturformat enn XMSS ved samme trehøyde.
Der XMSS håndterer store signaturbudsjetter med XMSS^MT, bruker LMS et eget hierarkisk lag kalt HSS (Hierarchical Signature System). En HSS-struktur med L nivåer kan autentisere om lag 2^(h×L) engangssignaturer totalt, avhengig av nøyaktig konfigurasjon. En HSS-signatur består av den nederste LMS-signaturen pluss, for hvert ekstra nivå, den offentlige nøkkelen og signaturen som autentiserer nivået over. Det gjør HSS-signaturer større enn en enkelt LMS-signatur, men fortsatt organisert på en måte som lar systemer skalere opp signeringskapasiteten uten å måtte bygge ett enormt tre på forhånd.
RFC 8554 definerer fem standard trehøyder for SHA-256 med m=32: H5, H10, H15, H20 og H25, tilsvarende maksimalt fra 32 til over 33 millioner signaturer per tre. Den offentlige LMS-nøkkelen er 56 byte (type-identifikator, LM-OTS-type, en 16-byte identifikator og en 32-byte Merkle-rot), mens en HSS-offentlig nøkkel legger til 4 byte for nivåtall, totalt 60 byte.
Et av forfatterteamets medlemmer bak RFC 8554, S. Fluhrer, er tilknyttet Cisco Systems, noe som gjenspeiles i hvordan spesifikasjonen er skrevet: den legger stor vekt på praktisk implementering i nettverksutstyr og innebygde system, ikke bare det teoretiske sikkerhetsbeviset. Det er også derfor RFC 8554 inneholder detaljerte anbefalinger om hvordan et system bør validere at en gitt LMS-offentlig nøkkel faktisk tilhører riktig privat nøkkeltilstand før signering starter, en kontroll som er mindre fremtredende i XMSS-spesifikasjonen fra den mer akademisk orienterte TU Eindhoven/TU Darmstadt-gruppen.
Spesifikasjonstabell: XMSS mot LMS side om side
Tabellen under samler kjernedataene fra RFC 8391, RFC 8554 og NIST SP 800-208, slik at du kan sammenligne de to standardene punkt for punkt.
| Egenskap | XMSS | LMS / HSS |
|---|---|---|
| Standard | RFC 8391 (IETF, mai 2018) | RFC 8554 (IETF, april 2019) |
| NIST-anbefaling | SP 800-208 (okt. 2020) | SP 800-208 (okt. 2020) |
| Engangssignatur | WOTS+ (Winternitz+) | LM-OTS (Leighton-Micali) |
| Hierarki for store volum | XMSS^MT (multi-tre) | HSS (Hierarchical Signature System) |
| Offentlig nøkkel (n=32, RFC-format) | 68 byte | 56 byte (LMS) / 60 byte (HSS) |
| Signatur, tre med 2^10 blader | 2 500 byte | 1 456 byte |
| Signatur, tre med 2^16 blader | 2 692 byte | ikke standard høyde |
| Signatur, tre med 2^20 blader | 2 820 byte | 1 776 byte |
| Standard trehøyder | 10, 16, 20 (samt XMSS^MT-varianter) | 5, 10, 15, 20, 25 |
| Nøkkelgenerering | O(2^h) hash-operasjoner | O(2^h) hash-operasjoner per tre |
| Krever tilstandshåndtering | Ja, kritisk | Ja, kritisk |
| Underliggende sikkerhetsantagelse | Hash-funksjonens motstandsdyktighet | Hash-funksjonens motstandsdyktighet |
| Post-kvante sikkerhetsnivå (n=32) | Om lag 128-bit | Om lag 128-bit |
Legg merke til at LMS ved samme trehøyde konsekvent gir mindre signaturer enn XMSS. Det skyldes at LM-OTS-formatet og LMS-kodingen har færre faste felt og en enklere autentiseringsstruktur enn WOTS+ og XMSS-formatet, ikke at LMS er “svakere”. Begge oppnår samme post-kvante sikkerhetsnivå ved n=32.
Signaturstørrelse i praksis: Byte for byte
Signaturstørrelsen er det som oftest avgjør valget i praksis, spesielt i fastvare der hver kilobyte flash-lagring og hver byte som må overføres over et begrenset radiogrensesnitt koster noe. RFC 8391 definerer XMSS-signaturlengden som 4 + n + (len + h) × n byte, der n=32 og len=67 for WOTS+ med SHA-256. For et tre med høyde 20 gir dette 2 820 byte. RFC 8554 definerer den tilsvarende LMS-signaturlengden som 4 + (4 + n×(p+1)) + 4 + h×m byte, der n=32 og p=34 (W=8). For samme høyde, 20, gir dette 1 776 byte, om lag 37 prosent mindre enn XMSS ved identisk signaturkapasitet på 2^20 (1 048 576) signaturer.
Forskjellen blir enda tydeligere ved lavere trehøyder. Ved høyde 10, som gir 1 024 signaturer, krever XMSS 2 500 byte per signatur mot 1 456 byte for LMS, en reduksjon på nesten 42 prosent. Det europeiske standardiseringsorganet ETSI har i sin rapport TR 103 692 pekt på lignende mønstre: WOTS+-baserte signaturer under RFC 8391 lander på rundt 2 144 byte for enkeltparametersettet som er obligatorisk i spesifikasjonen, og ETSI bemerker at det kreves 23 584 byte for å lagre 11 slike signaturer i et sertifikatformat, et konkret eksempel på hvor fort disse signaturene spiser opp lagringsplass sammenlignet med klassiske RSA- eller ECDSA-signaturer på noen hundre byte.
For et system som bruker HSS med flere nivåer, må du legge til én ekstra LMS-offentlig nøkkel (56 byte) og én ekstra LMS-signatur for hvert nivå over det nederste. En HSS-hierarki med to nivåer av høyde 10 vil dermed ha en total signaturstørrelse på om lag 1 456 + 1 456 + 56 = 2 968 byte, fortsatt mindre enn en tilsvarende XMSS^MT-konfigurasjon med sammenlignbar kapasitet.
Ytelse: Nøkkelgenerering og signeringshastighet
Verken RFC 8391 eller RFC 8554 spesifiserer en universell tidsbenchmark for nøkkelgenerering, siden dette avhenger sterkt av maskinvare, hash-akselerasjon og implementasjon. Det finnes likevel tre kilder som gir et konsistent bilde av de relative kostnadene. Open Quantum Safe-prosjektets liboqs-bibliotek publiserer måletall for begge familiene og bekrefter signaturstørrelsene fra RFC-ene direkte i sin implementasjon (2 500 byte for XMSS-SHA2_10_256, stigende til 2 820 byte for XMSS-SHA2_20_256). Et akademisk arbeid fra AfricaCrypt 2020, “LMS vs XMSS: Comparison of Stateful Hash-Based Signature Schemes on ARM Cortex-M4” av Campos, Kohlstadt, Reith og Stöttinger, sammenligner de to skjemaene direkte på en ressursbegrenset ARM Cortex-M4-mikrokontroller, en plattform som er representativ for nettopp fastvaresignering i innebygde systemer. Red Hats tekniske gjennomgang av hash-baserte signaturer bekrefter samme mønster: LMS/HSS anbefales ofte der maskinvaren ikke kan klones, nettopp fordi den kompakte konstruksjonen gjør det enklere å håndheve tilstand i beskyttet maskinvare.
Begge skjemaenes nøkkelgenerering skalerer asymptotisk som O(2^h), fordi hele treet med 2^h blader må bygges før den offentlige roten kan publiseres. For et tre av høyde 20 betyr det over en million hash-beregninger bare for å generere ett nøkkelpar, noe som gjør nøkkelgenerering til en engangskostnad som typisk gjøres offline eller under produksjon, ikke noe som gjentas ved hver signering. RFC 8391 beskriver optimaliserte traverseringsstrategier (BDS-algoritmen) som reduserer minnebruken under signering, men dette endrer ikke den grunnleggende oppbyggingskostnaden for selve treet.
I praksis rapporterer flere implementasjoner at LMS signerer og verifiserer raskere enn XMSS ved sammenlignbare parametere, fordi LM-OTS bruker færre hash-kjeder og et enklere sjekksum-skjema enn WOTS+. Forskjellen er sjelden dramatisk (typisk innenfor samme størrelsesorden), men den forsterker det samme mønsteret som signaturstørrelsene viser: LMS er gjennomgående det slankere alternativet av de to.
Minnebruk under signering er en annen praktisk forskjell som ofte overses. Et naivt XMSS-signeringsoppsett må ha rask tilgang til hele autentiseringsstien for gjeldende blad, noe som i verste fall betyr å holde store deler av treet tilgjengelig eller regenerere det på farten. RFC 8391 løser dette med BDS-algoritmen (Buchmann-Dahmen-Szydlo), som fordeler beregningskostnaden for fremtidige autentiseringsstier utover flere signeringsoperasjoner i stedet for å gjøre alt arbeidet i det øyeblikket en signatur faktisk trengs. LMS-implementasjoner løser samme problem på en litt enklere måte, siden LM-OTS-strukturen krever færre mellomlagrede verdier per steg. For et innebygd system med noen titalls kilobyte RAM kan denne forskjellen i praksis avgjøre om et gitt skjema i det hele tatt lar seg implementere innenfor tilgjengelig minnebudsjett, uavhengig av hvor rask selve CPU-en er.
Verifiseringshastighet og ressursbruk
Verifisering er ofte den viktigste operasjonen å optimalisere for fastvaresignering, fordi den skjer på hver eneste enhet, hver gang en oppdatering lastes ned, mens signering typisk skjer én gang sentralt hos utgiveren. Både XMSS- og LMS-verifisering krever at man regner seg oppover gjennom autentiseringsstien i Merkle-treet og sammenligner den beregnede roten med den kjente offentlige nøkkelen. Arbeidsmengden er tilnærmet lineær i trehøyden for begge, men med ulik konstantfaktor: XMSS-verifisering må også fullføre en WOTS+-kjedeberegning, mens LMS-verifisering fullfører en LM-OTS-beregning.
For enheter med begrenset CPU, som mikrokontrollere i IoT-utstyr eller nettverksbrytere, er den lavere konstante kostnaden ved LMS-verifisering en reell fordel. Samtidig er begge skjemaene raske nok til å verifisere i løpet av millisekunder på moderne prosessorer med SHA-256-akselerasjon i maskinvare, noe de fleste ARM Cortex-A- og x86-baserte systemer i dag har innebygd. Flaskehalsen ligger sjeldnere i selve CPU-tiden og oftere i signaturens størrelse: en 2 820 byte stor XMSS-signatur må lastes ned, mellomlagres og parses før verifiseringen i det hele tatt kan starte, noe som er en betydelig forskjell fra en 64-byte Ed25519-signatur på et system med treg eller kostbar dataoverføring.
Den store risikoen: Statlig nøkkelhåndtering
Det som skiller XMSS og LMS fra nesten alle andre moderne signaturalgoritmer, er ikke byte-tall, men driftsrisikoen. Fordi hvert blad i Merkle-treet kun kan brukes én gang, må systemet som holder den private nøkkelen aldri signere to ulike meldinger med samme blad. Gjør det det, kollapser sikkerhetsgarantien for det gjenbrukte bladet, og i verste fall kan en angriper utlede nok informasjon til å forfalske fremtidige signaturer.
NIST SP 800-208 er eksplisitt på at dette ikke er et hypotetisk problem, men den sentrale operasjonelle betingelsen for trygg bruk. Følgende hendelser kan alle føre til tilstandsgjenbruk hvis de ikke håndteres riktig:
- Gjenoppretting fra en virtuell maskin-øyeblikksbilde (snapshot) tatt før en signering ble committet
- Gjenoppretting fra en databasesikkerhetskopi som ikke inkluderer siste tilstandsoppdatering
- Aktiv-aktiv signeringsinfrastruktur uten delt, atomær tilstand mellom noder
- HSM-failover til en node med utdatert tilstand
- Duplisering av containere eller gyldne images som inneholder samme nøkkeltilstand
- Strømbrudd mellom signaturgenerering og tilstands-commit
- Race conditions ved samtidig signering fra flere prosesser
Dette er grunnen til at NIST anbefaler XMSS og LMS primært for miljøer der signeringsinfrastrukturen kan kontrolleres strengt, typisk sentraliserte fastvare- og oppdateringssystemer, og fraråder bruk der maskinvaren kan klones eller der tilstanden ikke kan beskyttes mot tilbakerulling. En praktisk konsekvens er at organisasjoner som velger XMSS eller LMS, må bygge egen infrastruktur for transaksjonell eller maskinvarestøttet tilstandsoppdatering, katastrofegjenoppretting som aldri kan gjenopprette en allerede brukt tilstand, og et klart skille mellom hvem som har signeringsmyndighet og hvem som har tilgang til sikkerhetskopier av nøkkeltilstanden.
Mange organisasjoner løser dette ved å plassere selve signeringsoperasjonen inne i en HSM som håndhever tilstanden i maskinvare, slik at selv en operatør med administratortilgang til det omkringliggende systemet ikke kan tvinge frem gjenbruk av et brukt blad. Andre bygger et eget signeringstjenestelag foran HSM-en, med en append-only logg over hver signaturoperasjon, slik at ethvert forsøk på å signere med en allerede brukt indeks blir avvist før det når selve nøkkelmaterialet. Uansett arkitektur er poenget det samme: tilstandshåndtering må behandles som en sikkerhetskritisk komponent på linje med selve den private nøkkelen, ikke som et implementasjonsdetalj som kan ettermonteres.
NIST SP 800-208 og standardiseringsstatus
NIST publiserte SP 800-208, “Recommendation for Stateful Hash-Based Signature Schemes”, i oktober 2020. Dokumentet dekker eksplisitt LMS/HSS fra RFC 8554 og XMSS/XMSS^MT fra RFC 8391, og er separat fra NISTs hovedløp for post-kvante signaturer som endte med ML-DSA (FIPS 204) og SLH-DSA (FIPS 205) i august 2024. Det betyr at XMSS og LMS allerede har vært godkjent i seks år, lenge før de gitterbaserte og stateless hash-baserte alternativene ble ferdigstilt, noe som har gitt dem et forsprang i sektorer som krever langsiktig, konservativ sikkerhet, som fastvaresignering for kritisk infrastruktur.
IETFs LAMPS-arbeidsgruppe fortsetter å bygge ut støtteinfrastruktur rundt LMS og HSS. RFC 8778 beskriver bruk av HSS/LMS i CMS-signaturer (Cryptographic Message Syntax), og videreførte utkast som draft-ietf-lamps-rfc8708bis definerer algoritme-identifikatorer for bruk av HSS/LMS i X.509-sertifikater, med støtte for trehøydene 5, 10, 15, 20 og 25 fra RFC 8554. Et tilsvarende utkast, draft-ietf-lamps-x509-shbs, dekker algoritme-identifikatorer for både HSS og XMSS i sertifikater. Verken NIST eller IETF har publisert noen formell utfasing av XMSS eller LMS per 2026. Det som derimot er dokumentert gjentatte ganger i standardene, er advarselen om tilstandsgjenbruk beskrevet i forrige avsnitt, som forblir det definerende operasjonelle kravet for begge skjemaene.
XMSS og LMS mot stateless post-kvante-signaturer
XMSS og LMS er ikke de eneste post-kvante-signaturene NIST har godkjent. I august 2024 ferdigstilte NIST også ML-DSA (FIPS 204) og SLH-DSA (FIPS 205), begge stateless, i tillegg til Falcon-baserte konstruksjoner som senere ble til FN-DSA. Forskjellen mellom de to familiene er fundamental, ikke bare en detalj i implementasjonen. Stateless signaturer som ML-DSA (gitterbasert) og Falcon krever ingen tilstandshåndtering i det hele tatt: samme private nøkkel kan brukes til å signere et ubegrenset antall meldinger uten risiko for gjenbruk av en allerede brukt engangsnøkkel. SLH-DSA er også stateless, men bygger fortsatt på hash-funksjoner i bunn, på samme måte som XMSS og LMS, bare uten kravet om å huske hvilke blader som er brukt.
Dette gjør valget mellom stateful og stateless i praksis til et spørsmål om hvor mye du stoler på infrastrukturen din. Trenger systemet ditt en generell signaturløsning uten spesialbygd tilstandshåndtering, som API-er, sertifikater for sluttbrukere eller applikasjoner med uforutsigbar signeringsfrekvens, er ML-DSA eller SLH-DSA som regel et tryggere utgangspunkt, nettopp fordi de fjerner hele klassen av feil beskrevet i forrige avsnitt. Har du derimot et avgrenset, sentralisert signeringsscenario med et kjent øvre tak på antall signaturer, som fastvareutgivelse fra én produsent, er den enkle konstruksjonen og de mindre signaturene til LMS ofte et bedre praktisk valg enn den relativt store SLH-DSA-signaturen. Vår gjennomgang av ML-DSA mot SLH-DSA går nærmere inn på denne avveiningen for stateless alternativer, mens denne artikkelen fokuserer på de to stateful skjemaene NIST har godkjent lengst.
Internasjonal tidslinje: Hvorfor dette haster for eksportbedrifter
Selv om XMSS og LMS har vært NIST-godkjent siden 2020, er det den bredere post-kvante-migreringen som nå driver frem konkrete beslutninger om fastvaresignering. NIST har signalisert at kvantesårbare algoritmer i standardene skal fases ut innen 2035, med høyrisikosystemer tidligere. Storbritannias National Cyber Security Centre har publisert en tilsvarende tidslinje som også peker mot 2035 som mål for fullført migrering, med ML-KEM fremhevet som en av de primære algoritmene organisasjoner bør planlegge rundt. I USA krever et direktiv fra 2026 at føderale etater migrerer nøkkelutveksling innen utgangen av 2030 og digitale signaturer innen utgangen av 2031.
For norske og nordiske selskaper som leverer nettverksutstyr, industrielt automasjonsutstyr eller programvare til kunder i USA, EU eller offentlig sektor, betyr dette at spørsmålet om XMSS eller LMS sjelden er isolert til egen infrastruktur. Kunder i regulerte sektorer, spesielt forsyningskjeder knyttet til amerikansk offentlig sektor eller kritisk infrastruktur i EU, kan komme til å stille konkrete krav om at fastvare skal kunne signeres med et NIST-godkjent post-kvante-skjema innen bestemte frister. Siden XMSS og LMS er de eneste post-kvante-signaturene som har vært produksjonsklare siden 2020, mens ML-DSA og SLH-DSA først ble ferdigstilt i 2024, har flere leverandører av nettverks- og industriutstyr allerede rukket å bygge og teste stateful hash-baserte signaturløp i produkter som er i drift i dag. Det gir dem et konkret forsprang sammenlignet med å vente på at gitterbaserte alternativer modnes ytterligere i verktøykjeder og sertifiseringsprogrammer.
Det er verdt å skille tydelig mellom nøkkelutveksling og digital signering i denne sammenhengen, siden de to ofte migreres etter ulike tidsplaner og med ulike algoritmer. Nøkkelutveksling, altså å etablere en delt hemmelighet mellom to parter, håndteres i den post-kvante verdenen typisk av ML-KEM, ofte kjørt i hybridmodus med klassiske kurver, mens digitale signaturer for autentisering og integritet er der XMSS, LMS, ML-DSA og SLH-DSA hører hjemme. En organisasjon som migrerer TLS-trafikken sin til hybrid ML-KEM, løser dermed ikke automatisk fastvaresigneringsproblemet, og omvendt. For en helhetlig oversikt over hvordan de ulike post-kvante-familiene henger sammen, se vår oversiktsside for kryptografi.
Kostnader ved implementering
XMSS og LMS er åpne standarder uten lisenskostnad i seg selv, men den reelle kostnaden ligger i infrastrukturen som kreves for trygg tilstandshåndtering, ofte en maskinvaresikkerhetsmodul (HSM). Tabellen under viser offentlig kjent prising for de mest brukte alternativene.
| Løsning | Type | Pris |
|---|---|---|
| liboqs (Open Quantum Safe) | Åpen kildekode-bibliotek | Gratis (MIT-lisens), ikke FIPS-validert produksjonsklar HSM |
| Bouncy Castle | Åpen kildekode-bibliotek | Gratis under egen åpen lisens |
| wolfSSL | Kryptografibibliotek | Dobbel lisensiering; kommersiell bruk kan kreve betalt lisens |
| AWS CloudHSM | Skybasert HSM | Fra 1,45-2,08 USD per HSM-time avhengig av region (US East: 1,60 USD/time) |
| AWS KMS (custom key store) | Skybasert nøkkeladministrasjon | 1 USD per nøkkel per måned, pluss 0,03 USD per 10 000 API-kall |
| Thales Luna HSM | Fysisk/enterprise HSM | Kun tilbudsbasert prising, ikke offentlig listepris |
| Utimaco HSM | Fysisk/enterprise HSM | Kun tilbudsbasert prising, ikke offentlig listepris |
| Entrust nShield | Fysisk/enterprise HSM | Kun tilbudsbasert prising, ikke offentlig listepris |
For en kontinuerlig kjørende HSM-klynge med to noder i AWS US East, lander kostnaden på rundt 2 336 USD per 730-timers måned, kun for selve HSM-timene, ifølge AWS’ offentlige prisside. Legg til at algoritme- og SDK-støtte for LMS/XMSS må verifiseres mot nøyaktig fastvareversjon og sertifiseringskonfigurasjon hos enterprise-leverandører som Thales, Utimaco og Entrust, siden det å støtte post-kvante algoritmer generelt ikke automatisk betyr at et gitt produkt støtter nettopp LMS eller XMSS. Den reelle kostnadsposten for de fleste organisasjoner er derfor ikke lisensavgiften for selve algoritmen, men ingeniørarbeidet med å bygge en tilstandshåndteringsarkitektur som aldri tillater gjenbruk av et brukt blad.
Skybaserte HSM-er som AWS CloudHSM er attraktive for organisasjoner som allerede driver infrastruktur i skyen, siden de slipper å anskaffe og vedlikeholde fysisk maskinvare selv. Men for fastvaresignering på tvers av en hel produktlevetid, ofte 10-20 år for nettverks- og industriutstyr, må kostnadsbildet også inkludere hvor lenge leverandøren forplikter seg til å drifte og støtte den aktuelle HSM-tjenesten. Et alternativ mange velger for langsiktige signeringsnøkler er en dedikert, offline signeringsserver med fysisk HSM, der selve signeringsoperasjonen gjøres sjeldent og under streng tilgangskontroll, mens verifiseringsnøklene distribueres bredt til alle enheter som skal validere fastvaren. Denne modellen reduserer eksponeringen for tilstandsfeil betydelig, siden antallet steder der den private nøkkelen faktisk brukes til signering, holdes lavt og godt overvåket.
5 virkelige brukstilfeller for stateful signaturer
XMSS og LMS er ikke ment som erstatning for TLS-sertifikater eller vanlig e-postsignering. De passer best der antallet signaturer kan avgrenses på forhånd og signeringsmiljøet kan kontrolleres tett. Fellesnevneren for alle brukstilfellene under er at den som utsteder signaturer, sitter med full kontroll over infrastrukturen, mens den som verifiserer, ofte er en enhet med begrensede ressurser som må stole blindt på at utstederen har håndtert tilstanden riktig. Her er fem konkrete kategorier der dette gjelder:
- Fastvaresignering for nettverksutstyr. Rutere, svitsjer og annet nettverksutstyr mottar et begrenset antall fastvareoppdateringer over produktets levetid, typisk noen titalls til noen hundre. Det passer godt med trehøyder som H10 eller H15, der signaturstørrelsen holdes lav samtidig som signaturbudsjettet dekker hele produktlevetiden.
- Sikker oppstart (secure boot) for IoT- og innebyggede enheter. ARM Cortex-M-baserte mikrokontrollere, som i den akademiske AfricaCrypt-studien nevnt over, har begrenset RAM og flash, noe som gjør LMS sin kompakte signaturstørrelse spesielt relevant der båndbredde og lagringsplass er trange ressurser.
- Programvareoppdateringer via The Update Framework (TUF). Et forskningsarbeid publisert i IEEE Security & Privacy (2025/2026) undersøker hvordan TUF kan kombineres med stateful hash-baserte signaturer nettopp for å håndtere nøkkellevetid og beskytte mot kompromitterte oppdateringskanaler.
- Sertifikatbaserte hierarkier via X.509 og CMS. IETFs LAMPS-arbeidsgruppe standardiserer bruk av HSS/LMS og XMSS i sertifikater (draft-ietf-lamps-x509-shbs) og i signerte meldinger gjennom RFC 8778, som gir organisasjoner en vei til å bygge egne PKI-hierarkier med post-kvante signaturer i dag, uten å vente på fulle CA/Browser Forum-profiler for ML-DSA.
- Trusselmodellering for langsiktige signaturer i kritisk infrastruktur. Systemer med driftstid på 15-25 år, som industrielle styringssystemer og annen operasjonell teknologi, må signere firmware som skal forbli verifiserbar lenge etter at dagens klassiske algoritmer er sårbare for en kvantedatamaskin. Her er den konservative hash-baserte sikkerhetsantagelsen i XMSS og LMS ofte mer attraktiv enn nyere gitterbaserte konstruksjoner.
Migreringsguide: Fra RSA/ECDSA til XMSS eller LMS
Å bytte fra en stateless algoritme som RSA eller ECDSA til XMSS eller LMS er en arkitekturendring, ikke en biblioteksoppdatering. Slik ser en realistisk migreringsprosess ut:
- Kartlegg signeringsvolumet. Tell hvor mange signaturer systemet realistisk vil trenge over produktets levetid. Dette bestemmer nødvendig trehøyde, og dermed signaturstørrelse.
- Velg mellom enkelt-tre og hierarki. Er signeringsvolumet lavt og forutsigbart, holder et enkelt XMSS- eller LMS-tre. Ved høyt eller uforutsigbart volum, bruk XMSS^MT eller HSS for å unngå å måtte bygge ett enormt tre på forhånd.
- Design tilstandslagringen først, ikke sist. Bestem hvor tilstanden lagres (HSM, sikret database, signert logg), hvordan den oppdateres atomært, og hvordan katastrofegjenoppretting garantert aldri kan gå tilbake til en brukt tilstand.
- Test mot RFC-vektorer. Bruk offisielle testvektorer fra RFC 8391 og RFC 8554, eller referanseimplementasjoner som liboqs eller Bouncy Castle, for å verifisere at signatur- og nøkkelstørrelser stemmer nøyaktig med spesifikasjonen før produksjonsutrulling.
- Bygg inn overvåking av gjenstående signaturbudsjett. Sett opp varsling lenge før treet går tomt for blader, slik at nøkkelrullering kan planlegges uten at systemet står uten gyldig signeringsnøkkel.
- Planlegg sertifikat- og fastvarestørrelse på nytt. Signaturer på 1-3 kilobyte er dramatisk større enn RSA- eller ECDSA-signaturer på noen hundre byte. Kontroller boot-ROM-grenser, OTA-pakkestørrelser og sertifikatkjeder tidlig, ikke etter at migreringen er i produksjon.
- Hold klassisk signatur som overgangslag. Mange organisasjoner kjører hybrid signering, der både en klassisk og en post-kvante signatur følger med samme fastvarepakke i en overgangsperiode, for å unngå brudd på kompatibilitet med eldre verifiseringsklienter.
Fordeler og ulemper
XMSS, fordeler:
- Moden spesifikasjon med lang akademisk analysehistorikk
- Fleksibelt multi-tre-hierarki (XMSS^MT) for svært høye signaturvolum
- Bred implementasjonsstøtte, inkludert liboqs og flere HSM-plattformer
XMSS, ulemper:
- Større signaturer enn LMS ved samme trehøyde (opptil 61 % større ved H10)
- Mer komplekst signaturformat med WOTS+-kjeder
- Krever samme strenge tilstandsdisiplin som LMS, uten å være mindre
LMS/HSS, fordeler:
- Konsekvent mindre signaturer enn XMSS ved sammenlignbar kapasitet
- Enklere LM-OTS-konstruksjon, ofte raskere i praksis på ressursbegrenset maskinvare
- Sterk standardiseringsmomentum i IETF LAMPS for sertifikater og CMS
- Direkte tilknytning til Cisco-medforfattere i RFC 8554, som gjenspeiler reell interesse fra nettverksindustrien
LMS/HSS, ulemper:
- Færre standard trehøyder å velge mellom enn XMSS
- HSS-hierarkier legger til ekstra offentlige nøkler og signaturer per nivå
- Samme kritiske krav til tilstandshåndtering som XMSS, uten unntak
Verdikt: Hvilken bør du velge?
Basert på tallene fra RFC 8391, RFC 8554 og NIST SP 800-208, er svaret ikke at den ene algoritmen er universelt bedre, men at de løser litt ulike versjoner av samme problem. Trenger du minst mulig signaturstørrelse, og kan du leve med færre standardiserte trehøyder, er LMS/HSS det tekniske vinnervalget: 1 944 byte mot 2 820 byte ved høyde 20, og 984 byte mot 2 500 byte ved høyde 10. Det er en forskjell som teller direkte på flash-forbruk, nettverksoverføring og batteriforbruk i innebygde systemer.
Trenger du derimot maksimal fleksibilitet i hvordan signeringshierarkiet bygges opp, spesielt ved svært høye eller uforutsigbare signaturvolum over lang tid, gir XMSS^MT en godt utprøvd vei dit, med et bredt økosystem av akademisk analyse bak seg. Uansett hvilket skjema du velger, er den avgjørende faktoren ikke byte-tallene i tabellen over, men om organisasjonen din faktisk klarer å bygge en tilstandshåndteringsarkitektur som aldri, under noen omstendighet, gjenbruker et brukt blad i treet. Det er der de fleste reelle implementasjonsfeil med stateful hash-baserte signaturer oppstår, ikke i selve matematikken.
Ofte stilte spørsmål
Er XMSS og LMS kvantesikre?
Ja. Begge bygger utelukkende på hash-funksjoners sikkerhetsegenskaper, ikke på faktorisering eller diskrete logaritmer, og regnes derfor som motstandsdyktige mot kjente kvantealgoritmer som Shors algoritme ved n=32 (256-bit hash, om lag 128-bit post-kvante sikkerhetsnivå).
Hva betyr det at en signatur er “stateful”?
Det betyr at systemet må huske hvilke engangsnøkler (blader i Merkle-treet) som allerede er brukt til signering, og aldri bruke samme blad to ganger. Gjenbruk kan kompromittere signaturens sikkerhet.
Kan jeg bruke XMSS eller LMS til TLS-sertifikater på et vanlig nettsted?
I praksis nei. Standard nettleserstøtte og CA/Browser Forum-baseline mangler bred støtte for disse skjemaene i offentlig TLS per 2026, og den strenge tilstandshåndteringen passer dårlig med hvordan de fleste webservere er driftet. De brukes primært til fastvare-, sertifikat- og oppdateringssignering i mer kontrollerte miljøer.
Hva skjer hvis jeg går tom for signaturer i treet?
Du kan rett og slett ikke signere flere meldinger med det nøkkelparet. Systemer må derfor overvåke gjenstående budsjett og rullere til et nytt nøkkelpar (eller neste nivå i et HSS-hierarki) i god tid før treet tømmes.
Er LMS alltid mindre enn XMSS?
Ved sammenlignbare trehøyder og n=32, ja. RFC-formlene viser konsekvent mindre signaturer for LMS: 984 byte mot 2 500 byte ved høyde 10, og 1 944 byte mot 2 820 byte ved høyde 20.
Hvordan forholder XMSS og LMS seg til ML-DSA og SLH-DSA?
ML-DSA (FIPS 204) og SLH-DSA (FIPS 205), ferdigstilt av NIST i august 2024, er stateless post-kvante signaturer og krever ikke tilstandshåndtering. Se vår sammenligning av ML-DSA mot SLH-DSA for detaljer. XMSS og LMS forblir aktuelle der den ekstra tilstandsdisiplinen er akseptabel til gjengjeld for en mer konservativ, lenge etablert sikkerhetsantagelse.
Bruker Cisco LMS i produkter?
To av forfatterne bak RFC 8554 er tilknyttet Cisco Systems, noe som reflekterer selskapets direkte involvering i standardiseringsarbeidet rundt LMS. Konkrete, navngitte produktimplementasjoner er ikke dokumentert i de offentlige standardene selv, og bør verifiseres mot Ciscos egne sikkerhetsdokumenter før man siterer det som et produkteksempel.
Må jeg velge mellom XMSS og LMS for alltid, eller kan jeg bytte senere?
Du kan bytte skjema ved neste nøkkelrullering, men det krever ny nøkkelgenerering og distribusjon av en ny offentlig nøkkel eller sertifikatkjede. De to skjemaene er ikke direkte interoperable på signaturnivå, så et bytte er i praksis en ny migrering, ikke en konfigurasjonsendring.
