Valget mellom to post-kvante-signaturalgoritmer høres ut som noe bare kryptografer bryr seg om. Det stemmer ikke lenger. NIST gjorde ML-DSA (tidligere Dilithium) til hovedstandard for digitale signaturer i august 2024, mens FN-DSA (tidligere Falcon) fortsatt henger i utkastfasen. Begge skal etter planen erstatte RSA og ECDSA innen kvantedatamaskiner blir en reell trussel mot dagens kryptografi. Spørsmålet norske IT-avdelinger, banker og det offentlige nå må svare på er ikke om de skal bytte, men hvilken av de to algoritmene som passer systemene deres best. Denne artikkelen går gjennom spesifikasjonene, ytelsestallene og de praktiske konsekvensene av å velge Falcon fremfor Dilithium, eller omvendt.

Vi har tidligere sett på hvordan ML-DSA erstatter ECDSA og hvordan ML-KEM konkurrerer med NTRU på nøkkelutvekslingssiden. Denne gangen snur vi blikket mot de to signaturalgoritmene som NIST selv har plassert side om side i sin post-kvante-portefølje, og ser på hvorfor valget mellom dem ikke er like opplagt som mange tror.

Hva er NISTs post-kvante-signaturstandarder?

13. august 2024 publiserte det amerikanske standardiseringsorganet NIST tre ferdige standarder på én gang: FIPS 203 (ML-KEM, bygget på CRYSTALS-Kyber) for nøkkelinnkapsling, FIPS 204 (ML-DSA, bygget på CRYSTALS-Dilithium) for generelle digitale signaturer, og FIPS 205 (SLH-DSA, bygget på SPHINCS+) som en hash-basert reserveløsning. En fjerde standard, FIPS 206, skal formalisere Falcon under det nye navnet FN-DSA (FFT over NTRU-Lattice-Based Digital Signature Algorithm). Den er fortsatt i utkast per 2026, og flere fagkilder, blant annet NIST selv og analysebyrået QubitChain, venter ferdigstillelse en gang i 2027.

Grunnen til at det finnes to konkurrerende signaturstandarder er ikke tilfeldig. Dilithium ble valgt som hovedalgoritme fordi den er rask og relativt grei å implementere sikkert. Falcon ble tatt med fordi den produserer mye mindre signaturer, noe som teller tungt i miljøer med begrenset båndbredde eller lagringsplass, som smartkort, SIM-kort og fastvareoppdateringer. NIST har med andre ord ikke bygget ett verktøy for alle formål, men to verktøy med forskjellige styrker.

Presset for å faktisk gjennomføre byttet har økt i 2025 og 2026. Ifølge en oversikt fra utviklerressursen AllDevToolsHub kom det en presidentordre i USA i juni 2025 som pålegger amerikanske føderale etater å migrere til post-kvante-kryptografi, med egne frister for nasjonale sikkerhetssystemer fra januar 2027. Samtidig har store aktører som Google Chrome, Cloudflare, Akamai og Signal allerede rullet ut hybrid nøkkelutveksling (X25519 kombinert med ML-KEM) i internett-skala, en utvikling vi også dekket i saken om X25519 mot P-256. Det gjelder foreløpig nøkkelutveksling og ikke signaturer, men det viser at den praktiske overgangen til post-kvante-kryptografi har begynt for lengst, ikke bare på papiret.

Hvorfor endte NIST opp med to konkurrerende signaturstandarder?

Svaret ligger i selve historien til NISTs PQC-standardiseringsprosess, som startet allerede i 2016 og gikk gjennom flere runder med offentlig kryptoanalyse før noen algoritmer ble kåret til vinnere. Både Dilithium og Falcon overlevde alle rundene og ble valgt som signaturvinnere i juli 2022, sammen med SPHINCS+ som en tredje, mer konservativ reserveløsning bygget på hashfunksjoner i stedet for gitterproblemer.

Poenget med å velge to gitterbaserte vinnere fremfor én var bevisst. NIST ønsket en hovedalgoritme som de fleste utviklere kunne implementere trygt uten spesialkompetanse, og det ble Dilithium. Samtidig fantes det et reelt behov for en algoritme med mye mindre signaturer til enheter der hver byte koster noe, enten i strøm, minne eller nettverkskapasitet. Der falt valget på Falcon, til tross for at den er vesentlig vanskeligere å implementere korrekt. Denne arbeidsdelingen er også grunnen til at Falcon-standardiseringen (FIPS 206) har tatt lengre tid enn de tre andre. Det er ikke fordi algoritmen er dårligere matematisk, men fordi det tar lengre tid å skrive en standard som sikrer at implementeringer faktisk blir trygge i praksis.

Det finnes for øvrig en tredje signaturstandard i porteføljen, SLH-DSA (FIPS 205, bygget på SPHINCS+), som verken bygger på gitter eller NTRU, men på hashfunksjoner. Den regnes som den mest konservative av de tre, siden hashbasert kryptografi har vært studert lenger og har færre ukjente svakheter, men den er også tregest og gir de klart største signaturene. SLH-DSA er tiltenkt som en ren reserveløsning dersom det skulle dukke opp uventede svakheter i gitterbaserte konstruksjoner som Dilithium og Falcon, ikke som et konkurrerende hovedvalg.

