NIST har allerede bestemt at RSA og elliptisk kurve-kryptografi må erstattes før kvantedatamaskiner blir kraftige nok til å knekke dem. To av signaturstandardene som skal ta over er bygget på helt ulike prinsipper: SLH-DSA (tidligere kjent som SPHINCS+) og Falcon, som får det offisielle navnet FN-DSA når standardiseringen er ferdig. Den ene er allerede en ferdig føderal standard. Den andre er fortsatt under offentlig gjennomgang. Denne artikkelen går gjennom forskjellene i tall, ikke bare i teori: signaturstørrelse, signeringstid, standardiseringsstatus og hva det faktisk koster å bruke hver av dem i produksjon.

Kort oppsummert: SLH-DSA (FIPS 205) ble ferdigstilt av NIST 13. august 2024, mens Falcon, som blir til FN-DSA under FIPS 206, fortsatt er et utkast per september 2026. Falcon produserer en signatur på 666 byte i sin minste variant, mens den minste SLH-DSA-signaturen veier 7.856 byte, over elleve ganger så mye. Til gjengjeld er SLH-DSA bygget på en matematisk antagelse (sikkerheten til hash-funksjoner) som de fleste kryptografer anser som mer konservativ enn gitterproblemene Falcon hviler på.

Hvorfor må digitale signaturer byttes ut nå?

Trusselen bak hele denne overgangen kalles harvest-now-decrypt-later. En angriper trenger ikke en fungerende kvantedatamaskin i dag for å skade deg i morgen. Det holder å lagre kryptert trafikk eller signerte dokumenter nå, og forfalske eller dekryptere dem senere, den dagen en tilstrekkelig kraftig kvantedatamaskin finnes. For data som må forbli troverdig i tiår, som helsejournaler, forsvarsdokumenter eller rotsertifikater, er dette allerede et akutt problem, selv om selve kvantedatamaskinen ikke er bygget ennå.

Shors algoritme, publisert av matematikeren Peter Shor i 1994, viser at en tilstrekkelig stor kvantedatamaskin kan faktorisere store tall og løse diskrete logaritmeproblemer eksponentielt raskere enn klassiske datamaskiner. Det rammer RSA og elliptisk kurve-kryptografi som ECDSA og Ed25519 direkte, siden begge hviler på nettopp disse problemene. Digitale signaturer basert på hash-funksjoner eller gitter er derimot ikke sårbare for Shors algoritme i det hele tatt, og det er derfor NIST konsentrerte sitt post-kvante-arbeid rundt akkurat disse to matematiske familiene.

NIST startet den formelle konkurransen om post-kvante-standarder i 2016, og prosessen tok åtte år før de tre første standardene, ML-KEM, ML-DSA og SLH-DSA, ble endelige i august 2024. Falcon var med fra samme tidspunkt, men står altså fortsatt ikke ferdig gjennom løpet. Ingen kjent kvantedatamaskin i dag er nær ved å true RSA-2048 eller ECDSA i praksis. Men migreringstiden for kryptografisk infrastruktur i store organisasjoner måles ofte i år, ikke måneder, og det tidsgapet er nettopp det disse standardene skal dekke.

Hva er SLH-DSA (SPHINCS+)?

SLH-DSA står for Stateless Hash-Based Digital Signature Algorithm, og algoritmen er en direkte videreføring av SPHINCS+-forslaget som vant frem i NISTs post-kvante-konkurranse. Navnet forteller mye om konstruksjonen: signaturen bygges utelukkende på hash-funksjoner (SHA-2 eller SHA-3 via SHAKE), ikke på tall-teoretiske problemer som faktorisering eller gitter. Det gjør SLH-DSA til det mest konservative alternativet i NISTs post-kvante-portefølje, fordi sikkerheten til hash-funksjoner har vært studert i tiår uten at noen har funnet en praktisk kvantealgoritme som knekker dem raskere enn Grovers algoritme klarer.

Ifølge NISTs egen beskrivelse, gjengitt på Wikipedia, er SLH-DSA bevisst bygget på en annen matematisk tilnærming enn ML-DSA (Dilithium), og algoritmen er ment som en backup-metode i tilfelle gitterbaserte signaturer på et tidspunkt viser seg sårbare. Det er ikke en tilfeldighet at NIST standardiserte to signaturalgoritmer med helt ulikt matematisk fundament samtidig, strategien er bevisst risikospredning.

Prisen for denne konservative tilnærmingen er størrelse og hastighet. FIPS 205 definerer tolv parametersett, fordelt på tre sikkerhetsnivåer og to profiler: en “s”-variant (small) optimalisert for liten signatur og tregere signering, og en “f”-variant (fast) optimalisert for raskere signering på bekostning av større signatur. Den minste av alle, SLH-DSA-SHA2-128s, produserer en signatur på 7.856 byte, mens 128f-varianten lander på 17.088 byte. NIST jobber allerede med å gjøre algoritmen mer praktisk: i april 2026 publiserte etaten et utkast til SP 800-230, som foreslår seks ekstra parametersett for SLH-DSA rettet mot “begrenset signaturbruk”, altså systemer som bare trenger å signere et fåtall ganger i løpet av produktets levetid, som fastvareoppdateringer.

