Når NIST valgte HQC i mars 2025 som reservealgoritme for kodebasert nøkkelinnkapsling, endte samtidig en 20 år lang diskusjon om hva som skal skje med Classic McEliece. Algoritmen har stått uslått i nesten 45 år uten et eneste praktisk gjennombrudd mot kjernesikkerheten, men den tapte likevel kappløpet om en NIST-standard. Grunnen er brutalt enkel: den offentlige nøkkelen er for stor til å passe inn i moderne protokoller. Denne artikkelen går gjennom hva forskjellen egentlig betyr i praksis, med konkrete tall for nøkkelstørrelse, ytelse og hvilken algoritme som passer hvilket bruksområde.
Begge algoritmene bygger på kodebasert kryptografi, en matematisk tilnærming som er fundamentalt annerledes enn de gitterbaserte konstruksjonene bak ML-KEM (tidligere Kyber). Det gjør dem attraktive som “plan B” dersom gitterbasert kryptografi en dag skulle vise seg sårbar. Samtidig er de to algoritmene nesten speilbilder av hverandre: Classic McEliece har enorme offentlige nøkler og mikroskopiske chiffertekster, mens HQC har små nøkler og relativt store chiffertekster. Hvilken du bør velge avhenger helt av hva systemet ditt faktisk flytter mest av.
Hva er Classic McEliece og HQC, og hvorfor sammenligne dem
Classic McEliece er en nøkkelinnkapslingsmekanisme (KEM) bygget på binære Goppa-koder, opprinnelig beskrevet av Robert McEliece i 1978. Det gjør den til den eldste kryptosystem-konstruksjonen som fremdeles regnes som et seriøst kandidat for post-kvante-sikkerhet. Styrken ligger i at ingen har funnet en praktisk strukturell svakhet i de fire tiårene algoritmen har eksistert, noe svært få kryptografiske konstruksjoner kan skilte med.
HQC (Hamming Quasi-Cyclic) er en nyere konstruksjon som også bygger på feilkorrigerende koder, men med en quasi-cyklisk struktur som gjør det mulig å komprimere den offentlige nøkkelen kraftig. NIST valgte HQC i mars 2025 som et tillegg til ML-KEM, spesifikt fordi den gir et annet matematisk sikkerhetsgrunnlag enn gitterbasert kryptografi, samtidig som nøklene er praktisk håndterbare. Begge algoritmene er KEM-er, ikke signaturalgoritmer, så de løser nøkkelutveksling og ikke autentisering.
Sammenligningen er relevant nå fordi norske og nordiske virksomheter som behandler helsedata, finansdata eller langtidsarkiver må begynne å planlegge overgangen til kvantesikker kryptering. EUs anbefalinger og NIST sine tidslinjer legger press på at migreringen skal være i gang før 2030, og kodebasert kryptografi er det sikreste alternativet dersom gitterbaserte algoritmer som ML-KEM en dag skulle bli knekket av fremtidig kryptoanalyse.
Det finnes også en tredje kodebasert kandidat i samme NIST-runde, BIKE, som ble vurdert side om side med både Classic McEliece og HQC. BIKE hadde en annen avveining enn begge de to andre: moderate nøkkelstørrelser og lav innkapslingskostnad, men NIST valgte til slutt å kutte BIKE fra videre standardisering i favør av HQC. Det gjør sammenligningen mellom Classic McEliece og HQC spesielt relevant nettopp nå, siden det er disse to som er igjen som de reelle kodebaserte alternativene til ML-KEM, mens BIKE i praksis er lagt til side som produksjonskandidat.
Post-kvantekryptografi: hvorfor det haster akkurat nå
Trusselen fra kvantedatamaskiner er ikke at de knekker kryptering i dag. Trusselen er “harvest now, decrypt later”: en angriper kan lagre kryptert trafikk nå og dekryptere den når en stor nok kvantedatamaskin finnes. For data som må forbli konfidensielt i 20-30 år, som pasientjournaler, rettsdokumenter eller statlige arkiver, er dette allerede et akutt problem, ikke et fremtidig ett.
NIST har standardisert ML-KEM (FIPS 203) som hovedvalget for nøkkelutveksling, og ML-DSA samt SLH-DSA for signaturer. Men en enkelt matematisk familie som eneste forsvarslinje er risikabelt. Dersom det dukker opp et strukturelt angrep mot gitterbaserte problemer, trenger verden en reserve som bygger på en helt annen matematisk vanskelighetsgrad. Det er nøyaktig den rollen Classic McEliece og HQC er tiltenkt: begge bygger på vanskeligheten av å dekode tilfeldige lineære koder, et problem som har vært studert i over 50 år uten et kvantealgoritme-gjennombrudd tilsvarende Shors algoritme for faktorisering.
Det tyske sikkerhetsdirektoratet BSI har vært tydelig på at kodebaserte alternativer bør holdes i beredskap parallelt med gitterbasert kryptografi. I sine notater om Classic McEliece skriver BSI at man for nøkkelutveksling bør bruke “FrodoKEM, ML-KEM eller HQC (når den tilhørende standarden er publisert)”, og understreker samtidig at HQC-skjemaet, som er planlagt anbefalt i fremtiden, ikke er påvirket av samme typer angrep som har vært diskutert for andre kodebaserte konstruksjoner, selv om det også bygger på feilkorrigerende koder (BSI, notater om Classic McEliece).
Classic McEliece: 45 år gammel kodebasert kryptering
Classic McEliece-prosjektet, som blant andre ledes av kryptograf Daniel J. Bernstein, har som mål å levere mer enn bare grunnleggende ettveissikkerhet. Bernstein har formulert det presist: Classic McEliece er designet for å stoppe angrep med valgt chiffertekst, et sterkere sikkerhetsmål enn den opprinnelige McEliece-konstruksjonen fra 1978 hadde (cr.yp.to, McEliece-standardisering).
Den praktiske konsekvensen av dette designvalget er en offentlig nøkkel på 261.120 byte ved det laveste sikkerhetsnivået, og over 1,3 millioner byte ved det høyeste. Til gjengjeld er chifferteksten bare 96 til 208 byte, uansett sikkerhetsnivå. Det gjør Classic McEliece til en av de mest ekstreme asymmetriske konstruksjonene som finnes: nesten all kostnaden ligger i nøkkelen, og nesten ingenting i selve den krypterte meldingen.
Nøkkelgenerering er samtidig den klart tyngste operasjonen i Classic McEliece. NIST sin statusrapport fra fjerde runde i PQC-prosessen slår fast at nøkkelgenerering i Classic McEliece er en uteligger, og er “tre størrelsesordener mer kostbar enn HQC” (NIST IR 8545, fjerde runde-status). Det betyr i praksis at Classic McEliece er dårlig egnet til systemer som genererer nye nøkkelpar ofte, men svært godt egnet til systemer der en nøkkel genereres én gang og gjenbrukes i lang tid, som filkryptering eller VPN-oppsett.
HQC: NISTs nye reservevalg for kodebasert kryptografi
HQC bygger på quasi-cykliske koder, en struktur som gjør det mulig å representere den offentlige nøkkelen med en enkelt kort vektor i stedet for en hel generatormatrise. Resultatet er offentlige nøkler på mellom 2.249 og 7.245 byte, avhengig av sikkerhetsnivå, altså over hundre ganger mindre enn Classic McEliece ved tilsvarende nivå.
Prisen HQC betaler for de små nøklene er en betydelig større chiffertekst: fra 4.481 byte ved nivå 1 til 14.469 byte ved nivå 5. Det er mellom 47 og 70 ganger større enn Classic McElieces chiffertekst ved samme nivå. For protokoller der nøkkelen distribueres sjelden, men mange meldinger krypteres mot den, er dette en ugunstig retning. For protokoller der nøkler utveksles ofte, som moderne TLS-håndtrykk, er det derimot et akseptabelt kompromiss.
NIST sin begrunnelse for å velge HQC fremfor både Classic McEliece og BIKE var todelt: HQC gir et annet matematisk sikkerhetsgrunnlag enn gitterbasert ML-KEM, samtidig som nøklene er praktisk håndterbare i moderne infrastruktur. Samtidig er det viktig å skille mellom “valgt” og “endelig standardisert”. HQC ble valgt av NIST i mars 2025, men en ferdig FIPS-publikasjon var fortsatt ikke klar per oktober 2026, med offentlige anslag som pekte mot 2026-2027 for en fullstendig standard.
Nøkkelstørrelser og chiffertekst: den fullstendige tabellen
Tabellen under viser byte-størrelser for alle offisielle parametersett i Classic McEliece og HQC, samt ML-KEM som referanse siden det er hovedstandarden begge algoritmene er tiltenkt å støtte eller erstatte ved behov. “NIST-nivå” angir hvilket klassisk sikkerhetsnivå parametersettet tilsvarer, der nivå 1 er sammenlignbart med AES-128 og nivå 5 med AES-256.
| Algoritme / parametersett | NIST-nivå | Offentlig nøkkel | Privat nøkkel | Chiffertekst | Delt hemmelighet |
|---|---|---|---|---|---|
| mceliece348864 | 1 | 261.120 byte | 6.492 byte | 96 byte | 32 byte |
| mceliece460896 | 3 | 524.160 byte | 13.608 byte | 156 byte | 32 byte |
| mceliece6688128 | 5 | 1.044.992 byte | 13.932 byte | 208 byte | 32 byte |
| mceliece6960119 | 5 | 1.047.319 byte | 13.948 byte | 194 byte | 32 byte |
| mceliece8192128 | 5 | 1.357.824 byte | 14.080 byte | 208 byte | 32 byte |
| HQC-128 | 1 | 2.249 byte | 2.289 byte | 4.481 byte | 64 byte |
| HQC-192 | 3 | 4.522 byte | 4.586 byte | 9.026 byte | 64 byte |
| HQC-256 | 5 | 7.245 byte | 7.317 byte | 14.469 byte | 64 byte |
| ML-KEM-512 (referanse) | 1 | 800 byte | 1.632 byte | 768 byte | 32 byte |
| ML-KEM-768 (referanse) | 3 | 1.184 byte | 2.400 byte | 1.088 byte | 32 byte |
| ML-KEM-1024 (referanse) | 5 | 1.568 byte | 3.168 byte | 1.568 byte | 32 byte |
Ved nivå 1 er forholdet ekstremt: Classic McElieces offentlige nøkkel på 261.120 byte er rundt 116 ganger større enn HQC-128 sin nøkkel på 2.249 byte. Samtidig er HQC-128 sin chiffertekst på 4.481 byte omtrent 47 ganger større enn Classic McElieces 96 byte. Begge tall holder seg konsistente opp gjennom sikkerhetsnivåene, noe som bekrefter at dette er en strukturell egenskap ved algoritmene, ikke en tilfeldighet ved et enkelt parametersett.
Ytelsesbenchmarks fra tre uavhengige kilder
Ytelsestall for post-kvante-algoritmer varierer mye med prosessorarkitektur, kompilator og hvilken implementasjon som er brukt, så det er viktig å ikke blande tall fra ulike kilder i en og samme sammenligning. Her presenteres tre uavhengige kilder separat, slik at hver enkelt forblir intern konsistent.
NIST sin firedelte paneloversikt (PQC 2024)
NIST sitt eget presentasjonsmateriale fra fjerderunde-panelet om BIKE, Classic McEliece og HQC beskriver det generelle mønsteret slik: Classic McEliece har tregest nøkkelgenerering av de tre, men kompenserer med lav kostnad på innkapsling og dekapsling. Det gjør algoritmen best egnet til bruksområder der en nøkkel genereres én gang og brukes til mange krypteringsoperasjoner, som filkryptering og VPN, fremfor protokoller som forhandler nye nøkler for hver tilkobling (NIST, firerunde-kandidatpanel 2024).
Akademisk sammenligning fra CEUR Workshop Proceedings
En sammenlignende vurdering av BIKE, HQC og Classic McEliece publisert i CEUR Workshop Proceedings måler kostnadene i kilosykler ved sikkerhetsnivå 1. Her kommer det tydelig frem at Classic McEliece sin nøkkelgenerering ligger på rundt 56.706 kilosykler, markant høyere enn HQC, som i samme studie har den mest effektive nøkkelgenereringen av de testede algoritmene. BIKE kommer best ut på innkapslingskostnad i denne spesifikke studien, mens Classic McEliece henter inn fordelen igjen på dekapsling og total chiffertekst-kostnad over tid (CEUR-WS, sammenligning av BIKE, HQC og Classic McEliece).
Open Quantum Safe / liboqs referanseimplementasjoner
Open Quantum Safe-prosjektet, som distribuerer referanseimplementasjoner via liboqs og PQClean, lister Classic McEliece som en implementasjon i fellesskaps-tier under pågående ISO-vurdering, med PQClean som kildekode-opphav. HQC er tilgjengelig gjennom samme kanal. Begge algoritmene kan dermed testes og benchmarkes i identiske miljøer, noe prosjektet selv anbefaler for å unngå å blande tall fra forskjellige maskiner eller kompilatorinnstillinger (Open Quantum Safe, Classic McEliece og Open Quantum Safe, HQC).
Den samlede konklusjonen fra alle tre kilder er konsistent selv om de nøyaktige tallene varierer: Classic McEliece er tregest på nøkkelgenerering, men billigst på kryptering og dekryptering når nøkkelen først er på plass. HQC er mer balansert gjennom hele livssyklusen, men betaler for det med en større chiffertekst per operasjon.
Sikkerhetsgrunnlag: hvilken matematikk ligger bak
Begge algoritmene regnes som kodebaserte, men sikkerhetsargumentene deres er ikke identiske. Classic McEliece bygger på det klassiske “syndrome decoding”-problemet for lineære koder uten ekstra struktur, noe som gir et svært konservativt og godt studert sikkerhetsgrunnlag. HQC introduserer en quasi-cyklisk struktur for å komprimere nøkkelen, og denne strukturen gir et litt annet, og etter manges mening noe mindre konservativt, sikkerhetsargument.
Bernstein har pekt direkte på denne forskjellen: HQCs sikkerhet i den kvante-tilfeldige orakelmodellen (QROM) kan i verste fall ligge “langt under” sikkerhetsnivået til det underliggende QCSD-problemet, mens Classic McEliece har et tett sikkerhetsbevis for QROM IND-CCA2-sikkerhet, forutsatt at den grunnleggende McEliece-ettveisegenskapen holder (cr.yp.to, McEliece-standardisering). Dette er ikke et bevis på at HQC er usikker, men det er en teoretisk presisjonsforskjell som kryptografer tar med i vurderingen når de velger hvilken algoritme å stole mest på for langsiktig arkivering.
I praksis betyr dette at organisasjoner med ekstremt høye krav til sikkerhetsmargin, som nasjonale arkiver eller forsvarsrelatert infrastruktur, ofte lener mot Classic McEliece nettopp på grunn av det tette sikkerhetsbeviset og de 45 årene uten praktisk gjennombrudd. Organisasjoner som prioriterer enkel integrasjon i eksisterende protokoller lener mot HQC.
Det er også verdt å nevne at ingen av algoritmene er immune mot fremtidig kryptoanalyse bare fordi de er kodebaserte. Forskningsmiljøet rundt post-kvante-kryptografi fortsetter å granske quasi-cykliske strukturer som den HQC bruker, siden ekstra struktur i en kryptografisk konstruksjon alltid åpner for at en angriper kan utnytte nettopp denne strukturen, selv om ingen praktisk angrep er funnet så langt. Classic McElieces unngåelse av ekstra struktur er samtidig forklaringen på hvorfor den forblir så konservativ, men også hvorfor den ikke kan komprimeres på samme måte som HQC.
NIST-standardisering og status i 2026
Status per oktober 2026 er asymmetrisk mellom de to algoritmene. HQC ble valgt av NIST i mars 2025 som tilleggsalgoritme for kodebasert nøkkelinnkapsling, ved siden av ML-KEM. Men “valgt” betyr ikke “ferdig standardisert”: en endelig FIPS-publikasjon var fortsatt ikke klar, og offentlige tidslinjer pekte mot ferdigstillelse rundt 2026-2027.
Classic McEliece nådde fjerde runde i NIST-prosessen, men ble ikke valgt til den ekstra kodebaserte standarden. NIST har pekt på de svært store offentlige nøklene og begrenset interesse for bred utrulling som viktige grunner. Algoritmen har likevel fått en alternativ vei: den er rapportert inkludert i ISO/IEC 18033-2:2006/Amd 2:2026, en internasjonal standardiseringsprosess som dekker parametersettene mceliece460896, mceliece6688128, mceliece6960119 og mceliece8192128. Classic McEliece-prosjektet har selv uttalt at NIST kan vurdere en fremtidig standard etter at ISO-prosessen er fullført, delvis for å unngå to parallelle og inkompatible standarder for samme algoritme.
Det er verdt å presisere at ingen av algoritmene bør kalles “standard” i vanlig forstand ennå. Begge er mer nøyaktig beskrevet som valgt, under evaluering eller under standardisering. Hovedtyngden av reell produksjonsutrulling av post-kvante-kryptografi i 2026 er fortsatt konsentrert om ML-KEM og ML-DSA, ikke HQC eller Classic McEliece.
Praktisk kostnad: bånnbredde og lagring i kroner og øre
Verken Classic McEliece eller HQC har en lisenskostnad. Begge er åpne, patentfrie spesifikasjoner implementert gratis gjennom liboqs og PQClean under Open Quantum Safe-prosjektet. Den reelle kostnaden ligger i infrastruktur: lagringsplass for nøkler, og bånnbredde for å flytte dem. Tabellen under bruker Amazon sin offentlig publiserte standardpris for utgående dataoverføring (om lag 0,09 USD per GB for de første lagene med trafikk) som et praktisk referansepunkt for å vise hvordan nøkkelstørrelse slår ut i reelle driftskostnader ved stort volum.
| Kostnadselement | Classic McEliece (nivå 1) | HQC-128 (nivå 1) | ML-KEM-768 (referanse) |
|---|---|---|---|
| Programvarelisens | Gratis (åpen kildekode) | Gratis (åpen kildekode) | Gratis (åpen kildekode) |
| Offentlig nøkkel, lagring per 1 million brukere | ~249 GB | ~2,1 GB | ~1,1 GB |
| Estimert bånnbreddekostnad, 1 million nøkkeloverføringer | ~22,50 USD | ~0,19 USD | ~0,10 USD |
| Chiffertekst, lagring per 1 million transaksjoner | ~0,09 GB | ~4,3 GB | ~1,0 GB |
| Estimert bånnbreddekostnad, 1 million chiffertekster | ~0,01 USD | ~0,36 USD | ~0,09 USD |
| Best egnet skaleringsmønster | Nøkkel sjelden, kryptering ofte | Balansert, hyppige håndtrykk | Balansert, hovedstandard |
Tabellen illustrerer poenget tydelig: dersom systemet ditt distribuerer en offentlig nøkkel til millioner av enheter, er HQC rundt 100 ganger billigere i rå bånnbreddekostnad enn Classic McEliece. Men hvis systemet ditt krypterer mange ganger mot samme nøkkel, som i et VPN-oppsett med langvarige tunneler, er differansen i chiffertekst-kostnad ubetydelig i kroner, og Classic McEliece sin lille chiffertekst gir i tillegg lavere nettverkslatens per operasjon.
Det finnes også en skjult kostnad som sjelden dukker opp i rene bånnbredderegnestykker: lagringsplass i sikre nøkkeldatabaser og HSM-er (hardware security modules). Mange HSM-produkter på markedet i 2026 støtter fortsatt bare nøkkelstørrelser opp til noen titalls kilobyte som standard, noe som gjør en McEliece-nøkkel på over 1 MB til et eget prosjekt i seg selv dersom nøkkelen skal beskyttes i maskinvare. HQC sine nøkler på 2-7 KB passer derimot innenfor de fleste HSM-produkter uten tilpasning. For virksomheter som allerede har investert i HSM-infrastruktur for sine RSA- eller ECC-nøkler, er dette ofte en mer avgjørende faktor enn selve bånnbreddekostnaden.
Fem reelle bruksområder for kodebasert post-kvantekryptografi
Valget mellom de to algoritmene handler i praksis om hvilket mønster systemet ditt følger: distribueres nøkkelen ofte, eller brukes den lenge? Under følger fem konkrete scenarioer der valget faller ulikt ut.
- Satellittkommunikasjon og romfartøy. Oppkoblinger mot satellitter har ekstremt begrenset og dyr bånnbredde, men nøkkelen for en gitt satellitt-sesjon kan ofte forhåndslastes én gang på jorden. Her er Classic McElieces mikroskopiske chiffertekst på 96-208 byte verdt den ekstra lagringskostnaden for den store nøkkelen, siden nøkkelen aldri sendes over den trange kanalen.
- IoT-enheter og innebygd fastvare. Enheter med begrenset flash-lagring, som smarte målere eller industrisensorer, har ofte ikke plass til en 261 KB offentlig nøkkel per enhet. HQC sin nøkkel på 2-7 KB er langt mer realistisk for provisjonering av enhetsflåter i stort volum.
- Langtidsarkivering av helse- og rettsdata. Journaler og rettsdokumenter som må forbli konfidensielle i 20-30 år er nøyaktig det “harvest now, decrypt later” handler om. Her kan Classic McElieces 45 år uten praktisk gjennombrudd og tette sikkerhetsbevis vektlegges tyngre enn lagringskostnaden for nøkkelen, spesielt siden arkivdata ikke krever hyppig nøkkelgenerering.
- VPN-tunneler og sted-til-sted-kryptering. Et VPN-oppsett forhandler sjelden nye nøkler, men krypterer kontinuerlig trafikk gjennom en etablert tunnel. NIST sin egen vurdering peker på nettopp dette som Classic McElieces sterkeste kort: lav kostnad per krypteringsoperasjon når nøkkelen allerede er utvekslet.
- Offentlige sertifikater og hyppige TLS-håndtrykk. Web-tjenere som forhandler tusenvis av nye TLS-sesjoner hvert sekund har ikke rom for en nøkkel på flere hundre kilobyte per håndtrykk. Her er HQC, eller mer sannsynlig ML-KEM som hovedvalg, det praktiske alternativet, med HQC som reserve dersom gitterbasert kryptografi svekkes.
- Finansinfrastruktur med sentraliserte nøkkelsentre. Betalingsnettverk og clearingsystemer har ofte én eller noen få sentrale nøkler som resten av nettverket krypterer mot, i stedet for at hver transaksjon forhandler en ny nøkkel. Det samme mønsteret som gjør Classic McEliece attraktivt for VPN, gjør den attraktivt her: nøkkelen distribueres sjelden og sentralt, mens antallet krypteringsoperasjoner mot den kan være enormt.
Hva eksperter og standardiseringsorganer sier
Daniel J. Bernstein, kryptograf og medforfatter av Classic McEliece-spesifikasjonen, har vært tydelig på at algoritmens designmål går lenger enn grunnleggende ettveissikkerhet. Han skriver at “Classic McEliece has a more powerful goal than one-wayness: it’s a KEM designed to stop chosen-ciphertext attacks” (cr.yp.to, McEliece-standardisering). Samme kilde peker på en konkret teoretisk svakhet ved HQC, der Bernstein skriver at “HQC’s QROM IND-CCA2 security level could be far below the QCSD security level, whereas Classic McEliece has a tight proof of QROM IND-CCA2 security assuming McEliece one-wayness” (cr.yp.to, McEliece-standardisering).
NIST selv bekrefter den store ytelsesforskjellen på nøkkelgenerering i sin statusrapport fra fjerde runde, der det heter at “key generation in Classic McEliece is an outlier, being three orders of magnitude more costly than HQC” (NIST IR 8545, fjerde runde-status). Det tyske sikkerhetsdirektoratet BSI gir en mer praktisk anbefaling til organisasjoner som planlegger migrering nå: “For key agreement, it is advised to use FrodoKEM, ML-KEM or HQC (once the corresponding standard has been published)” (BSI, notater om Classic McEliece). BSI legger samtidig til at “the HQC scheme, which is planned to be recommended in the future, is not affected either, even though, like Classic McEliece, it is based on error-correcting codes” (BSI, notater om Classic McEliece), en referanse til at de to algoritmene ikke deler alle sårbarhetsmønstre selv om de begge er kodebaserte.
Migreringsguide: fra RSA/ECC til kodebasert post-kvantekryptografi
Ingen seriøs migrering bytter direkte fra RSA eller elliptisk kurve-kryptografi til en eksperimentell algoritme uten en hybridfase. Under er en praktisk fremgangsmåte for organisasjoner som vil evaluere Classic McEliece eller HQC som en del av sin post-kvante-strategi.
- Kartlegg hvilke systemer som faktisk har et “harvest now, decrypt later”-problem. Data med kort levetid, som en betalingstransaksjon som er ugyldig etter sekunder, har lavere prioritet enn arkivdata med 20+ års konfidensialitetskrav.
- Installer en referanseimplementasjon via liboqs eller PQClean i et isolert testmiljø, ikke i produksjon. Begge bibliotekene støtter både Classic McEliece og HQC gjennom samme API.
- Kjør en hybridkonfigurasjon der den post-kvante-algoritmen kombineres med en klassisk algoritme som X25519 eller ECDHE, aldri som full erstatning i første fase. Dette sikrer at systemet forblir sikkert selv om den nye algoritmen senere skulle vise seg svak.
- Mål faktisk nøkkelstørrelse og bånnbreddebruk i din egen protokoll, ikke bare i isolerte mikrobenchmarks. Et TLS-håndtrykk med en 261 KB McEliece-nøkkel kan kreve pakkefragmentering som ikke finnes i dagens protokollstabel.
- Velg algoritme basert på trafikkmønster, ikke på hype. Bruk tabellene i denne artikkelen til å beregne reell kostnad for ditt spesifikke forhold mellom nøkkeldistribusjon og krypteringsvolum.
- Planlegg for at standarden endrer seg. HQC er fortsatt under veis mot en ferdig FIPS-publikasjon, og Classic McEliece sin ISO-status kan påvirke fremtidige parametervalg. Bygg kryptografisk smidighet inn i arkitekturen slik at algoritmen kan byttes uten full re-arkitektur.
- Test interoperabilitet mot minst to uavhengige implementasjoner før noe rulles ut mot eksterne parter, siden spesifikasjonsdetaljer for begge algoritmene fortsatt kan justeres før endelig standardisering.
- Dokumenter beslutningen og kriteriene som lå til grunn. Fordi både HQC og Classic McEliece fortsatt er i bevegelse standardiseringsmessig, bør valget av parametersett og algoritme kunne spores tilbake til et konkret trafikkmønster og en konkret risikovurdering, ikke en engangsbeslutning som aldri revurderes.
Fordeler og ulemper ved Classic McEliece
| Fordeler | Ulemper |
|---|---|
| 45 år uten praktisk kryptoanalytisk gjennombrudd | Offentlig nøkkel fra 261 KB til over 1,3 MB |
| Chiffertekst på bare 96-208 byte uansett sikkerhetsnivå | Nøkkelgenerering er tre størrelsesordener dyrere enn HQC |
| Tett sikkerhetsbevis for QROM IND-CCA2-sikkerhet | Ikke valgt av NIST som standard, kun Round 4-kandidat |
| Ideell for VPN og filkryptering med langvarig nøkkelbruk | Upraktisk for enheter med begrenset lagringsplass |
| Inkludert i ISO/IEC 18033-2:2006/Amd 2:2026 | Krever pakkefragmentering i mange eksisterende protokoller |
Fordeler og ulemper ved HQC
| Fordeler | Ulemper |
|---|---|
| Offentlig nøkkel på 2,25-7,25 KB, praktisk for de fleste protokoller | Chiffertekst 47-70 ganger større enn Classic McEliece |
| Valgt av NIST i mars 2025 som tilleggsalgoritme til ML-KEM | Endelig FIPS-standard ikke ferdigstilt per oktober 2026 |
| Raskest nøkkelgenerering av de kodebaserte alternativene | Svakere teoretisk sikkerhetsbevis i QROM enn Classic McEliece |
| Passer godt i protokoller med hyppige nøkkelutvekslinger | Mindre kryptoanalytisk historie enn Classic McEliece |
| Lav nok nøkkelstørrelse til IoT og konstrensede enheter | Dårligere egnet der chiffertekst-volum er den dominerende kostnaden |
Dommen: hvilken algoritme bør du velge
Tallene peker mot en klar, men betinget konklusjon. HQC er det mer praktiske valget for de fleste organisasjoner, fordi en offentlig nøkkel på 2-7 KB lar seg distribuere i nesten alle eksisterende protokoller uten modifikasjon, mens Classic McElieces nøkkel på 261 KB til 1,3 MB krever spesialtilpasning i nesten alt som ikke allerede er designet for store nøkler. Det er også grunnen til at NIST valgte HQC og ikke Classic McEliece som sin tilleggsstandard i mars 2025.
Men “mer praktisk” er ikke det samme som “best i alle tilfeller”. For arkivering med ekstreme sikkerhetskrav, satellittlenker med minimal bånnbredde, og VPN-oppsett med langvarig nøkkelbruk, vinner Classic McEliece på egne premisser: 45 år med kryptoanalytisk stabilitet, et tettere sikkerhetsbevis, og en chiffertekst som er over 40 ganger mindre enn HQC sin. Konklusjonen bør derfor være todelt: bruk HQC som standard reservealgoritme ved siden av ML-KEM i de fleste nye systemer, men vurder Classic McEliece spesifikt for langtidsarkiver og lavbånnbredde-scenarioer der nøkkelen kan forhåndsdistribueres én gang og chiffertekst-størrelsen er den avgjørende kostnaden.
Uansett hvilken man velger, er ingen av de to en erstatning for en signaturalgoritme. Firmware og meldinger må fortsatt autentiseres med ML-DSA, SLH-DSA eller en annen post-kvante-signatur, siden både Classic McEliece og HQC kun løser nøkkelinnkapsling.
Implementering i praksis: biblioteker og utviklererfaring
For en utvikler som skal teste disse algoritmene i dag, er veien inn stort sett den samme uansett hvilken av de to man velger. Open Quantum Safe-prosjektets liboqs eksponerer et felles API for nøkkelgenerering, innkapsling og dekapsling, slik at man kan bytte mellom mceliece348864, HQC-128 og for den saks skyld ML-KEM-768 med minimale kodeendringer. PQClean leverer de underliggende referanseimplementasjonene som liboqs bygger videre på, og begge prosjektene distribueres som åpen kildekode uten lisenskostnad.
Den praktiske forskjellen dukker opp først når nøkkelen skal flyttes gjennom et eksisterende system. En offentlig nøkkel på 261 KB fra Classic McEliece er større enn mange databasefelt, API-grensesnitt og meldingskøer er designet for som standard. Flere TLS-implementasjoner må fragmentere håndtrykket over flere pakker, og noen eldre mellomboksenheter (brannmurer, lastbalansere) kan i verste fall kaste pakker de ikke forventer å se i en TLS ClientHello. HQC sin nøkkel på 2-7 KB passer derimot innenfor de fleste eksisterende grenser uten modifikasjon, selv om den fortsatt er betydelig større enn ML-KEMs 800-1.568 byte.
Språkbindinger finnes for begge algoritmene i Python, Go, Rust og C/C++ gjennom liboqs sine offisielle wrappere, samt gjennom OpenSSL sine post-kvante-providere i nyere versjoner. For team som allerede bruker OpenSSL 3.x i produksjon, er overgangen til å teste HQC eller Classic McEliece i en hybridkonfigurasjon en konfigurasjonsendring snarere enn en større kodeomskrivning, forutsatt at man kjører en versjon med post-kvante-provider aktivert.
Nordisk kontekst: hva betyr dette for norske og nordiske virksomheter
For norske og nordiske virksomheter kommer post-kvante-migrering i praksis fra to retninger samtidig. Den første er EU-regelverk: NIS2-direktivet skjerper krav til risikostyring for kritisk infrastruktur og samfunnsviktige tjenester, og kryptografisk fremtidssikring regnes i stadig større grad som en del av god risikostyring, ikke et valgfritt tillegg. Den andre retningen er internasjonale standardiseringsorganer som NIST og BSI, som i praksis setter tempoet for hvilke algoritmer leverandører av sikkerhetsprodukter faktisk bygger inn i sine løsninger.
For de fleste norske virksomheter er den riktige prioriteringen fortsatt å sikre at ML-KEM og ML-DSA er på plass i kritiske systemer, siden disse allerede er NIST-standardisert og har den bredeste leverandørstøtten. Classic McEliece og HQC er mer relevante som en bevisst forsikring for et lite, men viktig, delsett av systemer: langtidsarkiver i offentlig sektor, helseregistre med lovkrav om oppbevaring i flere tiår, og sentralbank- eller finansinfrastruktur der konsekvensen av et fremtidig kryptografisk sammenbrudd er uakseptabel. Et praktisk første skritt for en norsk IT-avdeling er å identifisere nøyaktig hvilke datasett som faller i denne kategorien, og teste en hybrid HQC- eller Classic McEliece-konfigurasjon mot nettopp disse systemene, i stedet for å forsøke å migrere alt på én gang.
Verdt å merke seg er at ingen norsk eller nordisk standardiseringsmyndighet per oktober 2026 har publisert egne, avvikende krav til post-kvante-kryptografi utover det som følger av EU- og NIST-rammeverket. Det betyr at norske virksomheter i praksis følger samme tidslinje som resten av Europa, og at valget mellom Classic McEliece og HQC bør baseres på de samme tekniske kriteriene som er beskrevet i denne artikkelen, ikke på lokale regulatoriske særkrav.
Vanlige spørsmål om Classic McEliece og HQC
Er Classic McEliece eller HQC offisielle NIST-standarder i 2026?
Nei, ingen av dem er en ferdig FIPS-publisert standard per oktober 2026. HQC ble valgt av NIST i mars 2025 som fremtidig tilleggsalgoritme, men den endelige publikasjonen var fortsatt under arbeid. Classic McEliece nådde fjerde runde i NIST-prosessen, men ble ikke valgt, og er i stedet inkludert i en ISO/IEC-standardiseringsprosess.
Hvorfor har Classic McEliece en så stor offentlig nøkkel?
Nøkkelstørrelsen følger direkte av Goppa-kode-strukturen algoritmen bruker. For å oppnå det konservative sikkerhetsnivået må generatormatrisen for koden være stor, og denne matrisen utgjør kjernen av den offentlige nøkkelen. Det er en bevisst avveining mot HQCs mer komprimerte, men teoretisk mindre konservative, quasi-cykliske struktur.
Kan HQC og Classic McEliece brukes til digitale signaturer?
Nei. Begge er nøkkelinnkapslingsmekanismer (KEM-er), ikke signaturalgoritmer. For post-kvante-signaturer må man bruke ML-DSA, SLH-DSA eller Falcon, uavhengig av hvilken KEM som velges for nøkkelutveksling.
Er HQC tryggere enn Classic McEliece?
Ikke nødvendigvis. Classic McEliece har et tettere teoretisk sikkerhetsbevis og 45 år uten praktisk gjennombrudd, mens HQC er nyere og har et mindre konservativt sikkerhetsargument i den kvante-tilfeldige orakelmodellen. NIST valgte HQC primært av praktiske, ikke rent sikkerhetsmessige, årsaker.
Hvilken algoritme bør et norsk IoT-selskap velge?
For enheter med begrenset flash-lagring er HQC det mer realistiske valget på grunn av den langt mindre offentlige nøkkelen. Classic McEliece passer bedre til sentraliserte systemer, som en VPN-konsentrator eller et arkivsystem, der nøkkelen kan lagres sentralt én gang.
Hva betyr det at HQC og Classic McEliece begge er “kodebaserte”?
Det betyr at sikkerheten bygger på vanskeligheten av å dekode en tilfeldig lineær feilkorrigerende kode, et problem som er uavhengig av gitterbasert matematikk (som ML-KEM bruker) og av faktorisering eller diskret logaritme (som RSA og ECC bruker). Det gjør dem til et nyttig matematisk mangfold i en post-kvante-portefølje.
Bør vi vente med å implementere noen av disse i produksjon?
For de fleste organisasjoner, ja, med ett unntak. Hovedprioritet bør være ML-KEM og ML-DSA, som allerede er NIST-standardisert. Classic McEliece og HQC bør testes i hybridkonfigurasjoner nå, men venter man på full produksjonsbruk til standardene er ferdigstilt, typisk anslått til 2026-2027 for HQC.
Hvor stor er risikoen for at begge algoritmene blir knekket samtidig?
Lav, men ikke null, siden begge bygger på samme generelle kodebaserte vanskelighetsgrad. Det er nettopp derfor NIST og BSI anbefaler å holde minst én gitterbasert algoritme (ML-KEM) og én kodebasert algoritme i beredskap samtidig, i stedet for å sette alle ressurser på en enkelt matematisk familie.
Hva skjer med BIKE, den tredje kodebaserte kandidaten?
BIKE ble vurdert i samme fjerderunde som Classic McEliece og HQC, men NIST valgte å ikke ta den videre til standardisering og pekte på at den var mellom 5 og 7 ganger tregere enn de andre kandidatene på visse operasjoner. I praksis er BIKE dermed lagt til side som produksjonskandidat, og det reelle valget for kodebasert post-kvante-kryptografi står mellom Classic McEliece og HQC.
Må vi velge én av algoritmene, eller kan vi bruke begge?
Det er fullt mulig å bruke begge i parallell for forskjellige systemer. En stor organisasjon kan for eksempel bruke HQC i hybrid med ML-KEM for de fleste TLS-tilkoblinger, og samtidig bruke Classic McEliece for et avgrenset langtidsarkiv der chiffertekst-størrelse og 45 års kryptoanalytisk historie er viktigere enn nøkkeldistribusjon. Kryptografisk smidighet, altså evnen til å bytte algoritme uten full re-arkitektur, er mer avgjørende enn å binde seg til ett valg for alltid.