ML-DSA (Dilithium) forklart

ML-DSA bygger på modul-gitter-problemer, nærmere bestemt Module-LWE og Module-SIS. Den matematiske konstruksjonen ligner i struktur på ML-KEM, noe som gjør det enklere for utviklere å implementere begge i samme kodebase. Algoritmen finnes i tre parametersett: Dilithium2 (sikkerhetsnivå 2), Dilithium3 (nivå 3) og Dilithium5 (nivå 5), der høyere nivå gir mer sikkerhetsmargin mot fremtidige angrep, men også større nøkler og signaturer. Vi har tidligere gått i detalj på hvordan denne algoritmen presterer mot dagens standard i saken ML-DSA vs ECDSA, der signaturstørrelsen alene vokser opptil 38 ganger sammenlignet med den eldre elliptisk kurve-baserte metoden.

Den store fordelen med Dilithium er at den unngår komplisert Gauss-sampling og andre operasjoner som er vanskelige å gjøre sikre mot sidekanalangrep. Det gjør den til et tryggere valg for team uten dyp spesialkompetanse på kryptografisk implementering. En studie på post-kvante-signaturer i IoT-maskinvare, publisert av SciTePress i 2025, fant at Dilithium hadde raskest utførelsestid av de testede algoritmene. Det er en av grunnene til at NIST anbefaler ML-DSA som standardvalg for de fleste generelle bruksområder, fra TLS-sertifikater til kodesignering.

Dilithium er også algoritmen NIST har satt opp mot den hash-baserte reserveløsningen SLH-DSA (SPHINCS+), som vi dekket i ML-DSA vs SLH-DSA. Der SLH-DSA er tregere, men bygger på en matematisk enklere og mer konservativ sikkerhetsantagelse, gir Dilithium et bedre kompromiss mellom hastighet og signaturstørrelse for de fleste vanlige bruksområder. Denne kombinasjonen av moden standardisering, forutsigbar ytelse og lav implementeringsrisiko er hovedgrunnen til at ML-DSA regnes som selve ryggraden i NISTs post-kvante-portefølje for signaturer.

FN-DSA (Falcon) forklart

Falcon henter sikkerheten sin fra NTRU-gitter, en annen matematisk struktur enn Dilithium. Navnet FN-DSA kommer fra bruken av rask Fourier-transformasjon (FFT) i signeringsprosessen, kombinert med NTRU-baserte gitterproblemer. Falcon finnes i to hovedvarianter: Falcon-512 (sikkerhetsnivå 1) og Falcon-1024 (nivå 5). NTRU-gitter er ikke et nytt konsept i post-kvante-sammenheng. Vi har tidligere sett hvordan den samme matematiske familien brukes på nøkkelutvekslingssiden i saken ML-KEM vs NTRU, der NTRU var opptil 29 ganger tregere på nøkkelgenerering enn Kyber-baserte ML-KEM.

Falcons klart største salgsargument er signaturstørrelsen. Fordi konstruksjonen er mer kompakt matematisk, blir signaturene betydelig mindre enn Dilithiums ved sammenlignbare sikkerhetsnivåer. Prisen for dette er implementeringskompleksitet. Falcon krever presis flyttallsaritmetikk og sofistikert Gauss-sampling for å unngå at private nøkler lekker gjennom sidekanaler, noe flere standardiseringskommentarer i 2026 peker på som en vedvarende utfordring for utviklere som skal bygge produksjonsklare biblioteker. Det er også hovedårsaken til at FIPS 206 har tatt lengre tid å ferdigstille enn de tre andre PQC-standardene. NISTs egen statusside for PQC-standardiseringen bekrefter at FIPS 206 fortsatt er under arbeid, mens de tre andre allerede er offisielt publiserte standarder.

Falcon deler også et slektskap med hybride sertifikatløsninger som allerede finnes i produksjon. Flere sertifikatmyndigheter tester nå kombinasjoner av klassiske og post-kvante-signaturer i samme sertifikatkjede, en tilnærming beskrevet i detalj av sikkerhetsselskapet EverTrust i deres gjennomgang av hybride post-kvante-sertifikater. Falcons kompakte signaturer gjør denne typen hybridkjeder mer praktiske å håndtere enn om man hadde brukt Dilithium alene, siden totalstørrelsen på sertifikatkjeden holder seg lavere.

Falcon vs Dilithium: spesifikasjonene side om side

Tabellen under samler nøkkeltallene for begge algoritmene, hentet fra NIST-dokumentasjonen og en sammenligningsanalyse publisert av H33 tidlig i 2026. Den gir et raskt overblikk over hvor de to skiller seg, og hvor de faktisk ligner hverandre.