Hva er Falcon og FN-DSA?

Falcon er en gitterbasert signaturalgoritme, bygget på NTRU-gitter, og navnet er en forkortelse for “Fast Fourier Lattice-based Compact signatures over NTRU”. Når NIST ferdigstiller standardiseringen som FIPS 206, får algoritmen det offisielle navnet FN-DSA, en forkortelse for “FFT over NTRU-lattice-based Digital Signature Algorithm”. Konstruksjonen er mer kompleks enn SLH-DSA: en Falcon-signatur er et gitterpunkt som ligger nær et målpunkt utledet fra en randomisert hash av meldingen, og algoritmen bruker Fast Fourier Transform sammen med et LDL-tre (kalt “Falcon Tree”) for å tilnærme diskret gaussisk sampling, ifølge NISTs egen presentasjon av FN-DSA-statusen.

Det som gjør Falcon attraktiv er kompaktheten. En Falcon-512-signatur veier 666 byte og den offentlige nøkkelen er 897 byte, tall som er bekreftet både i IETFs utkast for FN-DSA i JOSE og COSE og i W3Cs spesifikasjon for kvanteresistente signatursuiter. Falcon-1024, som gir høyere sikkerhetsnivå, bruker en offentlig nøkkel på 1.793 byte og en signatur på 1.280 byte. Til sammenligning med de klassiske algoritmene den skal erstatte er dette fortsatt større enn en ECDSA-signatur på rundt 64 byte, men langt mindre enn hva SLH-DSA klarer å levere.

Ulempen er implementasjonskompleksitet. Falcon krever flyttallsberegninger med presis avrunding for å unngå at private nøkkeldata lekker gjennom sidekanaler, noe som har gjort det vanskeligere å bygge konstant-tid-implementasjoner sammenlignet med SLH-DSA, som kun trenger hash-operasjoner. Dette er en av grunnene til at FIPS 206 har tatt lengre tid å ferdigstille enn FIPS 205.

Standardiseringsstatus: FIPS 205 mot FIPS 206

Dette er trolig den viktigste forskjellen for alle som skal ta en beslutning i 2026. FIPS 205, som spesifiserer SLH-DSA, ble publisert og trådte i kraft 13. august 2024, sammen med FIPS 203 (ML-KEM) og FIPS 204 (ML-DSA). Alle tre er, ifølge Encryption Consultings gjennomgang av NISTs PQC-standarder, produksjonsklare erstatninger for RSA og ECC allerede i dag.

FN-DSA, som blir FIPS 206, ligger derimot fortsatt i utkastfasen. NIST sendte inn utkastet til intern godkjenning 28. august 2025, og ifølge DigiCerts gjennomgang av statusen hadde det offentlige utkastet (Initial Public Draft) fortsatt ikke blitt publisert per april 2026. Den samme kilden anslår at den ferdige standarden kommer sent i 2026 eller tidlig i 2027, etter om lag ett år med offentlig høring. Det betyr at alle som bygger på Falcon i dag, teknisk sett bygger på et utkast som fortsatt kan endres før det blir en føderal standard.

EgenskapSLH-DSA (FIPS 205)Falcon / FN-DSA (FIPS 206)
StandardiseringsstatusFerdig, endelig standardUtkast, ikke ferdig
Publiseringsdato13. august 2024Ikke satt, ventet sent 2026 / tidlig 2027
Siste kjente milepælSP 800-230-utkast, april 2026Internt utkast sendt inn 28. august 2025
Matematisk grunnlagHash-funksjoner (SHA-2/SHA-3)NTRU-gitter
Betraktes somKonservativt reserve-alternativKompakt hovedalternativ

Full spesifikasjonstabell: SLH-DSA mot Falcon

Tallene under er hentet fra de offisielle spesifikasjonene, NISTs egne presentasjoner og standardiseringsdokumentene fra IETF og W3C. Falcon har faste byte-tall fordi NIST-varianten som blir stående i FIPS 206 bruker et fast signaturformat (padded), mens ikke-paddede varianter i biblioteker som liboqs kan variere noe.

ParameterSLH-DSA-128sSLH-DSA-128fFalcon-512Falcon-1024
Sikkerhetsnivå (NIST)1115
Offentlig nøkkel32 byte32 byte897 byte1.793 byte
Privat nøkkel64 byte64 byte1.281 byte2.305 byte
Signaturstørrelse7.856 byte17.088 byte666 byte1.280 byte
Matematisk grunnlagHash-basertHash-basertNTRU-gitterNTRU-gitter
Antall parametersett totalt12 (FIPS 205)2 hovedvarianter
Signeringshastighet (relativ CPU-tid)~8.000~550~8ikke oppgitt
Verifiseringshastighet (relativ CPU-tid)~2,8~7~0,5ikke oppgitt
Krever flyttallsaritmetikkNeiNeiJaJa
Sidekanalrisiko ved implementasjonLavLavModerat til høyModerat til høy
StandardstatusFerdig (FIPS 205)Ferdig (FIPS 205)Utkast (FIPS 206)Utkast (FIPS 206)

