Satt på spissen handler dette om to ulike typer risiko. Velger et team HQC, tar de på seg en kjent og målbar kostnad i form av større pakker og litt mer minnebruk, mot en klar vei til en godkjent standard. Velger de BIKE, sparer de noen kilobyte per håndtrykk i dag, men bygger på en algoritme uten standardiseringsløp og med en dokumentert, om enn krevende, angrepsvei. For de aller fleste produksjonsmiljøer er det et enkelt regnestykke.
Seks virkelige bruksområder
Valget mellom HQC, BIKE og ML-KEM ser ulikt ut avhengig av hvilken type system som skal beskyttes. Her er seks konkrete scenarier der forskjellene faktisk får betydning, og hvorfor svaret ikke er det samme i alle.
- CDN- og TLS-infrastruktur i stor skala: Tjenester som håndterer milliarder av håndtrykk bør bruke ML-KEM-768 som primær hybrid-KEM i dag, slik store nettverksoperatører allerede gjør, og vurdere HQC som sekundær algoritme først når kladd-FIPS-en er ferdig i 2026.
- Kritisk infrastruktur under EUs veikart: Finans, telekom, energi og offentlig sektor, som ifølge EU-kommisjonens koordinerte veikart skal ha post-kvante kryptografi på plass for høyrisikobruk senest innen 2030, bør bygge på standardiserte algoritmer og se på HQC som reserve, ikke på BIKE.
- Langtidsarkivering og kryptografisk mangfold: Organisasjoner som lagrer dokumenter eller helsedata i tiår framover, har god grunn til å kombinere ML-KEM med en kodebasert reserve som HQC nettopp for å unngå at ett enkelt matematisk gjennombrudd kompromitterer alt.
- Innebygde og båndbreddebegrensede enheter: IoT-sensorer og innebygd utstyr med begrenset minne og lav båndbredde bør holde seg til ML-KEM-512 eller -768 der det er mulig, siden både HQCs og BIKEs chiffertekster er tunge å sende over trege radionett.
- Forskning og undervisning: liboqs fortsetter å tilby både HQC og BIKE for eksperimentering og kryptoanalyse, noe som gjør dem verdifulle i universitetsmiljøer selv om bare den ene har en kommersiell fremtid.
- VPN- og meldingstjenester som eksperimenterer med PQC: Prosjekter bygget på OQS-provideren kan teste hybridmodus med HQC for å forberede seg på en fremtidig standard, men bør unngå å basere produksjonstrafikk på BIKE gitt sårbarhetene som er dokumentert i 2026.
Det fellestrekket som går igjen i alle seks scenarier, er at ML-KEM nesten alltid er utgangspunktet, mens HQC og BIKE spiller ulike birollar avhengig av hvor mye vekt organisasjonen legger på kryptografisk mangfold versus ren ressursbruk. Ingen av bruksområdene over peker mot BIKE som et fornuftig valg i produksjon i 2026, noe som i seg selv sier mye om hvor tungt NISTs beslutning veier når virksomheter faktisk skal velge byggeklosser for egen infrastruktur.
Norge og Norden: EUs veikart og NSMs rolle
EU-kommisjonen publiserte sin anbefaling om et koordinert veikart for post-kvante kryptografi 11. april 2024, og medlemslandene, støttet av kommisjonen, vedtok selve det koordinerte veikartet for overgangen i juni 2025. Tidslinjen er klar: innen utgangen av 2026 skal medlemslandene ha startet overgangen, med nasjonale strategier, kryptografiske kartlegginger og de første pilotprosjektene på plass, mens operatører av kritisk infrastruktur skal ha satt i gang planlegging og pilotprosjekter for høy- og middelsrisikobruk. Innen utgangen av 2030 skal høyrisikobruk og kritisk infrastruktur, deriblant finans, telekom og offentlig forvaltning, være sikret med post-kvante kryptografi. Innen 2035 er målet at migreringen er fullført for de aller fleste systemer der det er praktisk mulig.
For Norge spesifikt har Nasjonal sikkerhetsmyndighet (NSM) publisert ikke-bindende veiledning som oppfordrer virksomheter i kritiske sektorer til å kartlegge sine kryptografiske ressurser og starte overgangen nå, men uten en konkret frist eller håndhevingsmekanisme tilsvarende EUs 2030-dato. Det betyr i praksis at norske virksomheter som opererer i eller mot EU-markedet, uansett bør planlegge etter EUs tidslinje, mens rent nasjonale aktører har noe mer albuerom, men fortsatt et klart insentiv til å komme i gang før konkurrenter og regulatoriske krav tar igjen dem.
For nordiske banker, forsikringsselskaper og telekomoperatører kommer denne tidslinjen på toppen av et allerede krevende regelverkslandskap, der digital motstandsdyktighet er strengt regulert gjennom EUs finanssektorregler. Å legge post-kvante-migrering inn i samme program som eksisterende compliance-arbeid, framfor å behandle det som et frittstående IT-prosjekt, er noe flere rådgivningsmiljøer i Norden nå anbefaler, rett og slett fordi kartleggingsarbeidet i stor grad overlapper. En kryptografisk inventarliste laget for post-kvante-formål gjenbrukes direkte i revisjoner av øvrig sikkerhetsarkitektur.
Verdikt: hvem bør velge hva
Tallene peker i én klar retning. HQC vant NISTs tillit 11. mars 2025 fordi den kombinerer en matematisk bevist dekodingsfeilrate med ytelse som slår BIKE på nesten alle operasjoner, til tross for en chiffertekst som er nesten tre ganger større. BIKE var aldri det svakeste alternativet på papiret, mindre nøkler er tross alt en reell fordel, men usikkerheten rundt dekodingsfeilraten og det dokumenterte sidekanalangrepet fra 2026 gjør det vanskelig å anbefale algoritmen til noe annet enn forskning og eksperimentering.
For de fleste virksomheter er svaret enkelt: bruk ML-KEM-768 i hybridmodus som hovedløsning i dag, følg med på HQCs kladd-FIPS gjennom 2026, og hold BIKE unna produksjonssystemer. Når HQC blir en ferdig FIPS-standard i 2027, gir den et reelt sikkerhetsnett bygget på annen matematikk enn ML-KEM, noe som er verdt den ekstra båndbredden for organisasjoner som tar langsiktig kryptografisk risiko på alvor. Med EUs frist for kritisk infrastruktur i 2030 som bakteppe, er dette ikke lenger et spørsmål virksomheter i Norge og Norden kan skyve foran seg.
Det er også verdt å minne om at ingenting her er statisk. Kladd-FIPS-en for HQC kan i teorien justere parametre før den blir endelig i 2027, akkurat slik ML-KEM selv gjennomgikk mindre endringer på veien fra Kyber til FIPS 203. BIKE kan i prinsippet komme tilbake i en senere runde dersom kryptoanalysen på dekodingsfeilrate modnes betraktelig, men det finnes ingen tidslinje for det i dag, og ingen ansvarlig sikkerhetsarkitekt bør planlegge rundt en mulighet uten dato. Den praktiske leveregelen forblir den samme gjennom hele denne artikkelen: bygg på det som er standardisert, hold øye med det som er på vei til å bli det, og bruk eksperimentelle algoritmer kun der konsekvensen av en feilvurdering er lav.
Ofte stilte spørsmål
Hva er den viktigste forskjellen mellom HQC og BIKE?
Begge er kodebaserte nøkkelinnkapslingsmekanismer, men HQC har en matematisk bevist lav dekodingsfeilrate og ble valgt av NIST som femte post-kvante-standard 11. mars 2025, mens BIKE ikke ble valgt fordi analysen av dens dekodingsfeilrate ikke ble ansett som moden nok.
Hvorfor valgte NIST HQC og ikke BIKE?
Ifølge NIST IR 8545 kan BIKEs dekodingsfeilrate i verste fall nå 2⁻¹¹⁷ for visse svake nøkler, under målet på 2⁻¹²⁸ som kreves for full IND-CCA2-sikkerhet. HQC beviser en feilrate under 2⁻¹²⁸ på alle tre sikkerhetsnivåene, og ble derfor foretrukket til tross for større nøkler.
Er BIKE usikkert å bruke i dag?
BIKE har ingen kjent, praktisk utnyttbar svakhet som umiddelbart bryter alle implementasjoner, men et dokumentert nøkkelgjenopprettingsangrep fra 2026 utnytter tidsvariasjon i dekapsuleringsrutinen, og algoritmen mangler en offisiell standardiseringsvei. Det gjør den uegnet for nye produksjonssystemer.
Når blir HQC en ferdig FIPS-standard?
NIST forventer en kladd-FIPS for HQC i løpet av 2026, med endelig standard ventet i 2027, ifølge Cryptomathic og postquantum.wiki.
Støtter OpenSSL HQC og BIKE?
Ikke direkte i kjernebiblioteket. OpenSSL 3.5 og nyere har native støtte for ML-KEM, ML-DSA og SLH-DSA, mens HQC og BIKE begge krever OQS-provideren, som bygger på liboqs.
Bør jeg bruke HQC i produksjon allerede nå?
De fleste bør vente til kladd-FIPS-en er publisert i 2026 før HQC settes i skarp drift, og heller bruke ML-KEM-768 i hybridmodus som hovedløsning i mellomtiden. HQC egner seg godt til testing og pilotprosjekter allerede i dag, spesielt for team som ønsker å øve på integrasjonsarbeidet før algoritmen blir en formell standard.
Hva er forskjellen mellom HQC og ML-KEM?
ML-KEM (FIPS 203) er gitterbasert og allerede en ferdig standard, mens HQC er kodebasert og fortsatt under standardisering. NIST valgte bevisst HQC som reserve nettopp fordi den bygger på annen matematikk enn ML-KEM, som beskyttelse hvis gitterbasert kryptografi skulle vise seg sårbar i fremtiden.
Må norske virksomheter bytte til post-kvante kryptografi nå?
EUs koordinerte veikart krever at kritisk infrastruktur, inkludert finans, telekom og offentlig forvaltning, er sikret med post-kvante kryptografi senest innen utgangen av 2030, med nasjonale planer klare innen 2026. NSM i Norge gir tilsvarende, men ikke-bindende veiledning, så virksomheter bør uansett starte kartleggingen nå.
Kommandoene over forutsetter at OQS-provideren er installert og registrert i OpenSSLs konfigurasjonsfil. Mange team setter opp et lite testmiljø akkurat slik, med en lokal server konfigurert til å tilby flere PQC-grupper samtidig, for å måle håndtrykkstider og pakkestørrelser før noe rører produksjonstrafikk. Dette er også en praktisk måte å avdekke om mellomliggende utstyr, som eldre brannmurer eller lastbalanserere, håndterer de større ClientHello-meldingene korrekt, siden det er nettopp den typen infrastruktur som historisk har skapt de fleste overraskelsene i tidlige PQC-utrullinger.
Kostnad og infrastrukturbehov ved storskala drift
Verken HQC eller BIKE koster noe i lisens, begge er åpen kildekode og fritt tilgjengelige gjennom liboqs. Den reelle kostnaden ligger i båndbredde, minnebruk og pakkefragmentering, ikke i kroner per nøkkel. Jo større chiffertekst, desto mer data må sendes i hvert håndtrykk, og for tjenester med milliarder av tilkoblinger i måneden blir selv noen hundre ekstra byte merkbart i regnskapet. For en liten eller mellomstor norsk virksomhet med noen tusen daglige TLS-forbindelser er denne kostnaden i praksis neglisjerbar, men for banker, telekomoperatører og offentlige portaler med nasjonal trafikk er det en linjepost verdt å regne på før man låser seg til én algoritme.
| Kostnadsfaktor | HQC | BIKE | ML-KEM-768 (referanse) |
|---|---|---|---|
| Lisens / bruksrett | Gratis, åpen kildekode | Gratis, åpen kildekode | Gratis, åpen kildekode |
| Native støtte i OpenSSL 3.5+ | Nei, kun via OQS-provider | Nei, kun via OQS-provider | Ja, innebygd |
| Planlagt støtte i wolfSSL | Ja, oppført som fremtidig utvidelse | Ikke nevnt i veikartet | Allerede støttet (FIPS 203) |
| Ekstra data pr. nøkkelutveksling (nivå 1) | ≈6 674 byte | ≈3 114 byte | ≈2 272 byte |
| Krav til embedded/IoT-maskinvare | Høyere minnebehov, risiko for pakkefragmentering | Lavere minnebehov, men usikker dekodingsytelse | Lavest ressursbruk av de tre |
| Standardiseringsstatus (kostnad ved implementering nå) | Kladd-FIPS ventet 2026, kan endres før ferdigstillelse | Ingen standard kommer, implementering er permanent eksperimentell | Ferdig standard, stabil å bygge mot |
Som referanse har Cloudflare offentliggjort tall for hvor mye hybrid ML-KEM-768 legger til et TLS-håndtrykk: en klient som bruker X25519MLKEM768 sender en nøkkeldel på 1 216 byte mot 32 byte for ren X25519, noe som ofte skyver ClientHello-meldingen over grensen for én enkelt nettverkspakke. Skaleres dette opp til en tjeneste med én milliard håndtrykk i måneden og rundt 2,27 kilobyte ekstra data per hybrid tilkobling, blir det snakk om i overkant av 2 terabyte ekstra utgående trafikk hver måned bare fra nøkkelutvekslingen. HQC, med sin større chiffertekst, vil legge til proporsjonalt mer i et tilsvarende scenario, mens BIKE ligger mellom de to andre.
Cloudflare har også vist hvordan kostnaden vokser videre når signaturalgoritmer legges til håndtrykket: en oppgradering av sertifikatkjeden til ML-DSA legger til rundt 14,7 kilobyte per TLS-håndtrykk, og selskapet har anslått at en full oppgradering av egne sertifikater ville kreve rundt 1,8 terabit per sekund i ekstra kapasitet, tilsvarende omtrent 0,6 prosent av selskapets totale nettverkskapasitet. Tallene er hentet fra ML-DSA-signaturer, ikke fra HQC eller BIKE spesifikt, men de illustrerer størrelsesordenen infrastrukturteam bør planlegge for når nøkkelutveksling og signering oppgraderes samtidig, noe som uansett må skje for at post-kvante-migreringen skal gi reell beskyttelse.
Migrasjonsguide: fra klassisk til post-kvante nøkkelutveksling
Uansett om målet er ML-KEM alene eller en hybridløsning med HQC som reserve, følger de fleste virksomheter det samme grunnmønsteret. Migrering til post-kvante kryptografi er sjelden en «rip and replace»-øvelse, den skjer stegvis over flere år, med hybridmodus som mellomstasjon slik at klassisk kryptografi fortsatt gir beskyttelse dersom noe skulle vise seg galt med de nye algoritmene tidlig i utrullingen. Her er stegene som gir minst risiko for driftsavbrudd underveis.
- Kartlegg alle steder i systemporteføljen der RSA, ECDH eller andre klassiske nøkkelutvekslingsalgoritmer brukes i dag, inkludert tredjepartstjenester og interne API-er.
- Prioriter TLS-endepunkter mot internett først, siden disse er mest eksponert for «harvest now, decrypt later»-angrep der data lagres i dag for å knekkes senere med en kvantedatamaskin.
- Innfør hybridmodus med X25519MLKEM768 som førstevalg, siden dette allerede er standardisert (FIPS 203) og støttet i moderne nettlesere og serverstakker.
- Oppdater TLS-biblioteker til versjoner med OQS-provider eller native PQC-støtte, og test at eksisterende systemer takler de større håndtrykkstørrelsene uten å bryte MTU-grenser.
- Følg med på NISTs kladd-FIPS for HQC i 2026 før HQC settes i produksjon, siden parametrene i teorien kan endres fram til endelig standard i 2027.
- Unngå å bygge nye produksjonssystemer rundt BIKE, siden algoritmen ikke har noen vei mot en offisiell standard og biblioteksstøtten trolig vil trappes ned over tid.
- Test ytelse under realistisk last, spesielt for tjenester med mange samtidige håndtrykk eller begrenset båndbredde, som mobilnett eller IoT-nettverk.
- Planlegg sertifikatkjeder og PKI-infrastruktur for post-kvante signaturer (ML-DSA eller SLH-DSA) parallelt, siden nøkkelutveksling og signering må oppgraderes sammen for reell beskyttelse.
- Sett interne milepæler i tråd med EUs veikart, med nasjonale planer klare innen utgangen av 2026 og kritisk infrastruktur sikret senest innen 2030.
- Dokumenter algoritmevalg og fallback-strategi, slik at driftsteamet raskt kan bytte KEM dersom en ny sårbarhet dukker opp i ett av alternativene.
Sjekkliste før du bytter
Før produksjonssetting bør teamet bekrefte tre ting: at TLS-biblioteket faktisk støtter den valgte KEM-en i en versjon som mottar sikkerhetsoppdateringer, at nedstrøms systemer (lastbalanserere, CDN-er, brannmurer) ikke feiler på de større pakkestørrelsene, og at det finnes en dokumentert reversplan tilbake til ren klassisk kryptografi dersom noe går galt i en tidlig utrullingsfase. Mange av feilene som oppstår i praksis handler mer om MTU-fragmentering og mellomvare som ikke kjenner de nye protokollutvidelsene, enn om selve kryptoalgoritmen.
Fordeler og ulemper: HQC mot BIKE
Satt opp mot hverandre har hver algoritme klare styrker og svakheter som avgjør hvilken som passer til hvilket formål.
- HQC – fordeler: Valgt av NIST med vei mot FIPS-standard i 2027, matematisk bevist dekodingsfeilrate under 2⁻¹²⁸, aktivt vedlikeholdt i liboqs og listet som fremtidig funksjon i wolfSSL, raskere enn BIKE på nøkkelgenerering og dekapsulering i uavhengige tester.
- HQC – ulemper: Betydelig større chiffertekst enn BIKE og ML-KEM, opptil 14,4 kilobyte på høyeste sikkerhetsnivå, noe som øker risikoen for pakkefragmentering på båndbreddebegrensede nett, og spesifikasjonen er fortsatt en kladd, ikke en ferdig standard.
- BIKE – fordeler: Mindre nøkler og chiffertekst enn HQC på hvert sikkerhetsnivå, flere års kryptoanalyse i forskningsmiljøet, fortsatt tilgjengelig i liboqs for testing og forskning.
- BIKE – ulemper: Ikke valgt av NIST for standardisering, dekodingsfeilrate som i verste fall når 2⁻¹¹⁷ for svake nøkler, dokumentert nøkkelgjenopprettingsangrep via tidsmåling i 2026, ingen offisiell FIPS-vei, og biblioteksstøtten vil trolig ikke prioriteres videre.
Satt på spissen handler dette om to ulike typer risiko. Velger et team HQC, tar de på seg en kjent og målbar kostnad i form av større pakker og litt mer minnebruk, mot en klar vei til en godkjent standard. Velger de BIKE, sparer de noen kilobyte per håndtrykk i dag, men bygger på en algoritme uten standardiseringsløp og med en dokumentert, om enn krevende, angrepsvei. For de aller fleste produksjonsmiljøer er det et enkelt regnestykke.
Seks virkelige bruksområder
Valget mellom HQC, BIKE og ML-KEM ser ulikt ut avhengig av hvilken type system som skal beskyttes. Her er seks konkrete scenarier der forskjellene faktisk får betydning, og hvorfor svaret ikke er det samme i alle.
- CDN- og TLS-infrastruktur i stor skala: Tjenester som håndterer milliarder av håndtrykk bør bruke ML-KEM-768 som primær hybrid-KEM i dag, slik store nettverksoperatører allerede gjør, og vurdere HQC som sekundær algoritme først når kladd-FIPS-en er ferdig i 2026.
- Kritisk infrastruktur under EUs veikart: Finans, telekom, energi og offentlig sektor, som ifølge EU-kommisjonens koordinerte veikart skal ha post-kvante kryptografi på plass for høyrisikobruk senest innen 2030, bør bygge på standardiserte algoritmer og se på HQC som reserve, ikke på BIKE.
- Langtidsarkivering og kryptografisk mangfold: Organisasjoner som lagrer dokumenter eller helsedata i tiår framover, har god grunn til å kombinere ML-KEM med en kodebasert reserve som HQC nettopp for å unngå at ett enkelt matematisk gjennombrudd kompromitterer alt.
- Innebygde og båndbreddebegrensede enheter: IoT-sensorer og innebygd utstyr med begrenset minne og lav båndbredde bør holde seg til ML-KEM-512 eller -768 der det er mulig, siden både HQCs og BIKEs chiffertekster er tunge å sende over trege radionett.
- Forskning og undervisning: liboqs fortsetter å tilby både HQC og BIKE for eksperimentering og kryptoanalyse, noe som gjør dem verdifulle i universitetsmiljøer selv om bare den ene har en kommersiell fremtid.
- VPN- og meldingstjenester som eksperimenterer med PQC: Prosjekter bygget på OQS-provideren kan teste hybridmodus med HQC for å forberede seg på en fremtidig standard, men bør unngå å basere produksjonstrafikk på BIKE gitt sårbarhetene som er dokumentert i 2026.
Det fellestrekket som går igjen i alle seks scenarier, er at ML-KEM nesten alltid er utgangspunktet, mens HQC og BIKE spiller ulike birollar avhengig av hvor mye vekt organisasjonen legger på kryptografisk mangfold versus ren ressursbruk. Ingen av bruksområdene over peker mot BIKE som et fornuftig valg i produksjon i 2026, noe som i seg selv sier mye om hvor tungt NISTs beslutning veier når virksomheter faktisk skal velge byggeklosser for egen infrastruktur.
Norge og Norden: EUs veikart og NSMs rolle
EU-kommisjonen publiserte sin anbefaling om et koordinert veikart for post-kvante kryptografi 11. april 2024, og medlemslandene, støttet av kommisjonen, vedtok selve det koordinerte veikartet for overgangen i juni 2025. Tidslinjen er klar: innen utgangen av 2026 skal medlemslandene ha startet overgangen, med nasjonale strategier, kryptografiske kartlegginger og de første pilotprosjektene på plass, mens operatører av kritisk infrastruktur skal ha satt i gang planlegging og pilotprosjekter for høy- og middelsrisikobruk. Innen utgangen av 2030 skal høyrisikobruk og kritisk infrastruktur, deriblant finans, telekom og offentlig forvaltning, være sikret med post-kvante kryptografi. Innen 2035 er målet at migreringen er fullført for de aller fleste systemer der det er praktisk mulig.
For Norge spesifikt har Nasjonal sikkerhetsmyndighet (NSM) publisert ikke-bindende veiledning som oppfordrer virksomheter i kritiske sektorer til å kartlegge sine kryptografiske ressurser og starte overgangen nå, men uten en konkret frist eller håndhevingsmekanisme tilsvarende EUs 2030-dato. Det betyr i praksis at norske virksomheter som opererer i eller mot EU-markedet, uansett bør planlegge etter EUs tidslinje, mens rent nasjonale aktører har noe mer albuerom, men fortsatt et klart insentiv til å komme i gang før konkurrenter og regulatoriske krav tar igjen dem.
For nordiske banker, forsikringsselskaper og telekomoperatører kommer denne tidslinjen på toppen av et allerede krevende regelverkslandskap, der digital motstandsdyktighet er strengt regulert gjennom EUs finanssektorregler. Å legge post-kvante-migrering inn i samme program som eksisterende compliance-arbeid, framfor å behandle det som et frittstående IT-prosjekt, er noe flere rådgivningsmiljøer i Norden nå anbefaler, rett og slett fordi kartleggingsarbeidet i stor grad overlapper. En kryptografisk inventarliste laget for post-kvante-formål gjenbrukes direkte i revisjoner av øvrig sikkerhetsarkitektur.
Verdikt: hvem bør velge hva
Tallene peker i én klar retning. HQC vant NISTs tillit 11. mars 2025 fordi den kombinerer en matematisk bevist dekodingsfeilrate med ytelse som slår BIKE på nesten alle operasjoner, til tross for en chiffertekst som er nesten tre ganger større. BIKE var aldri det svakeste alternativet på papiret, mindre nøkler er tross alt en reell fordel, men usikkerheten rundt dekodingsfeilraten og det dokumenterte sidekanalangrepet fra 2026 gjør det vanskelig å anbefale algoritmen til noe annet enn forskning og eksperimentering.
For de fleste virksomheter er svaret enkelt: bruk ML-KEM-768 i hybridmodus som hovedløsning i dag, følg med på HQCs kladd-FIPS gjennom 2026, og hold BIKE unna produksjonssystemer. Når HQC blir en ferdig FIPS-standard i 2027, gir den et reelt sikkerhetsnett bygget på annen matematikk enn ML-KEM, noe som er verdt den ekstra båndbredden for organisasjoner som tar langsiktig kryptografisk risiko på alvor. Med EUs frist for kritisk infrastruktur i 2030 som bakteppe, er dette ikke lenger et spørsmål virksomheter i Norge og Norden kan skyve foran seg.
Det er også verdt å minne om at ingenting her er statisk. Kladd-FIPS-en for HQC kan i teorien justere parametre før den blir endelig i 2027, akkurat slik ML-KEM selv gjennomgikk mindre endringer på veien fra Kyber til FIPS 203. BIKE kan i prinsippet komme tilbake i en senere runde dersom kryptoanalysen på dekodingsfeilrate modnes betraktelig, men det finnes ingen tidslinje for det i dag, og ingen ansvarlig sikkerhetsarkitekt bør planlegge rundt en mulighet uten dato. Den praktiske leveregelen forblir den samme gjennom hele denne artikkelen: bygg på det som er standardisert, hold øye med det som er på vei til å bli det, og bruk eksperimentelle algoritmer kun der konsekvensen av en feilvurdering er lav.
Ofte stilte spørsmål
Hva er den viktigste forskjellen mellom HQC og BIKE?
Begge er kodebaserte nøkkelinnkapslingsmekanismer, men HQC har en matematisk bevist lav dekodingsfeilrate og ble valgt av NIST som femte post-kvante-standard 11. mars 2025, mens BIKE ikke ble valgt fordi analysen av dens dekodingsfeilrate ikke ble ansett som moden nok.
Hvorfor valgte NIST HQC og ikke BIKE?
Ifølge NIST IR 8545 kan BIKEs dekodingsfeilrate i verste fall nå 2⁻¹¹⁷ for visse svake nøkler, under målet på 2⁻¹²⁸ som kreves for full IND-CCA2-sikkerhet. HQC beviser en feilrate under 2⁻¹²⁸ på alle tre sikkerhetsnivåene, og ble derfor foretrukket til tross for større nøkler.
Er BIKE usikkert å bruke i dag?
BIKE har ingen kjent, praktisk utnyttbar svakhet som umiddelbart bryter alle implementasjoner, men et dokumentert nøkkelgjenopprettingsangrep fra 2026 utnytter tidsvariasjon i dekapsuleringsrutinen, og algoritmen mangler en offisiell standardiseringsvei. Det gjør den uegnet for nye produksjonssystemer.
Når blir HQC en ferdig FIPS-standard?
NIST forventer en kladd-FIPS for HQC i løpet av 2026, med endelig standard ventet i 2027, ifølge Cryptomathic og postquantum.wiki.
Støtter OpenSSL HQC og BIKE?
Ikke direkte i kjernebiblioteket. OpenSSL 3.5 og nyere har native støtte for ML-KEM, ML-DSA og SLH-DSA, mens HQC og BIKE begge krever OQS-provideren, som bygger på liboqs.
Bør jeg bruke HQC i produksjon allerede nå?
De fleste bør vente til kladd-FIPS-en er publisert i 2026 før HQC settes i skarp drift, og heller bruke ML-KEM-768 i hybridmodus som hovedløsning i mellomtiden. HQC egner seg godt til testing og pilotprosjekter allerede i dag, spesielt for team som ønsker å øve på integrasjonsarbeidet før algoritmen blir en formell standard.
Hva er forskjellen mellom HQC og ML-KEM?
ML-KEM (FIPS 203) er gitterbasert og allerede en ferdig standard, mens HQC er kodebasert og fortsatt under standardisering. NIST valgte bevisst HQC som reserve nettopp fordi den bygger på annen matematikk enn ML-KEM, som beskyttelse hvis gitterbasert kryptografi skulle vise seg sårbar i fremtiden.
Må norske virksomheter bytte til post-kvante kryptografi nå?
EUs koordinerte veikart krever at kritisk infrastruktur, inkludert finans, telekom og offentlig forvaltning, er sikret med post-kvante kryptografi senest innen utgangen av 2030, med nasjonale planer klare innen 2026. NSM i Norge gir tilsvarende, men ikke-bindende veiledning, så virksomheter bør uansett starte kartleggingen nå.
11. mars 2025 tok NIST en beslutning som rammet halvparten av kandidatfeltet i den fjerde runden av standardiseringsprosessen for post-kvante kryptografi. HQC ble valgt som femte algoritme og reserveløsning ved siden av ML-KEM. BIKE, som hadde vært med siden 2017, ble ikke valgt. Begge er kodebaserte nøkkelinnkapslingsmekanismer (KEM-er) bygget på en helt annen matematikk enn gitter-baserte ML-KEM, men bare én av dem har nå en vei mot en offisiell FIPS-standard. Denne artikkelen går gjennom nøkkelstørrelser, ytelsestall fra tre uavhengige kilder, årsaken til at BIKE falt fra, og hva valget betyr for virksomheter i Norge og Norden som må planlegge overgangen til post-kvante kryptografi innen fristene EU har satt.
For lesere som følger med på kryptoutviklingen, er dette mer enn en fotnote i en standardiseringsprosess. Valget påvirker hvilke biblioteker som får videre finansiering og vedlikehold, hvilke algoritmer produsenter av nettverksutstyr velger å bygge inn i maskinvareakselerasjon, og hvilke kombinasjoner virksomheter bør teste når de først går løs på migreringen. En feil satsing nå kan bety at et team bruker måneder på å integrere en algoritme som aldri blir stående som standard.
Hva er HQC og BIKE, og hvorfor sammenlignes de?
Både HQC og BIKE tilhører familien av kodebaserte kryptosystemer, en gren av kryptografi som bygger sikkerhet på vanskeligheten av å dekode tilfeldige lineære koder. Det er den samme grunnideen som Classic McEliece bruker, men HQC og BIKE er konstruert med strukturerte, sykliske koder for å holde nøklene mye mindre. NIST inkluderte begge i fjerde runde av sin post-kvante-standardiseringsprosess nettopp fordi komiteen ønsket minst én reserve-KEM som ikke deler matematisk grunnlag med ML-KEM. Hvis det noen gang dukker opp et gjennombrudd mot gitterbasert kryptografi, skal ikke hele internett stå uten alternativ.
Bakteppet er en annen kandidat som allerede har falt: SIKE, en isogenibasert KEM som var med gjennom hele fjerde runde, ble brutt med en klassisk (ikke-kvante) datamaskin i 2022, kort tid etter at den så ut til å nå mållinjen. Hendelsen minnet hele forskningsmiljøet om at matematisk mangfold ikke bare er teoretisk forsiktighet, det er en forsikring mot at ett enkelt kryptoanalytisk gjennombrudd slår ut flere systemer samtidig. Det er nøyaktig den logikken som ligger bak at NIST insisterte på en kodebasert reserve ved siden av gitterbaserte ML-KEM, og som gjorde at både HQC og BIKE ble tatt så langt i vurderingen før bare én av dem gikk videre.
Hva er HQC (Hamming Quasi-Cyclic)?
HQC, utviklet av et fransk-ledet forskerteam med Philippe Gaborit i spissen, bruker kvasi-sykliske koder kombinert med en Reed-Muller/Reed-Solomon-basert dekoder. Den siste spesifikasjonen, datert 22. august 2025, definerer tre parametersett kalt HQC-1, HQC-3 og HQC-5, tilpasset NISTs sikkerhetsnivå 1, 3 og 5. Et sentralt poeng ved HQC er at dekodingsfeilraten kan bevises matematisk ned mot under 2 opphøyd i minus 128, noe komiteen har vektlagt tungt i vurderingen.
Hva er BIKE (Bit Flipping Key Encapsulation)?
BIKE bruker QC-MDPC-koder (quasi-cyclic moderate density parity check) og en bit-flipping-dekoder som er raskere å implementere i maskinvare, men vanskeligere å bevise sikker i alle tilfeller. Prosjektet har eksistert siden 2017 og var lenge sett på som en solid kandidat nettopp fordi nøklene er mindre enn HQCs. Problemet, som skal vise seg å bli avgjørende, ligger ikke i hastigheten, men i hvor pålitelig man kan garantere at dekodingen faktisk lykkes hver gang.
NIST-beslutningen 11. mars 2025: HQC inn, BIKE ut
Da NIST offentliggjorde valget av HQC som femte post-kvante-algoritme, var begrunnelsen ikke at BIKE var for treg eller for stor. Tvert imot har BIKE mindre nøkler enn HQC på hvert sikkerhetsnivå. Årsaken var at analysen av BIKEs dekodingsfeilrate, kjent som DFR, ikke ble ansett som moden nok til å garantere IND-CCA2-sikkerhet ved standardisering i produksjonsskala. Cryptomathic har dokumentert at NIST forventer en HQC-kladdstandard i 2026 og en ferdig standard i 2027, mens BIKE ikke har noen tilsvarende vei videre i standardiseringsløpet. Classic McEliece, den tredje kodebaserte kandidaten, ble heller ikke standardisert, i hovedsak fordi nøklene er for store til praktisk bruk i de fleste protokoller.
Valget markerer også noe prinsipielt: NIST har nå to KEM-er på vei mot standard, ML-KEM (FIPS 203) som hovedalgoritme og HQC som eksplisitt reserve bygget på annen matematikk. Postquantum.wiki oppsummerer at HQC ble valgt fordi sikkerheten ikke hviler på gitter, altså fordi den gir kryptografisk mangfold hvis gitterbaserte metoder skulle svikte. BIKE forsvinner ikke fra forskningsmiljøet med det samme, men mister momentum og ressurser når det ikke lenger finnes en standardiseringsfrist å jobbe mot.
Det er verdt å understreke hvor tett løpet var før avgjørelsen falt. Både HQC og BIKE hadde vært gjennom flere runder med offentlig kryptoanalyse, parameterjusteringer og implementasjonsgjennomganger siden 2017. Forskjellen som til slutt avgjorde saken, var ikke et brudd på selve krypteringen, men hvor stabilt man kunne bevise at dekodingsprosessen alltid lykkes. Det illustrerer noe som ofte overses i offentlig diskusjon om post-kvante kryptografi: valget mellom algoritmer handler sjelden bare om nøkkelstørrelse eller hastighet, men om hvor solid matematikken bak feilhåndteringen er når systemet settes under press fra en angriper som aktivt prøver å fremprovosere feil.
Nøkkelstørrelser og spesifikasjoner: full sammenligning
Tallene under er hentet fra HQCs offisielle spesifikasjon (22. august 2025) og fra publisert dokumentasjon av BIKE-L1. ML-KEM-768 er tatt med som referansepunkt siden det er algoritmen de fleste virksomheter allerede har begynt å rulle ut i TLS 1.3. Legg merke til hvor mye raskere chiffertekststørrelsen vokser for HQC enn for BIKE og ML-KEM etter hvert som sikkerhetsnivået øker.
| Egenskap | HQC-1 (nivå 1) | HQC-3 (nivå 3) | HQC-5 (nivå 5) | BIKE-L1 (nivå 1) | ML-KEM-768 (referanse) |
|---|---|---|---|---|---|
| Matematisk grunnlag | Kvasi-sykliske koder | Kvasi-sykliske koder | Kvasi-sykliske koder | QC-MDPC-koder | Strukturerte gitter |
| NIST-sikkerhetsnivå | 1 | 3 | 5 | 1 | 3 |
| Offentlig nøkkel | 2 241 byte | 4 514 byte | 7 237 byte | 1 541 byte | 1 184 byte |
| Privat nøkkel | 2 321 byte | 4 602 byte | 7 333 byte | 281 byte | 2 400 byte |
| Chiffertekst | 4 433 byte | 8 978 byte | 14 421 byte | 1 573 byte | 1 088 byte |
| Delt hemmelighet | 32 byte | 32 byte | 32 byte | Ikke offentliggjort i tilgjengelige 2025/2026-kilder | 32 byte |
| Offentlig nøkkel + chiffertekst | ≈6 674 byte | ≈13 492 byte | ≈21 658 byte | ≈3 114 byte | ≈2 272 byte |
| Dekodingsfeilrate (DFR) | Under 2⁻¹²⁸ (bevist) | Under 2⁻¹²⁸ (bevist) | Under 2⁻¹²⁸ (bevist) | Ned mot 2⁻¹¹⁷ for svake nøkler (ifølge NIST IR 8545) | Ikke relevant (deterministisk) |
| NIST-status september 2026 | Kladd-FIPS ventet 2026 | Kladd-FIPS ventet 2026 | Kladd-FIPS ventet 2026 | Ikke valgt for standardisering | Ferdig standard (FIPS 203) |
| Støttet i liboqs siden | v0.14.0 (august 2025) | v0.14.0 (august 2025) | v0.14.0 (august 2025) | v0.14.0 (august 2025) | Fra første utgivelse |
| Kryptografisk mangfold vs. gitter | Ja, kodebasert | Ja, kodebasert | Ja, kodebasert | Ja, kodebasert | Nei, gitterbasert |
Tabellen viser den grunnleggende avveiningen: BIKE-L1 er om lag 2,1 ganger mindre i kombinert nøkkel- og chiffertekststørrelse enn HQC-1, mens ML-KEM-768 fortsatt er mest kompakt av alle tre. Én kilde, Quanchains gjennomgang av BIKE og HQC, oppsummerer forskjellen presist: HQCs chiffertekst og offentlige nøkkel er henholdsvis rundt 2,9 og 1,5 ganger større enn BIKEs på tilsvarende nivå. Den ekstra plassen HQC bruker, er prisen for en dekodingsfeilrate som lar seg bevise matematisk, noe BIKE ikke klarer på samme måte.
Ytelse i praksis: hva sier benchmarkene?
Byte-tall forteller bare halve historien. I praktisk drift, spesielt på servere som håndterer millioner av TLS-håndtrykk daglig, teller også hvor mange CPU-sykluser hver operasjon koster. Tre uavhengige kilder har publisert benchmarktall for HQC og BIKE i 2025 og 2026, og de peker i samme retning: HQC er konsekvent raskere enn BIKE på nøkkelgenerering og dekapsulering, til tross for de større nøklene. Testmiljøene er ikke identiske, ulike kilder bruker ulik maskinvare og ulike kompilatorinnstillinger, så de absolutte tallene bør leses som indikasjoner på retning og størrelsesorden snarere enn som eksakte fasitsvar som lar seg sammenligne tall for tall på tvers av tabellen.
| Operasjon | HQC | BIKE | ML-KEM-768 | Kilde |
|---|---|---|---|---|
| Nøkkelgenerering (HQC-128-profil) | 87 kilosykluser | Ikke oppgitt i denne kilden | Ikke oppgitt i denne kilden | NIST HQC-presentasjon (Gaborit, 2024) |
| Innkapsling (HQC-128-profil) | 204 kilosykluser | Ikke oppgitt i denne kilden | Ikke oppgitt i denne kilden | NIST HQC-presentasjon (Gaborit, 2024) |
| Dekapsulering (HQC-128-profil) | 362 kilosykluser | Ikke oppgitt i denne kilden | Ikke oppgitt i denne kilden | NIST HQC-presentasjon (Gaborit, 2024) |
| Nøkkelpar-generering, testmiljø 2025 | ≈0,10 ms | ≈0,12 ms | ≈0,04 ms (Kyber/ML-KEM) | OnlineHashCrack PQC Benchmark 2025 |
| Dekapsulering, relativ hastighet | Referanse | 5 til 7 ganger tregere enn HQC | Raskere enn begge | Postquantum.com, 2025-oppdatering |
| Nøkkelgenerering, relativ hastighet | Referanse | 6 til 10 ganger tregere enn HQC | Raskere enn begge | Postquantum.com, 2025-oppdatering |
| Chiffertekststørrelse, relativ | ≈2,9 ganger større enn BIKE | Referanse (mindre) | Mindre enn begge | Watchdata, 2026 |
| Nøkkelgenerering, median | Ikke oppgitt i denne kilden | Ikke oppgitt i denne kilden | 9,0 mikrosekunder | QNSP PQC-benchmarkdata |
| Innkapsling, median | Ikke oppgitt i denne kilden | Ikke oppgitt i denne kilden | 10 mikrosekunder | QNSP PQC-benchmarkdata |
| Dekapsulering, median | Ikke oppgitt i denne kilden | Ikke oppgitt i denne kilden | 11 mikrosekunder | QNSP PQC-benchmarkdata |
Mønsteret er konsistent på tvers av alle tre kildene: HQC vinner på hastighet i nesten alle operasjoner, BIKE vinner på nøkkelstørrelse, og ML-KEM-768 slår begge på nesten alt. Det siste er ingen overraskelse ettersom ML-KEM har vært hovedprioritet for optimalisering siden det ble valgt som primær KEM. For HQC og BIKE er ytelsesforskjellen stor nok til å merkes på servere med høyt handshake-volum, men liten nok til at valget i praksis avgjøres av sikkerhetsanalysen snarere enn av rå fart.
Kilosykler er ikke et tall folk flest forholder seg til daglig, men det oversettes greit til praksis: en moderne serverprosessor klokket rundt 3 gigahertz utfører rundt tre millioner sykluser per millisekund, så en dekapsulering på 362 kilosykluser tar brøkdelen av et millisekund selv på eldre maskinvare. Forskjellen mellom HQC og BIKE blir først synlig i aggregert form, når en lastbalanserer skal håndtere titusenvis av samtidige håndtrykk i sekundet og hver mikrosekund ekstra CPU-tid legger seg oppå hverandre. Det er også derfor selskaper som driver CDN-infrastruktur i stor skala måler i mikrosekunder og prosentpoeng CPU-belastning, ikke bare i millisekunder per enkeltforespørsel.
Sikkerhetsproblemet som felte BIKE: dekodingsfeilrate
Kjernen i BIKEs problem ligger i NIST IR 8545, statusrapporten fra fjerde runde av standardiseringsprosessen. Rapporten dokumenterer at bestemte klasser av svake nøkler kan drive den gjennomsnittlige dekodingsfeilraten for BIKE-nivå 1 opp mot 2 opphøyd i minus 117, et stykke unna målet på 2 opphøyd i minus 128 som kreves for å garantere IND-CCA2-sikkerhet på dette nivået. Forskere har vist at man kan justere parametrene, blant annet ved å øke blokklengden fra 12 323 til 13 477, og komme ned mot en mer konservativ DFR på rundt 2 opphøyd i minus 129,5 for typiske nøkler. Problemet er at analysen fortsatt ikke dekker alle tilfeller like solid, og det er nettopp denne usikkerheten NIST pekte på da BIKE ble utelatt.
HQC har ikke det samme problemet. Spesifikasjonen fra august 2025 beviser en dekodingsfeilrate godt under 2 opphøyd i minus 128 for alle tre sikkerhetsnivåene, uten behov for de samme unntaksklassene av svake nøkler som plager BIKE. For en standardiseringskomité som skal garantere sikkerhet i produkter som kan stå i drift i tiår framover, er en matematisk bevist feilrate mer verdt enn noen få hundre byte spart i hvert håndtrykk.
Hvorfor er DFR i det hele tatt et sikkerhetsproblem og ikke bare et pålitelighetsproblem? Svaret ligger i hva som skjer når en dekoding feiler i et system som skal være IND-CCA2-sikkert: hver mislykket dekoding kan, dersom den skjer på en forutsigbar måte, lekke informasjon om den hemmelige nøkkelen tilbake til en angriper som observerer systemet nok ganger. Jo høyere og mer uforutsigbar feilraten er, desto flere slike lekkasjepunkter finnes det å utnytte. Det er denne koblingen mellom pålitelighet og faktisk hemmeligholdelse som gjør at NIST behandler DFR som et kjernespørsmål i sikkerhetsbeviset, ikke som en ren ytelsesdetalj som kan fikses i en senere versjon.
Sidekanalangrep: nøkkelgjenoppretting mot BIKE i 2026
DFR-svakheten er ikke bare et teoretisk problem. En artikkel publisert i Moroccan Journal of Algebra and Geometry i 2026 beskriver en konkret timing-basert nøkkelgjenopprettingsangrep mot BIKEs dekapsuleringsrutine. Angrepet utnytter at rutinen for avvisningssampling (rejection sampling), som brukes til å generere feilvektorer med fast vekt, lekker informasjon om når dekodingen mislykkes. Ved å måle tidsbruk kan en angriper avgjøre om dekodingen feilet, og dermed hente ut informasjon om avstandsspekteret til den hemmelige nøkkelen. Forfatterne anslår at angrepet krever rundt 58 millioner spørringer mot et orakel for å lykkes, et stort men ikke urealistisk antall for en motivert angriper med tilgang til mange forsøk.
Ingen offentlig CVE-identifikator er registrert for svakheten per dags dato. SUSE har likevel patchet BIKE-implementasjonen i liboqs og oqs-provider med konstant-tid-fikser hentet fra oppstrøms-prosjektet, uten å referere til en egen sårbarhetsidentifikator i sikkerhetsbulletinen. Dette er et mønster som går igjen i forskningen på BIKE: dekodingsfeil og variabel kjøretid henger sammen, og begge kan i teorien utnyttes av en angriper som klarer å tvinge fram nok mislykkede dekodinger. HQC er ikke immun mot alle former for sidekanalangrep, men den bevist lave DFR-en gjør denne konkrete angrepsklassen langt vanskeligere å utnytte.
NIST har for øvrig pekt på at den samme klassen av sårbarheter, variabel kjøretid i avvisningssampling, i prinsippet kan ramme både HQC og BIKE dersom implementasjonen ikke er konstant-tid. Forskjellen er at HQCs teoretiske feilrate er så lav at antallet mislykkede dekodinger en angriper trenger å observere, blir upraktisk høyt selv i et scenario med perfekt timing-måling. For BIKE, der feilraten i visse nøkkelklasser er mange størrelsesordener høyere, blir det samme angrepet langt mer gjennomførbart, noe forskningsartikkelen fra 2026 demonstrerer i praksis. Konklusjonen for utviklere er enkel: konstant-tid-implementasjon er nødvendig for begge algoritmer, men den gir langt bedre beskyttelse når den underliggende feilraten allerede er lav.
Bibliotekstøtte: liboqs, OpenSSL, wolfSSL og BoringSSL
Open Quantum Safe-prosjektet, som driver referansebiblioteket liboqs, la til begge algoritmene tidlig og fortsetter å vedlikeholde dem. I versjon 0.14.0, sluppet 21. august 2025, listes HQC og BIKE begge blant støttede KEM-familier sammen med Classic McEliece, FrodoKEM, Kyber, ML-KEM og NTRU-Prime. Interessant nok var HQC-implementasjonen periodevis deaktivert som standard etter at en sikkerhetssvakhet ble oppdaget i en tidligere kodeversjon, før den ble oppdatert til den nyeste NIST-spesifikasjonen fra 22. august 2025 og aktivert igjen. Versjon 0.15.0, fra januar 2026, tilbyr totalt 35 KEM-algoritmer, med tre parametersett hver for både BIKE og HQC.
Der bibliotekstøtten skiller seg fra hverandre, er i hvor «native» støtten er. OpenSSL 3.5 og nyere støtter ML-KEM, ML-DSA og SLH-DSA direkte i kjernebiblioteket, men verken HQC eller BIKE er del av dette. Begge er i stedet tilgjengelige via OQS-provideren, en plugin bygget på liboqs. wolfSSL har i sitt PQC-veikart oppført HQC som en planlagt fremtidig utvidelse ved siden av ML-KEM, ML-DSA, SLH-DSA, LMS og XMSS, mens BIKE ikke er nevnt i det hele tatt som kommende funksjon. BoringSSL har ingen offisiell støtte for verken HQC eller BIKE i hovedgrenen, og eksperimentering skjer kun gjennom forgreninger koblet mot liboqs. Signalet fra økosystemet er tydelig: HQC har fortsatt et aktivt utviklingsspor, BIKE blir vedlikeholdt, men ikke videreutviklet mot produksjonsbruk.
For team som allerede kjører OQS-provideren i test eller pilot, er dette en praktisk fordel: begge algoritmene finnes side om side i samme kodebase, med samme API og samme kommandolinjeverktøy, noe som gjør det billig å kjøre HQC og BIKE mot hverandre i egne benchmarker før man tar en produksjonsbeslutning. Den tekniske terskelen for å prøve begge er med andre ord lav. Den strategiske risikoen ved å bygge en langsiktig produksjonsavhengighet til BIKE er derimot høy, uavhengig av hvor enkelt det er å kompilere biblioteket i dag, fordi det ikke finnes noen NIST-standard å forholde seg til når andre komponenter i stacken etter hvert krever FIPS-sertifisering.
# Sjekk hvilke PQC-KEM-er som er tilgjengelige via OQS-provideren
openssl list -kem-algorithms -provider oqsprovider
# Test et TLS 1.3-håndtrykk med hybrid ML-KEM-768 (produksjonsklar i dag)
openssl s_client -groups x25519_mlkem768 -connect example.com:443
# Test et eksperimentelt håndtrykk med HQC-1 (kun for forskning/testing)
openssl s_client -groups x25519_hqc1 -connect localhost:4433Kommandoene over forutsetter at OQS-provideren er installert og registrert i OpenSSLs konfigurasjonsfil. Mange team setter opp et lite testmiljø akkurat slik, med en lokal server konfigurert til å tilby flere PQC-grupper samtidig, for å måle håndtrykkstider og pakkestørrelser før noe rører produksjonstrafikk. Dette er også en praktisk måte å avdekke om mellomliggende utstyr, som eldre brannmurer eller lastbalanserere, håndterer de større ClientHello-meldingene korrekt, siden det er nettopp den typen infrastruktur som historisk har skapt de fleste overraskelsene i tidlige PQC-utrullinger.
Kostnad og infrastrukturbehov ved storskala drift
Verken HQC eller BIKE koster noe i lisens, begge er åpen kildekode og fritt tilgjengelige gjennom liboqs. Den reelle kostnaden ligger i båndbredde, minnebruk og pakkefragmentering, ikke i kroner per nøkkel. Jo større chiffertekst, desto mer data må sendes i hvert håndtrykk, og for tjenester med milliarder av tilkoblinger i måneden blir selv noen hundre ekstra byte merkbart i regnskapet. For en liten eller mellomstor norsk virksomhet med noen tusen daglige TLS-forbindelser er denne kostnaden i praksis neglisjerbar, men for banker, telekomoperatører og offentlige portaler med nasjonal trafikk er det en linjepost verdt å regne på før man låser seg til én algoritme.
| Kostnadsfaktor | HQC | BIKE | ML-KEM-768 (referanse) |
|---|---|---|---|
| Lisens / bruksrett | Gratis, åpen kildekode | Gratis, åpen kildekode | Gratis, åpen kildekode |
| Native støtte i OpenSSL 3.5+ | Nei, kun via OQS-provider | Nei, kun via OQS-provider | Ja, innebygd |
| Planlagt støtte i wolfSSL | Ja, oppført som fremtidig utvidelse | Ikke nevnt i veikartet | Allerede støttet (FIPS 203) |
| Ekstra data pr. nøkkelutveksling (nivå 1) | ≈6 674 byte | ≈3 114 byte | ≈2 272 byte |
| Krav til embedded/IoT-maskinvare | Høyere minnebehov, risiko for pakkefragmentering | Lavere minnebehov, men usikker dekodingsytelse | Lavest ressursbruk av de tre |
| Standardiseringsstatus (kostnad ved implementering nå) | Kladd-FIPS ventet 2026, kan endres før ferdigstillelse | Ingen standard kommer, implementering er permanent eksperimentell | Ferdig standard, stabil å bygge mot |
Som referanse har Cloudflare offentliggjort tall for hvor mye hybrid ML-KEM-768 legger til et TLS-håndtrykk: en klient som bruker X25519MLKEM768 sender en nøkkeldel på 1 216 byte mot 32 byte for ren X25519, noe som ofte skyver ClientHello-meldingen over grensen for én enkelt nettverkspakke. Skaleres dette opp til en tjeneste med én milliard håndtrykk i måneden og rundt 2,27 kilobyte ekstra data per hybrid tilkobling, blir det snakk om i overkant av 2 terabyte ekstra utgående trafikk hver måned bare fra nøkkelutvekslingen. HQC, med sin større chiffertekst, vil legge til proporsjonalt mer i et tilsvarende scenario, mens BIKE ligger mellom de to andre.
Cloudflare har også vist hvordan kostnaden vokser videre når signaturalgoritmer legges til håndtrykket: en oppgradering av sertifikatkjeden til ML-DSA legger til rundt 14,7 kilobyte per TLS-håndtrykk, og selskapet har anslått at en full oppgradering av egne sertifikater ville kreve rundt 1,8 terabit per sekund i ekstra kapasitet, tilsvarende omtrent 0,6 prosent av selskapets totale nettverkskapasitet. Tallene er hentet fra ML-DSA-signaturer, ikke fra HQC eller BIKE spesifikt, men de illustrerer størrelsesordenen infrastrukturteam bør planlegge for når nøkkelutveksling og signering oppgraderes samtidig, noe som uansett må skje for at post-kvante-migreringen skal gi reell beskyttelse.
Migrasjonsguide: fra klassisk til post-kvante nøkkelutveksling
Uansett om målet er ML-KEM alene eller en hybridløsning med HQC som reserve, følger de fleste virksomheter det samme grunnmønsteret. Migrering til post-kvante kryptografi er sjelden en «rip and replace»-øvelse, den skjer stegvis over flere år, med hybridmodus som mellomstasjon slik at klassisk kryptografi fortsatt gir beskyttelse dersom noe skulle vise seg galt med de nye algoritmene tidlig i utrullingen. Her er stegene som gir minst risiko for driftsavbrudd underveis.
- Kartlegg alle steder i systemporteføljen der RSA, ECDH eller andre klassiske nøkkelutvekslingsalgoritmer brukes i dag, inkludert tredjepartstjenester og interne API-er.
- Prioriter TLS-endepunkter mot internett først, siden disse er mest eksponert for «harvest now, decrypt later»-angrep der data lagres i dag for å knekkes senere med en kvantedatamaskin.
- Innfør hybridmodus med X25519MLKEM768 som førstevalg, siden dette allerede er standardisert (FIPS 203) og støttet i moderne nettlesere og serverstakker.
- Oppdater TLS-biblioteker til versjoner med OQS-provider eller native PQC-støtte, og test at eksisterende systemer takler de større håndtrykkstørrelsene uten å bryte MTU-grenser.
- Følg med på NISTs kladd-FIPS for HQC i 2026 før HQC settes i produksjon, siden parametrene i teorien kan endres fram til endelig standard i 2027.
- Unngå å bygge nye produksjonssystemer rundt BIKE, siden algoritmen ikke har noen vei mot en offisiell standard og biblioteksstøtten trolig vil trappes ned over tid.
- Test ytelse under realistisk last, spesielt for tjenester med mange samtidige håndtrykk eller begrenset båndbredde, som mobilnett eller IoT-nettverk.
- Planlegg sertifikatkjeder og PKI-infrastruktur for post-kvante signaturer (ML-DSA eller SLH-DSA) parallelt, siden nøkkelutveksling og signering må oppgraderes sammen for reell beskyttelse.
- Sett interne milepæler i tråd med EUs veikart, med nasjonale planer klare innen utgangen av 2026 og kritisk infrastruktur sikret senest innen 2030.
- Dokumenter algoritmevalg og fallback-strategi, slik at driftsteamet raskt kan bytte KEM dersom en ny sårbarhet dukker opp i ett av alternativene.
Sjekkliste før du bytter
Før produksjonssetting bør teamet bekrefte tre ting: at TLS-biblioteket faktisk støtter den valgte KEM-en i en versjon som mottar sikkerhetsoppdateringer, at nedstrøms systemer (lastbalanserere, CDN-er, brannmurer) ikke feiler på de større pakkestørrelsene, og at det finnes en dokumentert reversplan tilbake til ren klassisk kryptografi dersom noe går galt i en tidlig utrullingsfase. Mange av feilene som oppstår i praksis handler mer om MTU-fragmentering og mellomvare som ikke kjenner de nye protokollutvidelsene, enn om selve kryptoalgoritmen.
Fordeler og ulemper: HQC mot BIKE
Satt opp mot hverandre har hver algoritme klare styrker og svakheter som avgjør hvilken som passer til hvilket formål.
- HQC – fordeler: Valgt av NIST med vei mot FIPS-standard i 2027, matematisk bevist dekodingsfeilrate under 2⁻¹²⁸, aktivt vedlikeholdt i liboqs og listet som fremtidig funksjon i wolfSSL, raskere enn BIKE på nøkkelgenerering og dekapsulering i uavhengige tester.
- HQC – ulemper: Betydelig større chiffertekst enn BIKE og ML-KEM, opptil 14,4 kilobyte på høyeste sikkerhetsnivå, noe som øker risikoen for pakkefragmentering på båndbreddebegrensede nett, og spesifikasjonen er fortsatt en kladd, ikke en ferdig standard.
- BIKE – fordeler: Mindre nøkler og chiffertekst enn HQC på hvert sikkerhetsnivå, flere års kryptoanalyse i forskningsmiljøet, fortsatt tilgjengelig i liboqs for testing og forskning.
- BIKE – ulemper: Ikke valgt av NIST for standardisering, dekodingsfeilrate som i verste fall når 2⁻¹¹⁷ for svake nøkler, dokumentert nøkkelgjenopprettingsangrep via tidsmåling i 2026, ingen offisiell FIPS-vei, og biblioteksstøtten vil trolig ikke prioriteres videre.
Satt på spissen handler dette om to ulike typer risiko. Velger et team HQC, tar de på seg en kjent og målbar kostnad i form av større pakker og litt mer minnebruk, mot en klar vei til en godkjent standard. Velger de BIKE, sparer de noen kilobyte per håndtrykk i dag, men bygger på en algoritme uten standardiseringsløp og med en dokumentert, om enn krevende, angrepsvei. For de aller fleste produksjonsmiljøer er det et enkelt regnestykke.
Seks virkelige bruksområder
Valget mellom HQC, BIKE og ML-KEM ser ulikt ut avhengig av hvilken type system som skal beskyttes. Her er seks konkrete scenarier der forskjellene faktisk får betydning, og hvorfor svaret ikke er det samme i alle.
- CDN- og TLS-infrastruktur i stor skala: Tjenester som håndterer milliarder av håndtrykk bør bruke ML-KEM-768 som primær hybrid-KEM i dag, slik store nettverksoperatører allerede gjør, og vurdere HQC som sekundær algoritme først når kladd-FIPS-en er ferdig i 2026.
- Kritisk infrastruktur under EUs veikart: Finans, telekom, energi og offentlig sektor, som ifølge EU-kommisjonens koordinerte veikart skal ha post-kvante kryptografi på plass for høyrisikobruk senest innen 2030, bør bygge på standardiserte algoritmer og se på HQC som reserve, ikke på BIKE.
- Langtidsarkivering og kryptografisk mangfold: Organisasjoner som lagrer dokumenter eller helsedata i tiår framover, har god grunn til å kombinere ML-KEM med en kodebasert reserve som HQC nettopp for å unngå at ett enkelt matematisk gjennombrudd kompromitterer alt.
- Innebygde og båndbreddebegrensede enheter: IoT-sensorer og innebygd utstyr med begrenset minne og lav båndbredde bør holde seg til ML-KEM-512 eller -768 der det er mulig, siden både HQCs og BIKEs chiffertekster er tunge å sende over trege radionett.
- Forskning og undervisning: liboqs fortsetter å tilby både HQC og BIKE for eksperimentering og kryptoanalyse, noe som gjør dem verdifulle i universitetsmiljøer selv om bare den ene har en kommersiell fremtid.
- VPN- og meldingstjenester som eksperimenterer med PQC: Prosjekter bygget på OQS-provideren kan teste hybridmodus med HQC for å forberede seg på en fremtidig standard, men bør unngå å basere produksjonstrafikk på BIKE gitt sårbarhetene som er dokumentert i 2026.
Det fellestrekket som går igjen i alle seks scenarier, er at ML-KEM nesten alltid er utgangspunktet, mens HQC og BIKE spiller ulike birollar avhengig av hvor mye vekt organisasjonen legger på kryptografisk mangfold versus ren ressursbruk. Ingen av bruksområdene over peker mot BIKE som et fornuftig valg i produksjon i 2026, noe som i seg selv sier mye om hvor tungt NISTs beslutning veier når virksomheter faktisk skal velge byggeklosser for egen infrastruktur.
Norge og Norden: EUs veikart og NSMs rolle
EU-kommisjonen publiserte sin anbefaling om et koordinert veikart for post-kvante kryptografi 11. april 2024, og medlemslandene, støttet av kommisjonen, vedtok selve det koordinerte veikartet for overgangen i juni 2025. Tidslinjen er klar: innen utgangen av 2026 skal medlemslandene ha startet overgangen, med nasjonale strategier, kryptografiske kartlegginger og de første pilotprosjektene på plass, mens operatører av kritisk infrastruktur skal ha satt i gang planlegging og pilotprosjekter for høy- og middelsrisikobruk. Innen utgangen av 2030 skal høyrisikobruk og kritisk infrastruktur, deriblant finans, telekom og offentlig forvaltning, være sikret med post-kvante kryptografi. Innen 2035 er målet at migreringen er fullført for de aller fleste systemer der det er praktisk mulig.
For Norge spesifikt har Nasjonal sikkerhetsmyndighet (NSM) publisert ikke-bindende veiledning som oppfordrer virksomheter i kritiske sektorer til å kartlegge sine kryptografiske ressurser og starte overgangen nå, men uten en konkret frist eller håndhevingsmekanisme tilsvarende EUs 2030-dato. Det betyr i praksis at norske virksomheter som opererer i eller mot EU-markedet, uansett bør planlegge etter EUs tidslinje, mens rent nasjonale aktører har noe mer albuerom, men fortsatt et klart insentiv til å komme i gang før konkurrenter og regulatoriske krav tar igjen dem.
For nordiske banker, forsikringsselskaper og telekomoperatører kommer denne tidslinjen på toppen av et allerede krevende regelverkslandskap, der digital motstandsdyktighet er strengt regulert gjennom EUs finanssektorregler. Å legge post-kvante-migrering inn i samme program som eksisterende compliance-arbeid, framfor å behandle det som et frittstående IT-prosjekt, er noe flere rådgivningsmiljøer i Norden nå anbefaler, rett og slett fordi kartleggingsarbeidet i stor grad overlapper. En kryptografisk inventarliste laget for post-kvante-formål gjenbrukes direkte i revisjoner av øvrig sikkerhetsarkitektur.
Verdikt: hvem bør velge hva
Tallene peker i én klar retning. HQC vant NISTs tillit 11. mars 2025 fordi den kombinerer en matematisk bevist dekodingsfeilrate med ytelse som slår BIKE på nesten alle operasjoner, til tross for en chiffertekst som er nesten tre ganger større. BIKE var aldri det svakeste alternativet på papiret, mindre nøkler er tross alt en reell fordel, men usikkerheten rundt dekodingsfeilraten og det dokumenterte sidekanalangrepet fra 2026 gjør det vanskelig å anbefale algoritmen til noe annet enn forskning og eksperimentering.
For de fleste virksomheter er svaret enkelt: bruk ML-KEM-768 i hybridmodus som hovedløsning i dag, følg med på HQCs kladd-FIPS gjennom 2026, og hold BIKE unna produksjonssystemer. Når HQC blir en ferdig FIPS-standard i 2027, gir den et reelt sikkerhetsnett bygget på annen matematikk enn ML-KEM, noe som er verdt den ekstra båndbredden for organisasjoner som tar langsiktig kryptografisk risiko på alvor. Med EUs frist for kritisk infrastruktur i 2030 som bakteppe, er dette ikke lenger et spørsmål virksomheter i Norge og Norden kan skyve foran seg.
Det er også verdt å minne om at ingenting her er statisk. Kladd-FIPS-en for HQC kan i teorien justere parametre før den blir endelig i 2027, akkurat slik ML-KEM selv gjennomgikk mindre endringer på veien fra Kyber til FIPS 203. BIKE kan i prinsippet komme tilbake i en senere runde dersom kryptoanalysen på dekodingsfeilrate modnes betraktelig, men det finnes ingen tidslinje for det i dag, og ingen ansvarlig sikkerhetsarkitekt bør planlegge rundt en mulighet uten dato. Den praktiske leveregelen forblir den samme gjennom hele denne artikkelen: bygg på det som er standardisert, hold øye med det som er på vei til å bli det, og bruk eksperimentelle algoritmer kun der konsekvensen av en feilvurdering er lav.
Ofte stilte spørsmål
Hva er den viktigste forskjellen mellom HQC og BIKE?
Begge er kodebaserte nøkkelinnkapslingsmekanismer, men HQC har en matematisk bevist lav dekodingsfeilrate og ble valgt av NIST som femte post-kvante-standard 11. mars 2025, mens BIKE ikke ble valgt fordi analysen av dens dekodingsfeilrate ikke ble ansett som moden nok.
Hvorfor valgte NIST HQC og ikke BIKE?
Ifølge NIST IR 8545 kan BIKEs dekodingsfeilrate i verste fall nå 2⁻¹¹⁷ for visse svake nøkler, under målet på 2⁻¹²⁸ som kreves for full IND-CCA2-sikkerhet. HQC beviser en feilrate under 2⁻¹²⁸ på alle tre sikkerhetsnivåene, og ble derfor foretrukket til tross for større nøkler.
Er BIKE usikkert å bruke i dag?
BIKE har ingen kjent, praktisk utnyttbar svakhet som umiddelbart bryter alle implementasjoner, men et dokumentert nøkkelgjenopprettingsangrep fra 2026 utnytter tidsvariasjon i dekapsuleringsrutinen, og algoritmen mangler en offisiell standardiseringsvei. Det gjør den uegnet for nye produksjonssystemer.
Når blir HQC en ferdig FIPS-standard?
NIST forventer en kladd-FIPS for HQC i løpet av 2026, med endelig standard ventet i 2027, ifølge Cryptomathic og postquantum.wiki.
Støtter OpenSSL HQC og BIKE?
Ikke direkte i kjernebiblioteket. OpenSSL 3.5 og nyere har native støtte for ML-KEM, ML-DSA og SLH-DSA, mens HQC og BIKE begge krever OQS-provideren, som bygger på liboqs.
Bør jeg bruke HQC i produksjon allerede nå?
De fleste bør vente til kladd-FIPS-en er publisert i 2026 før HQC settes i skarp drift, og heller bruke ML-KEM-768 i hybridmodus som hovedløsning i mellomtiden. HQC egner seg godt til testing og pilotprosjekter allerede i dag, spesielt for team som ønsker å øve på integrasjonsarbeidet før algoritmen blir en formell standard.
Hva er forskjellen mellom HQC og ML-KEM?
ML-KEM (FIPS 203) er gitterbasert og allerede en ferdig standard, mens HQC er kodebasert og fortsatt under standardisering. NIST valgte bevisst HQC som reserve nettopp fordi den bygger på annen matematikk enn ML-KEM, som beskyttelse hvis gitterbasert kryptografi skulle vise seg sårbar i fremtiden.
Må norske virksomheter bytte til post-kvante kryptografi nå?
EUs koordinerte veikart krever at kritisk infrastruktur, inkludert finans, telekom og offentlig forvaltning, er sikret med post-kvante kryptografi senest innen utgangen av 2030, med nasjonale planer klare innen 2026. NSM i Norge gir tilsvarende, men ikke-bindende veiledning, så virksomheter bør uansett starte kartleggingen nå.