EgenskapML-DSA (Dilithium)FN-DSA (Falcon)
NIST-standardFIPS 204 (ferdig, aug. 2024)FIPS 206 (utkast, ventet 2027)
Matematisk grunnlagModule-LWE / Module-SISNTRU-gitter
Opprinnelig navnCRYSTALS-DilithiumFalcon
ParametersettDilithium2, Dilithium3, Dilithium5Falcon-512, Falcon-1024
Sikkerhetsnivå (laveste)Nivå 2 (Dilithium2)Nivå 1 (Falcon-512)
Signatur, laveste nivå≈ 2 420 byte≈ 666 byte
Signatur, høyeste nivå≈ 3 293 byte (Dilithium3)≈ 1 280 byte (Falcon-1024)
Offentlig nøkkelCa. 1,3–2,6 kBCa. 0,9–1,8 kB
SigneringshastighetRaskest i SciTePress IoT-test (2025)Balanserer hastighet og minnebruk
ImplementeringskompleksitetLav til moderatHøy (flyttall, Gauss-sampling)
Sidekanal-risikoLavere, enklere å herdeHøyere, krever spesialkompetanse
Anbefalt brukGenerelle signaturer, TLS, kodesigneringFastvare, smartkort, båndbredde-kritiske systemer

Legg merke til at sikkerhetsnivåene ikke er direkte sammenlignbare rad for rad. Dilithium2 tilsvarer NIST-nivå 2, mens Falcon-512 tilsvarer nivå 1, som er noe lavere. Falcon er likevel den algoritmen som oftest trekkes frem som mest kompakt, siden selv Falcon-1024 på nivå 5 gir mindre signaturer enn Dilithium2 på nivå 2.

Hvor passer ML-KEM og nøkkelutveksling inn i bildet?

Det er lett å blande sammen signaturalgoritmer med nøkkelutveksling, men de to løser forskjellige oppgaver i et sikkert system. ML-DSA og FN-DSA brukes til å bevise hvem som har sendt eller signert noe. ML-KEM, som vi omtalte i sammenligningen ML-KEM vs HQC, brukes i stedet til å etablere en delt hemmelig nøkkel mellom to parter, altså selve krypteringsdelen av forbindelsen.

I praksis dukker begge opp i samme TLS-forbindelse. Klienten og serveren bruker gjerne en hybrid av klassisk elliptisk kurve-kryptografi og ML-KEM for selve nøkkelutvekslingen, en tilnærming vi beskrev i detalj i ECDHE vs RSA, mens sertifikatene som bekrefter serverens identitet til slutt må signeres med enten RSA, ECDSA, eller etter hvert ML-DSA og FN-DSA. Det betyr at en fullstendig post-kvante-sikker TLS-forbindelse krever fremskritt på begge fronter samtidig, ikke bare på én av dem. Foreløpig er det nøkkelutvekslingsdelen som har kommet lengst i faktisk utrulling, mens signatursiden med ML-DSA og FN-DSA fortsatt er i tidlig produksjonsfase hos de fleste sertifikatmyndigheter.

Signaturstørrelse i praksis: hva betyr byte-forskjellen?

På papiret ser 2 420 byte mot 666 byte ut som en akademisk detalj. I praksis er forskjellen stor nok til å avgjøre om et prosjekt i det hele tatt kan bruke post-kvante-signaturer. Et TLS-håndtrykk med flere ML-DSA-signaturer i sertifikatkjeden kan fort legge på flere kilobyte ekstra data per tilkobling. For en vanlig nettleser med god båndbredde er dette knapt merkbart. For en IoT-sensor som sender data over et smalt LPWAN-nett, eller et smartkort med noen få kilobyte minne totalt, kan den samme økningen gjøre løsningen ubrukelig.

Ta et typisk sertifikatkjede-scenario med tre nivåer: rot, mellomliggende og sluttbrukersertifikat. Med Dilithium3 kan hver signatur i kjeden veie rundt 3 293 byte, noe som gir en samlet signaturmengde på nærmere 10 kilobyte bare for signaturdelen, før man i det hele tatt regner med selve nøklene. Bytter man til Falcon-1024 på samme nivå, faller den summen til under 4 kilobyte. For en enkelt nettsideinnlasting er forskjellen marginal, men multiplisert med millioner av daglige TLS-håndtrykk hos en stor tjenesteleverandør blir det en betydelig mengde ekstra nettverkstrafikk og prosesseringstid.

Falcons komprimerte signaturer løser nettopp dette problemet. En Falcon-512-signatur på 666 byte er om lag 3,5 ganger mindre enn en Dilithium2-signatur, ifølge sammenligningstallene fra H33. For produsenter av SIM-kort, eID-brikker og fastvaresignering er denne forskjellen ofte utslagsgivende, uavhengig av at Falcon er vanskeligere å implementere trygt. Samtidig advarer flere kilder mot å velge Falcon bare fordi den er liten. Hvis teamet ditt ikke har erfaring med konstant-tid-implementering av flyttalloperasjoner, kan et Falcon-bibliotek med subtile feil bli et større sikkerhetsproblem enn et par ekstra kilobyte trafikk noensinne ville vært.

Ytelse-benchmarks fra tre kilder