De relative CPU-tallene i tabellen kommer fra en benchmark-presentasjon vist på DEF CON i 2024, der Falcon-512 er satt som referansepunkt for signeringshastighet. Legg merke til at SLH-DSA-128s, som har den minste signaturen blant SLH-DSA-variantene, samtidig er den desidert tregeste å signere med, mens 128f-varianten er raskere å signere med, men produserer en over dobbelt så stor signatur.

Alle seks kombinasjonene av sikkerhetsnivå og hastighetsprofil i FIPS 205 følger det samme mønsteret: jo høyere sikkerhetsnivå, desto større blir både nøkler og signaturer, og “f”-variantene er alltid over dobbelt så store som “s”-variantene på samme nivå.

ParametersettSikkerhetsnivåOffentlig nøkkelPrivat nøkkelSignatur
SLH-DSA-128s132 byte64 byte7.856 byte
SLH-DSA-128f132 byte64 byte17.088 byte
SLH-DSA-192s348 byte96 byte16.224 byte
SLH-DSA-192f348 byte96 byte35.664 byte
SLH-DSA-256s564 byte128 byte29.792 byte
SLH-DSA-256f564 byte128 byte49.856 byte

Falcon holder seg til bare to varianter uansett sikkerhetsnivå, 512 og 1024, fordi den gitterbaserte konstruksjonen ikke trenger like mange justeringsknapper for å oppnå ulike sikkerhetsnivåer. Det er en direkte konsekvens av at Falcons signaturstørrelse vokser lineært med sikkerhetsnivået, mens SLH-DSA sin vokser raskere fordi hver økning i sikkerhetsnivå krever dypere hash-trær og dermed flere bevis-elementer i hver signatur, som forklart i selve FIPS 205-standarden.

Ytelsesbenchmark fra tre uavhengige kilder

Ett benchmark-tall er sjelden nok til å stole på i kryptografi, fordi resultatene varierer med prosessor, kompilator og implementasjon. Derfor har vi samlet tall fra tre separate kilder som alle måler den samme grunnleggende forskjellen: Falcon signerer raskt, SLH-DSA signerer tregt.

  • NIST CSRC, september 2025: I presentasjonen “Smaller SLH-DSA” oppgir NIST at en signering med SLH-DSA-SHA2-128s krever rundt 2,2 millioner hash-kall, tilsvarende omtrent 644.740.090 CPU-sykluser, og tar cirka 0,2 sekunder på testplattformen som ble brukt.
  • DEF CON 2024: En uavhengig sammenligning vist på sikkerhetskonferansen DEF CON, publisert av forsker James Howe, viser at SLH-DSA sin “s”-variant bruker rundt 8.000 ganger så mye relativ CPU-tid til signering som Falcon-512, mens “f”-varianten bruker rundt 550 ganger så mye.
  • Falcons offisielle implementasjonsside: Ifølge falcon-sign.info, det offisielle nettstedet for referanseimplementasjonen, klarer Falcon-512 rundt 5.948 signeringer og 27.933 verifiseringer per sekund på testmaskinen som brukes, mens Falcon-1024 klarer rundt 2.913 signeringer og 13.650 verifiseringer per sekund.

Konklusjonen fra alle tre kildene peker samme vei: Falcon er bygget for høyfrekvent signering, som TLS-håndtrykk eller API-autentisering, mens SLH-DSA egner seg best der signering skjer sjelden, men verifisering skjer ofte, som ved fastvareoppdateringer eller rotsertifikater som skal signeres én gang og verifiseres av millioner av enheter i mange år fremover.

Nøkkelgenerering forteller en litt annen historie. Ifølge tall fra falcon-sign.info bruker Falcon-512 rundt 8,64 millisekunder og 14.336 byte minne for å generere et nøkkelpar, mens Falcon-1024 bruker 27,45 millisekunder og 28.672 byte. Dette er fortsatt raskere enn de fleste SLH-DSA-variantene, men forskjellen er langt mindre enn for selve signeringen, fordi nøkkelgenerering for begge algoritmefamiliene er en operasjon som normalt bare skjer én gang per nøkkelpar, ikke per signatur.

Bibliotek- og verktøystøtte i 2026

Ingen av algoritmene er nyttige uten kode som faktisk implementerer dem riktig. Open Quantum Safe-prosjektet, som driver biblioteket liboqs, er i praksis blitt referanseimplementasjonen utviklere bruker til å eksperimentere med post-kvante-algoritmer før de commiter til en produksjonsløsning. Ifølge PQCA sin kunngjøring av liboqs versjon 0.14.0 i august 2025 støtter biblioteket i dag et bredt sett med signaturalgoritmer, inkludert Falcon, ML-DSA, SPHINCS+ (SLH-DSA), samt nyere kandidater som CROSS, MAYO, SNOVA og UOV, i tillegg til de statlige eldre standardene LMS og XMSS.

For virksomheter som bruker OpenSSL, finnes det en tilhørende oqs-provider som lar utviklere teste post-kvante-signaturer direkte i eksisterende TLS-stakker uten å bytte ut hele kryptografibiblioteket. Dette gjør det mulig å kjøre kontrollerte tester av både SLH-DSA og Falcon side om side i et testmiljø, måle faktisk ytelsespåvirkning på egen infrastruktur, og sammenligne resultatene direkte mot tallene i denne artikkelen før man tar en beslutning som gjelder produksjon.

Sikkerhetsgrunnlag: hash-basert mot gitterbasert kryptografi

Den underliggende matematikken innenfor moderne kryptografi er der de to algoritmene skiller seg mest fundamentalt. SLH-DSA sin sikkerhet hviler utelukkende på egenskapene til hash-funksjoner, altså at det er beregningsmessig umulig å finne to ulike meldinger som gir samme hash (kollisjonsresistens), og at man ikke kan reversere en hash til den opprinnelige meldingen (preimage-resistens). Dette er egenskaper kryptografer har testet grundig i over to tiår, og ingen kjent kvantealgoritme gir mer enn en kvadratisk fartsøkning mot dem (via Grovers algoritme), noe som er langt mindre alvorlig enn den eksponentielle fartsøkningen Shors algoritme gir mot RSA og elliptisk kurve-kryptografi.

Falcon hviler på en annen antagelse: at det er beregningsmessig vanskelig å finne korte vektorer i strukturerte NTRU-gitter, selv med tilgang til en kvantedatamaskin. Dette problemet har vært studert siden midten av 1990-tallet, og det er også grunnlaget for ML-KEM og ML-DSA, de to andre allerede standardiserte NIST-algoritmene. Det betyr samtidig at hvis noen finner en fundamental svakhet i gitterbaserte problemer, faller tre av NISTs fire post-kvante-standarder på samme tid. Det er nettopp denne risikoen SLH-DSA er designet for å dekke.

Kostnadsbildet: hva størrelsesforskjellen betyr i praksis

Ingen av algoritmene koster noe i lisens, begge er åpne NIST-standarder som kan implementeres fritt. Men signaturstørrelse har en reell kostnad når systemer skalerer til millioner av operasjoner, i form av båndbredde, lagring og prosessortid. Tabellen under viser en illustrasjon av hva forskjellen betyr ved én million signaturer, basert på en vanlig sky-utgangspris på 0,09 dollar per GB. Dette er ment som en illustrasjon av skalaeffekten, ikke en offisiell pris fra noen leverandør, faktiske priser varierer med sky-leverandør, region og volum.

AlgoritmeSignaturstørrelseData ved 1 million signaturerIllustrativ båndbreddekostnadSigneringstid relativt til Falcon-512Lisenskostnad
Falcon-512666 byte0,63 GB~$0,061x (referanse)$0
Falcon-10241.280 byte1,19 GB~$0,11~2x tregere$0
SLH-DSA-128f17.088 byte15,9 GB~$1,43~550x tregere$0
SLH-DSA-128s7.856 byte7,32 GB~$0,66~8.000x tregere$0

Det som overrasker mange er at SLH-DSA-128s, som har mindre signatur enn 128f, likevel er dyrere i CPU-tid enn den fysisk større 128f-varianten. Det er fordi “s” står for small og prioriterer signaturstørrelse over hastighet i selve konstruksjonen, mens “f” (fast) gjør motsatt avveining. For systemer som signerer sjelden, men verifiserer ofte, som en produsent som signerer fastvare én gang før den sendes ut til millioner av enheter, er den ekstra signeringstiden i praksis irrelevant. For systemer som signerer kontinuerlig, som en sertifikatmyndighet eller en API-gateway, er forskjellen alt.

Virkelige eksempler på bruk og tidlig adopsjon