Det finnes foreløpig få store, uavhengige ytelsesstudier som sammenligner Falcon og Dilithium direkte på samme maskinvare. Tabellen under samler de mest konkrete funnene fra tre forskjellige kilder publisert i 2025 og 2026.

KildeFunn om Dilithium (ML-DSA)Funn om Falcon (FN-DSA)
SciTePress, IoT-signaturstudie (2025)Raskest utførelsestid av de testede PQC-signaturalgoritmene på IoT-maskinvareBalanserer hastighet og minneeffektivitet, også på høyere sikkerhetsnivå
H33, algoritmesammenligning (2026)Signatur 2 420–3 293 byte avhengig av nivåSignatur 666–1 280 byte avhengig av nivå, konsekvent minst
QubitChain, NIST PQC-statusrapport (2026)Fullt ferdigstilt standard (FIPS 204), moden verktøystøtteFortsatt i utkast (FIPS 206), venter finalisering i 2027

Det gjennomgående bildet fra alle tre kildene er at Dilithium vinner på modenhet og rå hastighet, mens Falcon vinner på størrelse. Ingen av kildene rapporterer at Falcon er tregere i et omfang som gjør den ubrukelig. Det er heller snakk om at Dilithium er det tryggere og mer forutsigbare valget når du ikke har spesifikke båndbreddebegrensninger å løse.

Det er verdt å understreke at disse tre kildene måler litt forskjellige ting: SciTePress-studien tester faktisk kjøretid på reell IoT-maskinvare, H33 sammenligner strukturelle egenskaper som byte-størrelse direkte fra NIST-spesifikasjonene, og QubitChain rapporterer på standardiseringsstatus fremfor rå ytelse. Til sammen gir de likevel et konsistent bilde: ingen av kildene motsier hverandre om hvilken algoritme som er raskest eller mest kompakt, selv om de måler ulike aspekter av sammenligningen.

Implementeringskompleksitet og sidekanal-risiko

Dette er trolig det viktigste, og mest oversette, punktet i hele sammenligningen. En algoritme kan ha perfekte tall på papiret og likevel bli et sikkerhetshull i praksis hvis implementeringen lekker informasjon gjennom tidsbruk, strømforbruk eller cache-mønstre.

Dilithium bruker heltallsaritmetikk i moduler, en operasjonstype de fleste kryptografiske utviklere allerede kjenner fra RSA og elliptisk kurve-kryptografi. Det gjør det enklere å skrive konstant-tid-kode som ikke avslører hemmeligheter gjennom sidekanaler. Falcon, derimot, er avhengig av flyttallsberegninger via FFT og en form for Gauss-sampling som er notorisk vanskelig å implementere uten tidsvariasjon. Flere standardiseringskommentarer fra 2026 peker på nettopp dette som årsaken til at gode, herdede Falcon-biblioteker har tatt lengre tid å modnes enn Dilithium-biblioteker, og at det er en direkte medvirkende årsak til at FIPS 206 fortsatt ikke er ferdigstilt.

For en organisasjon uten egen kryptografiingeniør er anbefalingen fra de fleste migreringsguider i 2026 entydig: bruk et etablert, revidert bibliotek som liboqs fra Open Quantum Safe-prosjektet, og ikke skriv egen Falcon-implementering fra bunnen av. Det samme gjelder i noe mindre grad for Dilithium, men risikoen ved feil er lavere der konstruksjonen i utgangspunktet er enklere å gjøre riktig.

Et konkret eksempel på hvor mye kompleksitet som ligger skjult i Falcon, er at referanseimplementeringen bruker doble flyttall (double-precision) i signeringsprosessen for å oppnå den nødvendige presisjonen i Gauss-samplingen. Enhver avvik i avrunding, timing eller minnetilgang under denne prosessen kan i verste fall lekke deler av den private nøkkelen over tid, gjennom det som kalles et sidekanalangrep. Dilithiums heltallsbaserte tilnærming har rett og slett færre steder der slike lekkasjer kan oppstå, noe som er hovedgrunnen til at den regnes som det tryggere standardvalget for team uten dedikert kryptografikompetanse.

Kostnad og infrastruktur ved overgang til post-kvante-signaturer

Selve algoritmene koster ingenting i lisens. Både ML-DSA og FN-DSA ble valgt av NIST nettopp fordi de er royaltyfrie og åpent spesifisert, i tråd med NISTs krav til alle kandidater i PQC-konkurransen. Den reelle kostnaden ligger et annet sted: i utviklingstid, testing, maskinvarestøtte og eventuell resertifisering av systemer som må gjennom FIPS-validering. For de fleste IT-budsjetter er det denne skjulte arbeidskostnaden, ikke lisenser eller maskinvare, som ender opp med å dominere regnestykket når migrasjonen faktisk planlegges.

KostnadspostML-DSA (Dilithium)FN-DSA (Falcon)
Lisenskostnad for algoritmenIngen (royaltyfri NIST-standard)Ingen (royaltyfri NIST-standard)
Åpen kildekode-bibliotekerModne (liboqs, PQClean, OpenSSL oqs-provider)Tilgjengelige, men mindre utbredt testet i produksjon
Behov for spesialkompetanseLavt til moderatHøyt (konstant-tid flyttallsimplementering)
Sertifiseringsstatus (FIPS)Kan FIPS-valideres nå (FIPS 204 er ferdig)Kan ikke fullt ut FIPS-valideres før FIPS 206 ferdigstilles
Båndbreddekostnad ved skaleringHøyere per signatur, men forutsigbarLavere per signatur, reduserer datavolum i stor skala
Tidshorisont for produksjonsklar brukNåTrolig fra 2027, når FIPS 206 er endelig

Konklusjonen fra denne tabellen er ganske grei: hvis budsjettet og tidsplanen krever at noe skal i produksjon i år, er ML-DSA det eneste reelle alternativet med full standardstøtte akkurat nå. Falcon kan fortsatt tas i bruk før FIPS 206 er endelig, men da uten formell FIPS-validering, noe som er en showstopper for mange offentlige anskaffelser og regulerte bransjer i Norge og EU.

Vanlige feil bedrifter gjør under migreringen

Den vanligste feilen er å behandle post-kvante-migrasjon som en ren biblioteksoppdatering, altså å bytte ut én signaturfunksjon med en annen og anta at resten av systemet fungerer som før. I praksis endrer både ML-DSA og FN-DSA størrelsen på nøkler, sertifikater og nettverkspakker så mye at fastsatte grenser i eldre systemer, som maksimal TLS-rekordstørrelse eller faste bufferstørrelser i innebygd programvare, kan brytes uten varsel.

Den nest vanligste feilen er å velge Falcon utelukkende på grunn av signaturstørrelsen, uten å ha kapasitet til å verifisere at implementeringen faktisk kjører i konstant tid. Flere 2026-kilder peker på at useriøse eller uferdige Falcon-implementeringer i praksis kan være mindre sikre enn en godt testet Dilithium-løsning, selv om Falcon på papiret gir bedre komprimering. Den tredje fellen er å utsette hele migrasjonen fordi FIPS 206 ikke er ferdig, i stedet for å starte med ML-DSA nå og legge til Falcon som et senere tillegg der det faktisk trengs.

Fem eksempler på post-kvante-signaturer i praksis

  • Nettleser- og CDN-økosystemet. Google Chrome, Cloudflare og Akamai har allerede rullet ut hybrid X25519+ML-KEM i TLS-håndtrykk i internett-skala. Det gjelder nøkkelutveksling, ikke signaturer, men samme aktører peker på ML-DSA som det naturlige neste steget for sertifikatsignering når biblioteker og infrastruktur er klare. Skalaen her er verdt å merke seg: dette er ikke pilotprosjekter hos noen få kunder, men infrastruktur som allerede håndterer en betydelig andel av verdens daglige nettrafikk.
  • Signal. Meldingsappen er blant tjenestene som har innført post-kvante-beskyttet nøkkelutveksling i produksjon, og illustrerer at PQC-migrasjon ikke lenger er et forskningsprosjekt, men noe brukere allerede drar nytte av uten å merke det. Samme mønster, stille utrulling uten at sluttbrukeren merker noe, er trolig det norske virksomheter også bør sikte mot når de etter hvert innfører ML-DSA i egne systemer.
  • Amerikansk statsforvaltning. Presidentordren fra juni 2025 om PQC-migrasjon for føderale systemer, med NSS-frister fra januar 2027, gjør USAs offentlige sektor til et av de største case-studiene på tvungen overgang til ML-DSA og ML-KEM i stor skala. Erfaringene derfra, om alt fra budsjettering til leverandørkrav, vil trolig prege hvordan europeiske og nordiske myndigheter utformer sine egne krav i årene som kommer.
  • Blokkjede-plattformer som avventer. Enkelte kryptoplattformer, deriblant SynX-plattformen omtalt av SynXCrypto, har allerede integrert ML-KEM (Kyber-768) for nøkkelinnkapsling, men har bevisst utsatt innføringen av ML-DSA-signaturer i påvente av mer moden økosystemstøtte. Det viser at selv teknisk avanserte miljøer velger å vente på biblioteker og verktøy fremfor å hoppe på standarden dag én.
  • Fastvare- og smartkortindustrien. Migreringsguider fra 2026 peker gjentatte ganger på fastvaresignering og SIM-/eID-kort som det klareste bruksområdet der Falcons kompakte signaturer rettferdiggjør den ekstra implementeringsrisikoen, fordi disse enhetene rett og slett ikke har plass til Dilithium-signaturer i samme skala.

Hva betyr dette for Norge og Norden?

Norske og nordiske virksomheter følger i stor grad de samme standardiseringssporene som resten av Europa og USA, siden NIST-standardene er de facto-referansen som ETSI og europeiske sertifiseringsordninger bygger videre på. Det betyr at et valg mellom ML-DSA og FN-DSA i en norsk bank, et departement eller en telekomaktør i praksis er det samme valget som beskrevet i denne artikkelen, bare med lokale krav til revisjon og databehandling lagt oppå.