Ingen av algoritmene har foreløpig en stor, navngitt produksjonsutrulling som paraderes offentlig, men det finnes konkrete spor av adopsjon i standarder og pilotarbeid gjennom 2025 og 2026.

  • W3C Quantum-Resistant Cryptosuites: W3Cs spesifikasjon for verifiserbare akkreditiver inkluderer Falcon-512 og Falcon-1024 som offisielle signaturvarianter, noe som viser at algoritmen allerede er tatt inn i webstandarder før FIPS 206 er ferdig.
  • IETF FN-DSA for JOSE og COSE: Et aktivt IETF-utkast definerer hvordan FN-DSA skal brukes i JSON- og CBOR-baserte token-formater, altså den typen signaturer som ligger bak API-autentisering og enkelte innloggingstokener i dag.
  • AWS Key Management Service: AWS har allerede integrert ML-DSA (FIPS 204) i sin PQC-satsing i AWS KMS. Det er ikke Falcon eller SLH-DSA spesifikt, men det viser at store skyleverandører beveger seg raskt på signaturstandardene som allerede er ferdige, noe som historisk pleier å bane vei for de neste.
  • Google Chrome og hybride nøkkelutvekslinger: Chrome byttet allerede i 2024 til ML-KEM for nøkkelutveksling, ifølge The Hacker News. Det er ikke en signaturalgoritme, men det viser samme mønster: nettleserleverandører flytter seg først på det som er ferdig standardisert, og signaturalgoritmene følger etter i samme rekkefølge som Falcon nå gjør med SLH-DSA og ML-DSA foran seg.
  • DNSSEC og båndbreddesensitive protokoller: En 2025-gjennomgang av post-kvante-kryptografi publisert på arXiv peker på at Falcons kompakte signaturer gjør algoritmen spesielt egnet for DNSSEC, der hver ekstra byte i en respons øker risikoen for fragmentering og forsterkningsangrep.
  • Programvareforsyningskjeder (TUF/Notary): Forskning på post-kvante-sikring av container-forsyningskjeder har testet SLH-DSA i rammeverk som TUF og Notary, og funnet at ytelsen på rundt 160 signeringer per sekund gjør algoritmen uegnet for høyfrekvent signering i CI/CD-pipeliner, men fullt brukbar for sjeldne, kritiske signeringer som root-of-trust-nøkler.

Når bør du velge SLH-DSA?

SLH-DSA passer best når konservativ sikkerhet veier tyngre enn størrelse og hastighet. Her er fem konkrete bruksområder der SLH-DSA er det naturlige valget:

  • Rotsertifikater med lang levetid. Et rotsertifikat signeres én gang og skal holde i tiår. Da spiller signaturstørrelsen mindre rolle, mens det matematiske sikkerhetsgrunnlaget betyr alt.
  • Fastvaresignering i IoT og industri. Enheter som får én fastvareoppdatering i året tåler en treg signeringsprosess på produsentens side, mens selve enheten bare trenger å verifisere, en operasjon som er langt raskere enn signering.
  • Backup-signatur i hybride oppsett. Flere organisasjoner kombinerer en gitterbasert og en hash-basert signatur på samme dokument, slik at et fremtidig gjennombrudd mot gitterproblemer ikke gjør hele systemet usikkert på én gang.
  • Myndighets- og forsvarssystemer med lang gyldighetstid. Systemer som må dokumentere sikkerhet i offentlige revisjoner drar nytte av at SLH-DSA bygger på et matematisk problem som er enklere å forklare og revidere enn gitterproblemer.
  • Signering av kritiske root-of-trust-nøkler i forsyningskjeder. Som nevnt over egner algoritmen seg for sjeldne, høyverdi-signeringer i rammeverk som TUF og Notary, der antall signeringer per år er lavt, men konsekvensen av en kompromittert nøkkel er svært høy.

Når bør du velge Falcon (FN-DSA)?

Falcon er det naturlige valget når volum og hastighet er avgjørende, og du kan leve med at standarden formelt sett fortsatt er et utkast:

  • TLS-håndtrykk med høyt volum. En signatur på 666 byte gjør langt mindre skade på båndbredde og latens i et TLS-håndtrykk enn en signatur på flere titalls kilobyte.
  • API-autentisering og JWT-baserte tokener. Med et aktivt IETF-utkast for FN-DSA i JOSE og COSE er dette allerede forberedt for token-baserte systemer som må signere og verifisere tusenvis av forespørsler i sekundet.
  • DNSSEC og andre båndbreddesensitive protokoller. Som nevnt tidligere er dette et av de klareste eksemplene der Falcons kompakthet er avgjørende, ikke bare ønskelig.
  • Sertifikatmyndigheter med høyt utstedelsesvolum. En CA som signerer millioner av sertifikater i året vil merke forskjellen på 8.000 ganger i signeringstid direkte på infrastrukturkostnadene.
  • Verifiserbare akkreditiver og digitale identitetsløsninger. W3Cs inkludering av Falcon i sin kryptosuit for kvanteresistente akkreditiver gjør algoritmen til et naturlig valg for digitale ID-løsninger som allerede bygger på W3C-standarder.

SLH-DSA og Falcon i det større post-kvante-bildet

Verken SLH-DSA eller Falcon eksisterer i et vakuum. NISTs portefølje har også ML-DSA (tidligere Dilithium), som de fleste organisasjoner regner som hovedalternativet for digitale signaturer fordi det treffer en balanse mellom størrelse og hastighet mellom de to algoritmene i denne artikkelen. Vi har gått grundigere gjennom den avveiningen i vår egen sammenligning av ML-DSA mot SLH-DSA, og i en egen artikkel om Falcon mot Dilithium, som ser på de to gitterbaserte signaturkandidatene opp mot hverandre.

Signaturalgoritmer er bare halve bildet. Nøkkelutveksling, altså hvordan to parter blir enige om en delt hemmelighet før kryptert kommunikasjon starter, er et separat problem løst av ML-KEM. Der finnes det også alternativer med andre matematiske grunnlag, akkurat som med signaturer, noe vi dekker i vår sammenligning av ML-KEM mot Classic McEliece. For virksomheter som allerede tester hybrid nøkkelutveksling i TLS, altså å kombinere en klassisk og en post-kvante-algoritme i samme håndtrykk, har vi også en egen gjennomgang av hybrid mot ren ML-KEM i TLS, som viser de samme kompromissene mellom størrelse og sikkerhetsmargin som denne artikkelen beskriver for signaturer.

Helhetsbildet er at ingen enkelt algoritme løser hele post-kvante-migreringen alene. En fullstendig kvanteresistent arkitektur trenger minst én KEM-algoritme for nøkkelutveksling og minst én signaturalgoritme, og de fleste sikkerhetsarkitekter anbefaler å ha en reservealgoritme klar for begge kategoriene, i tråd med NISTs egen strategi om matematisk mangfold.

Hva betyr dette for norske og nordiske virksomheter?

Norske og nordiske virksomheter møter det samme tidspresset som resten av Europa, men fra en litt annen regulatorisk vinkel. Virksomheter som allerede er underlagt NIS2-regelverket må dokumentere risikostyring for hele forsyningskjeden, kryptografisk praksis inkludert, noe vi har beskrevet nærmere i vår gjennomgang av NIS2 i Norge. Kryptografisk migrering til SLH-DSA eller Falcon faller naturlig inn under den samme risikokartleggingen, selv om ingen norsk tilsynsmyndighet i dag krever en bestemt post-kvante-algoritme innen en bestemt frist.

For nordiske banker, energiselskaper og offentlige etater med lange systemlevetider, ofte tjue år eller mer for kritisk infrastruktur, er valget mellom SLH-DSA og Falcon sjelden et enten-eller. Systemer som skal driftes til godt over 2040 bør planlegge for begge, uansett hvilken som velges først som pilot. Det gjelder spesielt sektorer som allerede er vant til lange sertifiseringsløp, som kraftforsyning og finans, der en kryptografisk komponent sjelden byttes ut alene, men følger med i større systemoppgraderinger som uansett skjer med flere års mellomrom.

Migreringsguide: fra klassiske signaturer til post-kvante

En overgang til SLH-DSA eller Falcon bør ikke gjøres i én operasjon. De fleste organisasjoner som har kommet lengst bruker en gradvis, hybrid tilnærming der den klassiske og den nye algoritmen kjører side om side en periode.

  1. Kartlegg hvor digitale signaturer faktisk brukes i systemet ditt i dag: sertifikater, kodesignering, API-tokener, dokumentsignering og fastvare.
  2. Klassifiser hvert bruksområde etter to akser: hvor ofte signeres det, og hvor lenge må signaturen forbli gyldig og troverdig.
  3. For høyfrekvent signering med moderate levetidskrav, sett Falcon (eller ML-DSA) øverst på listen for pilotering.
  4. For sjelden signering med svært lange levetidskrav, som rotsertifikater, sett SLH-DSA øverst.
  5. Test biblioteker som støtter begge algoritmene, som Open Quantum Safe sitt liboqs-prosjekt, i et isolert testmiljø før noe rører produksjon.
  6. Mål faktisk ytelsespåvirkning i din egen infrastruktur. Tallene i denne artikkelen er referansepunkter, ikke garantier, siden prosessor, nettverksforhold og biblioteksimplementasjon varierer.
  7. Implementer hybridsignaturer der det er mulig, altså at et dokument signeres med både en klassisk og en post-kvante-algoritme samtidig.
  8. Oppdater sertifikatinfrastruktur og PKI-verktøy til å håndtere de større nøkkel- og signaturstørrelsene, spesielt for SLH-DSA.
  9. Test verifiseringsytelsen på klientenheter med begrenset prosessorkraft, som IoT-enheter, siden dette ofte er flaskehalsen, ikke serveren.
  10. Følg med på NISTs oppdateringer om FIPS 206, siden formatet fortsatt kan endres før den endelige standarden er satt.
  11. Dokumenter kryptografisk smidighet i arkitekturen, slik at algoritmer kan byttes ut igjen uten en full ombygging, når neste generasjon standarder kommer.
  12. Rull ut gradvis, start med interne systemer og lavrisiko-tjenester før du beveger deg mot kundevendte og forretningskritiske systemer.

Et eksempel på hvordan en hybrid signeringsfunksjon kan se ut i praksis, ved bruk av Open Quantum Safe sitt liboqs-bibliotek:

from oqs import Signature