For sektorer med lange sertifiseringsløp, som finans og offentlig forvaltning, er det argumentet for ML-DSA ekstra sterkt: en algoritme som allerede er ferdig standardisert lar seg føre gjennom interne godkjenningsprosesser uten å vente på at FIPS 206 blir endelig. For norske produsenter av IoT-utstyr, målere og industrisensorer, der eksportmarkedet ofte er større enn hjemmemarkedet, kan derimot Falcons kompakte signaturer bli avgjørende for om post-kvante-sikkerhet i det hele tatt er praktisk mulig innenfor eksisterende maskinvarebudsjetter. Vi har tidligere pekt på det samme grunnleggende presset i artikkelen om Bitcoins kvantetrussel, der lagringsplass og signaturstørrelse også er en direkte kostnad, bare i en annen kontekst.

Slik genererer du nøkler med begge algoritmene

Med OpenSSL 3.x og oqs-provider fra Open Quantum Safe-prosjektet kan du generere testsertifikater med begge algoritmene for å sammenligne størrelse og ytelse lokalt før du bestemmer deg.

# Generer et selvsignert testsertifikat med ML-DSA (Dilithium, nivå 3)
openssl req -x509 -new -newkey mldsa65 \
  -keyout mldsa.key -out mldsa.crt \
  -days 30 -nodes -subj "/CN=test-mldsa"

# Generer et selvsignert testsertifikat med FN-DSA (Falcon-512)
openssl req -x509 -new -newkey falcon512 \
  -keyout falcon.key -out falcon.crt \
  -days 30 -nodes -subj "/CN=test-falcon"

# Sammenlign filstørrelsen på de utstedte sertifikatene
ls -la mldsa.crt falcon.crt

Kjør begge kommandoene på samme maskin, og sammenlign både genereringstid og filstørrelse på de resulterende sertifikatene. Dette gir et raskt, konkret inntrykk av forskjellene beskrevet i tabellene over, tilpasset akkurat den maskinvaren og OpenSSL-versjonen dere faktisk bruker i produksjon. Legg spesielt merke til at nøkkelgenereringen for Falcon typisk tar merkbart lengre tid enn for ML-DSA på vanlig serverutstyr, nettopp på grunn av den mer krevende Gauss-samplingen. Dette er verdt å teste tidlig dersom løsningen skal generere mange nøkler samtidig, for eksempel ved utstedelse av sertifikater til et stort antall enheter.

Migrasjonsguide: fra RSA/ECDSA til post-kvante-signaturer

Overgangen bør planlegges som et prosjekt over flere kvartaler, ikke som en enkeltstående oppgradering. De fleste organisasjoner undervurderer hvor mange steder RSA og ECDSA faktisk brukes internt, fra interne API-nøkler til gamle batch-jobber som signerer rapporter. Under er en praktisk rekkefølge basert på migreringsguidene fra NIST og bransjeaktører i 2025 og 2026.

  1. Kartlegg hvor RSA og ECDSA brukes i dag: TLS-sertifikater, kodesignering, dokumentsignaturer og interne API-er.
  2. Klassifiser systemene etter hvor følsomme de er for “harvest now, decrypt later”-angrep, altså der data må forbli konfidensielle i mange år fremover.
  3. Installer og test et modent PQC-bibliotek, som liboqs eller OpenSSLs oqs-provider, i et isolert testmiljø.
  4. Start med hybridløsninger, altså RSA/ECDSA kombinert med ML-DSA, slik at eksisterende klienter fortsatt fungerer under overgangen.
  5. Velg ML-DSA som standard for de fleste signaturbehov, siden den allerede er FIPS-validerbar og har mest moden verktøystøtte.
  6. Reservér Falcon (FN-DSA) kun til systemer med dokumentert plass- eller båndbreddebegrensning, og bruk et revidert bibliotek fremfor egen implementering.
  7. Test ytelse og signaturstørrelse under realistisk last, ikke bare i isolerte benchmarks.
  8. Oppdater sertifikatutstedelse, HSM-er og nøkkelhåndteringssystemer til å støtte de nye algoritmene.
  9. Følg med på ferdigstillelsen av FIPS 206 dersom Falcon inngår i planen, siden formell sertifisering kan påvirke offentlige anskaffelser.
  10. Sett en konkret sluttdato for utfasing av rene RSA/ECDSA-signaturer, i tråd med interne krav eller regulatoriske frister.
  11. Dokumenter hele migrasjonen for revisjon, spesielt i regulerte sektorer som finans og offentlig forvaltning.

Ingen av disse stegene krever at hele infrastrukturen byttes ut på én gang. Målet er en gradvis, hybrid overgang der klassisk og post-kvante-kryptografi lever side om side i en overgangsperiode som trolig varer flere år, akkurat slik hybrid ML-KEM allerede gjør i TLS-trafikken til Chrome og Cloudflare i dag.

Fordeler og ulemper med Dilithium (ML-DSA)

Fordeler: Ferdig standardisert (FIPS 204), moden verktøystøtte, raskest i uavhengige IoT-benchmarks, enklere å implementere sikkert mot sidekanalangrep, og NISTs anbefalte standardvalg for generell bruk. Den relativt enkle heltallsaritmetikken gjør det også lettere å finne utviklere med erfaring nok til å vedlikeholde løsningen over tid, siden mønstrene ligner det mange allerede kjenner fra RSA og ECDSA.

Ulemper: Betydelig større signaturer enn Falcon (2 420–3 293 byte), noe som kan bli en flaskehals i båndbredde- eller lagringsbegrensede systemer, samt økt datavolum ved storskala sertifikatutstedelse. For enheter med hard grense på minne eller nettverkskapasitet kan denne størrelsesøkningen alene gjøre Dilithium upraktisk, uavhengig av hvor moden verktøystøtten ellers er.

Fordeler og ulemper med Falcon (FN-DSA)

Fordeler: Klart minst signaturer av de to (ned mot 666 byte på laveste nivå), gjør PQC praktisk mulig for smartkort, SIM-kort og fastvaresignering, og gir lavere langsiktig båndbreddekostnad i stor skala. For produkter som sendes ut i millioner av enheter, kan den lavere datamengden per signatur også gi reelle besparelser på strømforbruk og radiobruk i trådløse enheter.

Ulemper: Standarden (FIPS 206) er fortsatt i utkast og forventes ikke ferdig før 2027, implementeringen er vesentlig mer krevende på grunn av flyttallsaritmetikk og Gauss-sampling, og risikoen for sidekanalfeil er høyere uten spesialisert kompetanse. Mangelen på en ferdig FIPS-standard gjør den også vanskelig å velge i anskaffelser som krever formell sertifisering, uansett hvor gode de tekniske egenskapene ellers er.

Hvem bør velge hva? Fem konkrete anbefalinger

  • Offentlig sektor og PKI-utstedere: Velg ML-DSA som standard, siden den allerede kan FIPS-valideres og passer inn i eksisterende anskaffelseskrav. Vent med Falcon til FIPS 206 er ferdig, med mindre et konkret delsystem krever den kompakte signaturstørrelsen.
  • Banker og finansaktører med sertifikatinfrastruktur: Start hybridmigrasjon med ML-DSA nå, og vurder Falcon kun for spesifikke, båndbreddekritiske delsystemer senere. Bruk overgangsperioden til å teste hvordan de større signaturene påvirker eksisterende meldingsformater og batch-jobber.
  • IoT- og sensorprodusenter: Vurder Falcon der enheten har svært begrenset minne eller båndbredde, men bruk et ferdig revidert bibliotek, ikke egen kode. Test strømforbruket til signeringsoperasjonen spesifikt, siden Falcons flyttallsberegninger kan belaste batteridrevet maskinvare annerledes enn Dilithiums heltallsoperasjoner.
  • Fastvare- og smartkortleverandører: Falcons kompakte signaturer er ofte eneste realistiske vei til post-kvante-sikkerhet innenfor eksisterende maskinvarebegrensninger. Planlegg likevel for at formell sertifisering kan komme senere enn selve implementeringen.
  • Skytjenester og API-plattformer: Hold dere til ML-DSA inntil videre, siden den gir forutsigbar ytelse og allerede støttes av modne biblioteker som OpenSSLs oqs-provider. Dette er også valget som krever minst spesialkompetanse å drifte over tid.

Hva skjer når FIPS 206 endelig blir ferdig?

Når NIST ferdigstiller FIPS 206, trolig en gang i 2027 ifølge flere fagkilder, endrer ikke det de tekniske egenskapene til Falcon i seg selv. Algoritmens matematikk er allerede låst, og har vært det siden den ble kåret til vinner i 2022. Det som endrer seg er den formelle statusen: byråkrati og anskaffelser som krever en ferdig FIPS-standard får da grønt lys til å inkludere Falcon på lik linje med ML-DSA og ML-KEM.

Det mest realistiske scenarioet er at bibliotekstøtten og produksjonserfaringen med Falcon fortsetter å modnes i denne ventetiden, slik at algoritmen står klar til bruk i det øyeblikket standarden er signert. Flere åpen kildekode-prosjekter, deriblant Open Quantum Safe, har allerede fungerende Falcon-implementeringer tilgjengelig i dag, nettopp for å unngå at hele bransjen må starte fra null når FIPS 206 til slutt kommer. For organisasjoner som planlegger langsiktig, er det fornuftig å begynne å teste Falcon i ikke-kritiske systemer allerede nå, selv om den formelle sertifiseringen ligger et år eller mer frem i tid.

Verdikt: hvilken algoritme vinner i 2026?

Det finnes ikke ett riktig svar, men det finnes et klart standardvalg. For de aller fleste organisasjoner som skal begynne migrasjonen til post-kvante-signaturer i 2026, er ML-DSA (Dilithium) det tryggeste valget. Den er ferdig standardisert, raskest i uavhengige tester, og enklere å implementere uten å introdusere nye sidekanalsårbarheter. NISTs egne migreringsguider peker samme vei, og det gjør den til default-anbefalingen i så godt som alle 2026-oversikter vi har gått gjennom.