def sign_hybrid(message: bytes):
    classical_sig = classical_ecdsa_sign(message)

    with Signature("Falcon-512") as falcon:
        public_key = falcon.generate_keypair()
        falcon_sig = falcon.sign(message)

    with Signature("SLH-DSA-SHA2-128s") as slh_dsa:
        public_key_slh = slh_dsa.generate_keypair()
        slh_dsa_sig = slh_dsa.sign(message)

    return {
        "classical": classical_sig,
        "falcon": falcon_sig,
        "slh_dsa": slh_dsa_sig,
    }

Poenget med å signere med tre algoritmer samtidig i en overgangsperiode er at et system forblir sikkert selv om én av de tre skulle vise seg sårbar, enten på grunn av en kvantedatamaskin eller en klassisk kryptoanalytisk oppdagelse.

I praksis betyr dette også endringer lenger ned i stabelen enn selve signeringskoden. Sertifikatformater basert på X.509 må utvides for å bære flere signaturer eller flere offentlige nøkler i samme sertifikat, en teknikk som ofte omtales som komposittsignaturer. Flere sertifikatmyndigheter og standardiseringsgrupper jobber allerede med slike formater, nettopp fordi en ren utskifting av én algoritme med en annen sjelden er mulig i praksis uten en overgangsperiode der begge må fungere samtidig i det samme sertifikatet.

Fordeler og ulemper ved SLH-DSA

Fordeler

  • Allerede en ferdig, endelig NIST-standard (FIPS 205) siden august 2024.
  • Bygger kun på hash-funksjoner, som har det mest konservative sikkerhetsgrunnlaget blant alle post-kvante-kandidatene.
  • Svært liten offentlig nøkkel, ned mot 32 byte i de minste variantene.
  • Ingen flyttallsaritmetikk, som gjør konstant-tid-implementasjoner enklere og reduserer sidekanalrisiko.
  • Aktiv videreutvikling gjennom NISTs SP 800-230 for flere praktiske parametersett.

Ulemper

  • Store signaturer, fra 7.856 byte og oppover, som belaster båndbredde og lagring.
  • Betydelig tregere signering enn Falcon, i enkelte benchmarks flere tusen ganger tregere.
  • Krever tilpasning av PKI- og sertifikatinfrastruktur som er bygget for langt mindre signaturer.
  • Uegnet for høyfrekvente signeringsscenarioer som CI/CD-pipeliner eller sanntids-API-er.

Fordeler og ulemper ved Falcon (FN-DSA)

Fordeler

  • Blant de mest kompakte post-kvante-signaturene som finnes, med bare 666 byte i Falcon-512.
  • Rask signering og svært rask verifisering, godt egnet for høyt volum.
  • Allerede tatt i bruk i standarder som W3Cs kvanteresistente kryptosuiter og IETFs FN-DSA-utkast.
  • Deler matematisk fundament (gitterproblemer) med ML-KEM og ML-DSA, som begge allerede er endelige standarder.

Ulemper

  • Fortsatt et utkast (FIPS 206), ikke en ferdig føderal standard per september 2026.
  • Krever flyttallsaritmetikk med presis avrunding, noe som gjør konstant-tid-implementasjoner mer krevende å bygge riktig.
  • Deler samme matematiske familie (gitter) som to av de tre andre NIST-standardene, noe som gir mindre matematisk mangfold i en portefølje.
  • Standarden kan fortsatt endre seg noe før den er endelig, siden den offentlige høringsrunden ikke er fullført.

Verdikt: hvilken bør du satse på i 2026?

Basert på tallene i denne artikkelen er svaret ikke enten-eller, men et spørsmål om rekkefølge. SLH-DSA er allerede en ferdig standard du kan implementere i produksjon i dag uten å vente på noe mer fra NIST. Det gjør algoritmen til det tryggeste valget for alt som krever langvarig sikkerhet og der du ikke vil bygge på et utkast, som rotsertifikater og fastvaresignering. Falcon vinner på nesten alle ytelsesmål, med en signatur som er over ti ganger mindre og en signeringshastighet som i enkelte benchmarks er tusenvis av ganger raskere, men algoritmen mangler fortsatt den formelle standardstatusen som SLH-DSA har hatt siden 2024.

Den praktiske anbefalingen for de fleste norske og nordiske organisasjoner som planlegger post-kvante-migrering nå: bruk SLH-DSA der standardstatus er et krav i dag, typisk i regulerte bransjer og offentlig sektor, og begynn pilotering med Falcon i høyvolum-systemer parallelt, slik at infrastrukturen er klar den dagen FIPS 206 blir endelig, ventet sent i 2026 eller tidlig i 2027. Ingen bør vente med å starte migreringsarbeidet til den dagen kommer, fordi selve overgangsprosessen, med hybridsignaturer, oppdatert PKI og testing på tvers av klienter, tar lengre tid enn de fleste anslår på forhånd.