FN-DSA (Falcon) vinner likevel der det faktisk teller mest for et konkret sett brukstilfeller: enheter med hard grense på minne, båndbredde eller lagringsplass. En signatur på 666 byte mot 2 420 byte er ikke en marginal forbedring, det er forskjellen mellom et prosjekt som er praktisk gjennomførbart og et som ikke er det. Prisen er en betydelig høyere implementeringsrisiko og en standard som ennå ikke er formelt ferdigstilt. Til den avveiningen er praktisk kunnskap om egne systemer viktigere enn noe generelt råd, inkludert dette.

Sett i sammenheng med resten av NISTs post-kvante-portefølje, fra ML-KEM på nøkkelutvekslingssiden til SLH-DSA som konservativ reserve, er ML-DSA og FN-DSA to verktøy som utfyller hverandre mer enn de konkurrerer. De fleste organisasjoner trenger trolig begge før 2030-tallet er omme, bare til forskjellige deler av infrastrukturen. Det viktigste er å ikke la usikkerheten om hvilken som er “best” bli en unnskyldning for å utsette hele migrasjonen.

Ofte stilte spørsmål

Er Falcon og Dilithium det samme som FN-DSA og ML-DSA?
Ja. Dilithium og Falcon er de opprinnelige navnene fra NISTs PQC-konkurranse. ML-DSA er det offisielle navnet i FIPS 204, mens FN-DSA er navnet som brukes i utkastet til FIPS 206.

Kan jeg bruke Falcon i produksjon allerede nå?
Teknisk sett ja, gjennom biblioteker som liboqs, men uten formell FIPS-validering siden FIPS 206 fortsatt er et utkast. For regulerte bransjer bør dere vente på ferdigstillelsen, ventet i 2027.

Hvorfor er Falcon vanskeligere å implementere enn Dilithium?
Falcon krever presis flyttallsaritmetikk og Gauss-sampling som er vanskelig å kjøre i konstant tid. Dilithium bruker enklere heltallsaritmetikk i moduler, som er lettere å herde mot sidekanalangrep.

Hvilken algoritme anbefaler NIST som standard?
NIST peker på ML-DSA (Dilithium) som hovedvalget for generelle digitale signaturer, mens FN-DSA (Falcon) er tiltenkt en nisjerolle for båndbredde- og lagringskritiske systemer.

Påvirker dette vanlige norske brukere med det samme?
Ikke direkte ennå. Endringen skjer først i infrastrukturen, hos nettlesere, CDN-er, banker og det offentlige. Effekten for sluttbrukere er i praksis usynlig, på samme måte som overgangen til HTTPS var det for de fleste.

Må vi bytte ut RSA og ECDSA umiddelbart?
Nei, men planlegging bør starte nå. Migreringsguidene fra 2025 og 2026 anbefaler hybridløsninger som kombinerer klassisk og post-kvante-kryptografi i en overgangsperiode, fremfor et brått, fullstendig bytte.

Hva skjer når kvantedatamaskiner faktisk blir kraftige nok til å knekke RSA?
Systemer som fortsatt kun bruker RSA eller ECDSA på det tidspunktet vil være sårbare for forfalskede signaturer. Det er nettopp derfor NIST og flere lands myndigheter, deriblant USA gjennom presidentordren fra juni 2025, presser på for migrasjon lenge før en slik kvantedatamaskin faktisk eksisterer.

Er ML-KEM det samme som ML-DSA?
Nei. ML-KEM (FIPS 203, bygget på Kyber) brukes til nøkkelinnkapsling, altså å etablere en delt hemmelighet mellom to parter. ML-DSA (FIPS 204, bygget på Dilithium) brukes til digitale signaturer. De løser forskjellige problemer, men brukes ofte sammen i samme system.

Kan Falcon og Dilithium brukes samtidig i samme system?
Ja, og det er faktisk vanlig i hybride sertifikatoppsett. Et system kan for eksempel bruke ML-DSA for de fleste sertifikater, men Falcon for en spesifikk komponent som en fastvareoppdatering, der signaturstørrelsen er kritisk.

Hvilken betydning har dette for kryptovaluta og blokkjeder?
Flere blokkjedeplattformer har begynt å integrere ML-KEM for nøkkelinnkapsling, men er mer forsiktige med å innføre ML-DSA-signaturer fordi de endrer transaksjonsstørrelsen betydelig. Vi har sett lignende avveininger mellom sikkerhet og datamengde i vår gjennomgang av Bitcoins kvantetrussel.

Hva bør jeg gjøre helt konkret denne uken?
Start med å kartlegge hvor RSA og ECDSA faktisk brukes i systemene deres, og test ML-DSA i et isolert testmiljø med et etablert bibliotek som liboqs. Det gir et konkret grunnlag for å planlegge resten av migrasjonen, uten å måtte ta stilling til Falcon før dere faktisk støter på et system med en reell båndbredde- eller lagringsbegrensning.