Sett i tall er avstanden mellom de to algoritmene større enn i de fleste andre kryptografiske sammenligninger. En signatur som er over ti ganger mindre, en signeringshastighet som i benchmarkene over spenner fra 550 til 8.000 ganger raskere, og en offentlig nøkkel som til gjengjeld er 28 ganger større, er ikke marginale forskjeller man kan se bort fra i en arkitekturbeslutning. Samtidig er atten måneders forsprang i standardiseringsløpet, fra august 2024 til et anslått ferdig FIPS 206 sent i 2026 eller inn i 2027, en konkret og målbar risiko for alle som må dokumentere compliance i dag, ikke om et år. Begge tallsettene er reelle, og den som må velge først, bør velge etter hvilket av de to som faktisk begrenser prosjektet: standardstatus eller ytelse.

Ofte stilte spørsmål

Er SLH-DSA det samme som SPHINCS+?

Ja. SLH-DSA er navnet NIST ga algoritmen da SPHINCS+-forslaget ble standardisert som FIPS 205. Den underliggende konstruksjonen er den samme, bare med et offisielt standardnavn.

Er Falcon og FN-DSA to forskjellige algoritmer?

Nei, det er samme algoritme. Falcon er navnet på det opprinnelige forslaget til NISTs konkurranse, og FN-DSA blir det offisielle navnet når algoritmen ferdigstilles som FIPS 206. Nøkkel- og signaturstørrelsene forblir de samme som i den originale Falcon-spesifikasjonen.

Kan jeg bruke Falcon i produksjon allerede nå, selv om FIPS 206 ikke er ferdig?

Teknisk sett ja, biblioteker som liboqs støtter Falcon allerede, men du bør være klar over at parameterdetaljer i teorien kan endres før standarden er endelig. For systemer med langvarige krav til standardkompatibilitet er det tryggere å vente på den ferdige FIPS 206-teksten, eller kjøre Falcon som et supplement til en allerede ferdig standard som ML-DSA eller SLH-DSA.

Hvorfor er SLH-DSA-signaturer så mye større enn Falcon-signaturer?

Fordi hash-baserte signaturer må inkludere store mengder bevismateriale, som Merkle-tre-stier, for å bevise at signaturen ble generert riktig, mens gitterbaserte signaturer som Falcon kan uttrykkes langt mer kompakt matematisk. Dette er en grunnleggende egenskap ved konstruksjonstypen, ikke noe som kan optimaliseres bort uten å endre selve algoritmen.

Hvilken av de to er sikrest mot kvantedatamaskiner?

Begge er designet for å motstå kjente kvantealgoritmer. Forskjellen ligger i hvilken type klassisk gjennombrudd som kan svekke dem. SLH-DSA er avhengig av at hash-funksjoner forblir sikre, en antagelse med lang historikk. Falcon er avhengig av at gitterproblemer forblir vanskelige, en nyere antagelse som deles med de fleste andre post-kvante-standarder. De fleste kryptografer anser SLH-DSA som det mer konservative valget nettopp av denne grunnen.

Må jeg velge én av dem, eller kan jeg bruke begge?

De fleste store organisasjoner planlegger å bruke begge, avhengig av bruksområde. Noen bruker også begge samtidig på samme dokument gjennom hybridsignering, som beskrevet i migreringsguiden over, for å redusere risikoen for at ett enkelt kryptografisk gjennombrudd svekker hele systemet.

Når blir FIPS 206 en ferdig standard?

Per september 2026 er det ingen fastsatt dato, men bransjeanalyser som DigiCerts gjennomgang anslår sent i 2026 eller tidlig i 2027, basert på at utkastet ble sendt til intern godkjenning i august 2025 og normalt gjennomgår rundt ett år med offentlig høring før det blir endelig.

Påvirker denne overgangen Bitcoin og andre kryptovalutaer?

Ja, i prinsippet, siden de fleste blokkjeder i dag bruker klassiske signaturalgoritmer som ECDSA. Verken SLH-DSA eller Falcon er foreløpig implementert som standard signaturalgoritme i store offentlige blokkjeder, men begge diskuteres som kandidater i forskningsmiljøer som ser på hvordan blokkjeder kan bli kvanteresistente over tid. Vi har sett nærmere på hva en slik overgang kan innebære for Bitcoin spesifikt i vår egen gjennomgang av post-kvante-sikring av Bitcoin.

Hva skjer med eksisterende sertifikater under overgangen til post-kvante-signaturer?

Eksisterende sertifikater basert på RSA eller ECDSA fortsetter å fungere som normalt frem til de utløper eller trekkes tilbake. Utfordringen ligger i sertifikater som utstedes nå med lang gyldighetstid, siden de risikerer å være i bruk den dagen en kryptografisk relevant kvantedatamaskin dukker opp. De fleste sertifikatmyndigheter anbefaler derfor kortere gyldighetstid på nye sertifikater i overgangsperioden, kombinert med hybride eller komposittsignaturer der infrastrukturen støtter det.