Norske team som har migrert passordhash til Argon2id og nøkkelutveksling til ML-KEM lar ofte ett valg stå urørt: meldingsautentiseringskoden, eller MAC-en. De aller fleste API-er, webhooks og TLS-sesjoner bruker fortsatt HMAC, en konstruksjon fra 1996 bygget rundt vanlige hash-funksjoner som SHA-256. Samtidig har NIST siden desember 2016 hatt en ferdig standardisert SHA-3-native MAC liggende klar: KMAC, beskrevet i NIST SP 800-185. Få team har tatt den i bruk. I november 2024 publiserte IETF likevel RFC 9688, som bruker nettopp KMAC128 og KMAC256 i SHA-3-baserte protokoller, og et IPsec-utkast definerer egne KMAC-identifikatorer for IKEv2. Spørsmålet er ikke lenger om KMAC finnes. Spørsmålet er om det er verdt å bytte ut en MAC som har fungert i snart tretti år. Denne sammenligningen går gjennom oppbyggingen, spesifikasjonene, de ytelsestallene som faktisk finnes offentlig, kostnaden ved å bruke hver av dem i skyen, og hvilken du bør velge i 2026.
Hva er HMAC? Den velprøvde MAC-standarden
HMAC, kort for Hash-based Message Authentication Code, ble først beskrevet i RFC 2104 i 1996 og er i dag spesifisert i FIPS 198-1. Konstruksjonen er en nøstet hash-operasjon. HMAC kjører hash-funksjonen to ganger: én gang over en indre nøkkelpute (ipad) satt sammen med meldingen, og én gang over en ytre nøkkelpute (opad) satt sammen med resultatet fra det første kallet. Formelen skrives gjerne som H((K’ XOR opad) || H((K’ XOR ipad) || M)), der K’ er nøkkelen justert til hash-funksjonens blokkstørrelse.
HMAC kan bygges på nesten enhver kryptografisk hash-funksjon. HMAC-SHA-256 er standardvalget i 2026, med HMAC-SHA-512 som alternativ når lengre tagger er ønsket. Nasjonal sikkerhetsmyndighets kryptografiske anbefalinger fra 2025 slår fast at MAC-nøkler bør være minst 128 bit og at taggene bør ha samme lengde. NSM peker spesifikt på SHA-256 som anbefalt hash-funksjon for HMAC i norske systemer.
Styrken til HMAC er enkelheten. Konstruksjonen er grundig analysert i snart tretti år, implementert i praktisk talt alle kryptografibiblioteker, og brukt i TLS, JSON Web Tokens (som HS256), AWS Signature Version 4 og webhook-signering hos selskaper som Stripe og GitHub. Svakheten er at HMAC arver begrensningene fra den underliggende hash-funksjonen og legger til en nøkkelregel som kan implementeres feil: nøkler lengre enn blokkstørrelsen blir først hashet ned, kortere nøkler blir paddet opp til blokkstørrelsen. Det er ikke komplisert, men det er én ekstra detalj et egenbygget bibliotek kan bomme på.
Hva er KMAC? SHA-3-familiens native MAC
KMAC, eller Keccak Message Authentication Code, ble standardisert av NIST i SP 800-185: SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash and ParallelHash, publisert i desember 2016. I stedet for å pakke en nøkkel rundt en eksisterende hash-funksjon, bygger KMAC direkte på Keccak-svampen som også ligger under SHA-3. Dokumentet definerer to varianter: KMAC128, som sikter mot et sikkerhetsnivå på rundt 128 bit, og KMAC256, som sikter mot rundt 256 bit.
KMAC er bygget oppå cSHAKE, en domeneseparert variant av Keccaks SHAKE-funksjoner. Nøkkel, melding, funksjonsnavnet “KMAC” og en valgfri tilpasningsstreng kodes alle inn i svampens input før den absorberes og til slutt “klemmes ut” som tag. Fordi hele konstruksjonen skjer i én svamp uten et eget utgangs-hash-kall, trenger KMAC ikke HMACs to-pass-struktur. Nøkkelen trenger heller ikke hashes ned eller paddes etter HMAC-regelen. Den kodes rett inn i input og paddes til et multiplum av svampens rate, uansett lengde.
Det som gjør KMAC spesielt attraktivt på papiret, er fleksibiliteten. Samme konstruksjon kan brukes som MAC, som pseudotilfeldig funksjon og, med variabel utgangslengde, som en slags nøkkelavledningsfunksjon. RFC 9688 utnytter nettopp denne egenskapen og bruker KMAC128/KMAC256 til nøkkelavledning i protokoller som allerede har tatt i bruk SHA-3. Les mer om hvordan SHA-3-familien er bygget opp i vår egen sammenligning av SHA-256 og SHA-3.
Fra Keccak-konkurransen til KMAC: kort historikk
For å forstå hvorfor KMAC i det hele tatt eksisterer, må man tilbake til 2007. NIST lyste da ut en åpen konkurranse om en ny hash-standard, etter at teoretiske og praktiske svakheter i SHA-1 begynte å bekymre kryptografimiljøet. Du kan lese mer om hvordan det svekket SHA-1 i praksis i vår gjennomgang av SHAttered-kollisjonen fra 2017. Keccak-teamet vant konkurransen i 2012, og algoritmen ble formalisert som SHA-3 i FIPS 202 i august 2015.
Det som gjør Keccak spesielt, er at den ikke er bygget som en Merkle-Damgård-konstruksjon slik SHA-1 og SHA-2 er. Den bruker en svamp (sponge), en struktur som absorberer input og deretter “klemmer ut” output i runder. Denne fleksibiliteten åpnet for mer enn bare en hash-funksjon. Året etter FIPS 202 publiserte NIST derfor SP 800-185, som definerte fire avledede funksjoner bygget på samme svamp: cSHAKE, KMAC, TupleHash og ParallelHash. KMAC var dermed ikke en etternølende idé, men en planlagt del av hele SHA-3-prosjektet fra start. Det forklarer også hvorfor KMAC regnes som en naturlig følgesvenn til SHA-3 og ikke en konkurrent til HMAC i generell forstand. Vår sammenligning av BLAKE3 og SHA-3 går nærmere inn på hvordan svampkonstruksjonen presterer mot nyere hash-design.
Slik er de bygget opp: nøstet hash mot svamp-absorpsjon
Den strukturelle forskjellen mellom HMAC og KMAC handler om hvor mange ganger den underliggende primitiven kalles, og hvordan nøkkelen kommer inn i beregningen.
cSHAKE og domeneseparasjon
HMAC skiller sine to hash-kall med XOR-mønstrene ipad og opad, en teknikk som stammer fra 1996. KMAC bruker i stedet cSHAKEs innebygde domeneseparasjon: funksjonsnavnet “KMAC” kodes direkte inn i input sammen med en valgfri tilpasningsstreng S. Det betyr at samme nøkkel og melding aldri kan kollidere med en annen cSHAKE-basert funksjon, fordi navnet på funksjonen er en del av det som absorberes i svampen. HMAC oppnår en lignende isolasjon gjennom pute-konstruksjonen, men uten et generelt navnerom for andre funksjoner.
Nøkkelhåndtering: padding mot enkoding
HMAC normaliserer alltid nøkkelen til hash-funksjonens blokkstørrelse: for lange nøkler hashes først, for korte paddes med nuller. KMAC gjør ingenting av dette. Nøkkelen kodes med en lengdeprefiks (byte-pad og left-encode, i NIST-notasjonen) og absorberes i sin fulle lengde, opptil den teoretiske grensen på 2^2040 bit som SP 800-185 setter for både nøkkel, melding og tilpasningsstreng. I praksis betyr det at KMAC-implementasjoner slipper en hel gren av kode som HMAC-implementasjoner må ha riktig.
Antall Keccak-f-permutasjoner KMAC bruker, avhenger av meldingslengden og er derfor ikke et fast tall. KMAC128 bruker en Keccak-rate på 1344 bit, altså 168 byte per blokk, mens KMAC256 bruker en rate på 1088 bit, altså 136 byte per blokk. Begge kjører 24 runder av Keccak-f-permutasjonen per absorbert blokk. Fordi KMAC256 har en mindre rate, trenger den flere blokker for samme inndata enn KMAC128, noe som er den strukturelle prisen for det høyere sikkerhetsnivået.
KMAC, cSHAKE og SHAKE: familien bak navnet
Mange blander sammen SHAKE, cSHAKE og KMAC fordi navnene minner om hverandre og alle tre stammer fra samme Keccak-svamp. SHAKE128 og SHAKE256, definert i FIPS 202, er rene funksjoner med variabel utgangslengde (XOF, extendable-output function) uten noen form for domeneseparasjon. cSHAKE legger til nettopp det NIST kalte et “funksjonsnavn” og en “tilpasningsstreng” i SP 800-185, slik at to forskjellige bruksområder som begge bygger på Keccak, ikke kan produsere samme output for samme input. KMAC er så det siste laget: en nøkkelbasert konstruksjon bygget direkte oppå cSHAKE, der nøkkelen enkodes inn i input før meldingen.
Denne lagdelingen betyr at alt som gjelder cSHAKEs sikkerhetsbevis, i stor grad arves av KMAC. Det er en helt annen tilnærming enn HMAC, som er bevist sikker som en generisk konstruksjon uavhengig av hvilken hash-funksjon den pakkes rundt, så lenge hash-funksjonen selv oppfører seg som forventet. SP 800-185 definerer også to søskenfunksjoner i samme dokument: TupleHash, som hasher flere separate datafelter uten at de kan forveksles ved sammenslåing, og ParallelHash, som deler store meldinger i blokker som kan hashes parallelt. Ingen av dem er MAC-er i seg selv, men de viser at NIST designet hele SP 800-185-familien som verktøy for samme type infrastrukturproblemer: domeneseparasjon, parallellisering og nøkkelbasert autentisering, bygget på én felles primitiv i stedet for flere spesialtilpassede konstruksjoner.
Spesifikasjonstabell: HMAC mot KMAC side om side
Tabellen under samler de tekniske spesifikasjonene fra NIST SP 800-185, FIPS 198-1 og RFC 9688, slik de står definert i dag. Legg spesielt merke til radene om nøkkelbehandling og tag-lengde, siden det er her de to konstruksjonene faktisk ber utvikleren ta forskjellige beslutninger, ikke bare ved implementasjon, men hver gang et nytt bruksområde legges til.
| Egenskap | HMAC | KMAC |
|---|---|---|
| Standard | RFC 2104 (1996), FIPS 198-1 | NIST SP 800-185 (2016) |
| Underliggende primitiv | Hash-funksjon (SHA-256, SHA-512, SHA3-256 osv.) | Keccak-svamp via cSHAKE |
| Konstruksjonstype | Nøstet hash med ipad/opad | Nøkkelkodet svamp-absorpsjon |
| Antall primitivkall for lange meldinger | To hash-passeringer (indre og ytre) | Variabelt, én sammenhengende absorpsjon |
| Rate / blokkstørrelse | Avhenger av hash (64 byte for SHA-256) | 168 byte (KMAC128), 136 byte (KMAC256) |
| Permutasjonsrunder | Ikke relevant (bruker kompresjonsfunksjon) | 24 runder Keccak-f per blokk |
| Nøkkelbehandling | Hashes hvis for lang, paddes hvis for kort | Enkodes og absorberes i full lengde |
| Maks nøkkel-/meldingslengde | Begrenset av hash-funksjonens inputgrense | Under 2^2040 bit (nøkkel, melding, tag, streng) |
| Tag-/utgangslengde | Fast (256 eller 512 bit), kan trunkeres | Variabel lengde L, valgfri av bruker |
| Domeneseparasjon | Via ipad/opad-konstanter | Via cSHAKE-funksjonsnavn og tilpasningsstreng |
| Kan brukes som PRF | Ja, vanlig i nøkkelavledning (HKDF) | Ja, eksplisitt nevnt i SP 800-185 |
| Standardisert i TLS 1.3 | Ja, i cipher suites og HKDF | Ikke som TLS-rekordens MAC |
| Standardisert i IPsec/IKEv2 | Ja, lenge brukt | Foreslått i IETF-utkast (AUTH_KMAC_128/256) |
Ytelse og benchmark: hva viser tallene faktisk?
Her må vi være presise om hva som finnes og hva som ikke finnes. Det eksisterer ingen offentlig, fagfellevurdert benchmark som sammenligner HMAC-SHA256, HMAC-SHA3-256, KMAC128 og KMAC256 under identiske forhold på samme maskinvare. Det betyr ikke at det ikke finnes tall å forholde seg til. Det betyr at man må sette sammen tallene fra flere kilder og være tydelig på hva hver av dem faktisk måler.
Et referansebenchmark-prosjekt for SHA-3-implementasjoner, pablotron/sha3 på GitHub, dokumenterer en metodikk for å måle median sykler per byte for SHA3- og HMAC-SHA3-varianter, men offentliggjør ikke et ferdig sammenlignbart tall for KMAC mot klassisk HMAC-SHA256 i prosjektets beskrivelse. Et eldre, ofte sitert mikrobenchmark på en Intel Core i5-6600 fra 2015 viser SHA-256 til 7,63 sykler per byte og SHA-512 til 5,06 sykler per byte for lange meldinger, som gir et bakgrunnstall for hvor raskt selve hash-primitiven er før man legger på HMAC-konstruksjonens doble kall.
Det mest konkrete tallgrunnlaget for KMAC kommer fra maskinvare. OpenTitan, Googles åpne rot-av-tillit-brikke, implementerer KMAC i silisium og publiserer gjennomstrømningstall ved 100 MHz: SHA3-224-motoren leverer 2,93 byte per klokkesyklus (2,34 Gbit/s) uten sidekanalmaskering, mot 1,19 byte per syklus (952 Mbit/s) med DOM-maskering aktivert. SHA3-512-motoren, som bruker samme rate-logikk som KMAC256, leverer 1,47 byte per syklus (1,18 Gbit/s) umaskert og 0,59 byte per syklus (472 Mbit/s) maskert. Tallene viser et konsistent mønster: maskering mot sidekanalangrep koster rundt 60 prosent av gjennomstrømningen, uavhengig av hvilken SHA-3-variant som kjøres.
| Mål | Kilde | Verdi |
|---|---|---|
| SHA-256, programvare, lang melding | Core i5-6600 mikrobenchmark (2015) | 7,63 sykler/byte |
| SHA-512, programvare, lang melding | Core i5-6600 mikrobenchmark (2015) | 5,06 sykler/byte |
| KMAC128-motor (SHA3-224-rate), maskinvare, umaskert | OpenTitan, 100 MHz | 2,93 B/syklus, 2,34 Gbit/s |
| KMAC128-motor, maskinvare, DOM-maskert | OpenTitan, 100 MHz | 1,19 B/syklus, 952 Mbit/s |
| KMAC256-motor (SHA3-512-rate), maskinvare, umaskert | OpenTitan, 100 MHz | 1,47 B/syklus, 1,18 Gbit/s |
| KMAC256-motor, maskinvare, DOM-maskert | OpenTitan, 100 MHz | 0,59 B/syklus, 472 Mbit/s |
Konklusjonen av dette er ikke at den ene algoritmen vinner på rå fart. Konklusjonen er at HMAC-SHA256 i programvare er en moden, veldokumentert kostnad på de fleste CPU-er med SHA-NI-instruksjoner, mens KMACs reelle ytelse i dag hovedsakelig er dokumentert i maskinvare-IP som OpenTitan, ikke i generelle programvarebiblioteker. Det stemmer med et mønster vi også fant i vår sammenligning av HMAC og Poly1305: valg av MAC avgjøres like mye av hva maskinvaren akselererer som av den teoretiske hastigheten til primitiven.
Sikkerhet og kjent angrepsflate
Ingen offentlig kilde beskriver et praktisk brudd på verken HMAC eller KMAC under normale forhold i 2026. Begge regnes som solide konstruksjoner, men de har forskjellig angrepsflate fordi de er bygget forskjellig.
HMACs to-pass-struktur gjør konstruksjonen motstandsdyktig mot lengdeutvidelsesangrep som rammer rå hash-funksjoner som SHA-256 brukt alene. Den praktiske risikoen ligger andre steder: implementasjoner som bommer på konstant-tid-sammenligning når tagger verifiseres, timingangrep i cache-adferden til hash-kompresjonsfunksjonen på maskinvare uten akselerasjon, og feil håndtering av nøkkellengde i egenbygde biblioteker. KMAC unngår lengdeutvidelse fordi Keccak-svampen i sin natur ikke er sårbar for det samme angrepet som rammer enkle Merkle-Damgård-hasher. Nøkkelen er fullt enkodet i inputen, noe som fjerner HMACs behov for separate ipad/opad-konstanter, men det flytter ikke problemet med korrekt nonce- og implementasjonshygiene. Det fjerner bare én bestemt feilkilde.
Et poeng som ofte glemmes: KMAC-nøkler trunkeres aldri, uansett lengde. Det er en fordel for sikkerhetsanalyse, fordi man slipper å resonnere om hva som skjer når en nøkkel hashes ned til blokkstørrelsen. Samtidig betyr variabel utgangslengde i KMAC at utviklere selv må velge en tagg-lengde som er trygg. SP 800-185 fraråder tagger under 64 bit og anbefaler at applikasjoner ikke går under 32 bit i det hele tatt. NSMs 2025-anbefaling er strengere og mer praktisk: minst 128 bit for både nøkkel og tag i enhver MAC, og minst 256-bit nøkkel hvis man velger KMAC256.
Sidekanalmotstand er et område der de to i praksis skiller seg mest i hvor godt de er dokumentert, ikke nødvendigvis i hvor sikre de er på papiret. HMAC i programvare uten maskinvareakselerasjon kan lekke informasjon gjennom cache-tidsbruk i hash-kompresjonsfunksjonen hvis implementasjonen ikke er konstant-tid. KMAC-implementasjonen i OpenTitan er eksplisitt bygget med DOM-maskering (Domain-Oriented Masking) som standard sikkerhetsegenskap i maskinvaren, noe som gir et konkret, målt tallgrunnlag for kostnaden ved beskyttelse: rundt 60 prosent lavere gjennomstrømning, som vist i benchmark-tabellen over. Tilsvarende maskerte, offentlig dokumenterte tall for programvare-HMAC på vanlig serverutstyr er vanskeligere å finne, rett og slett fordi de fleste HMAC-implementasjoner lener seg på CPU-ens innebygde SHA-NI-instruksjoner og dermed flytter sidekanalspørsmålet over til prosessorprodusenten.
Standardisering: NIST, RFC 9688 og IETF-sporet
HMAC har tretti år med standardiseringshistorikk bak seg og er innbakt i så godt som alle protokoller som trenger meldingsintegritet. KMAC er yngre, men beveger seg raskere enn mange tror akkurat nå. RFC 9688, publisert 18. november 2024, spesifiserer bruk av SHA-3 sine envegsfunksjoner og bygger nøkkelavledning direkte på KMAC128 og KMAC256 slik de er definert i SP 800-185. NIST selv jobber med en revisjon: et utkast til oppdatert SP 800-185 ble sendt ut på høring i februar 2026, uten at innholdet i den endelige versjonen er avklart ennå.
Parallelt har IETFs IPsec-arbeidsgruppe publisert et utkast, draft-salter-ipsecme-sha3, som definerer egne algoritme-identifikatorer for IKEv2: AUTH_KMAC_128 med 128-bits tag og AUTH_KMAC_256 med 256-bits tag. Som et internettutkast, ikke en ferdig RFC, er dette et tegn på standardiseringsarbeid i gang, ikke bevis på bred produksjonsbruk. Det er likevel verdt å følge med på for team som planlegger IPsec-infrastruktur med lengre levetid enn fem år, ettersom slike utkast ofte varsler hvor neste generasjon VPN-konsentratorer og brannmurer kommer til å støtte MAC-algoritmer.
For norske og nordiske virksomheter under finansregulering eller sikkerhetsloven er dette mer enn en akademisk detalj. NSMs kryptografiske anbefalinger fra 2025 omtaler både HMAC og KMAC eksplisitt og setter konkrete minstekrav til nøkkel- og tag-lengde for begge. Det betyr at en virksomhet som allerede følger NSM-veilederen, ikke trenger å vente på en norsk særstandard før den kan vurdere KMAC der det gir mening. Samtidig er HMAC fortsatt det eneste av de to som er innbakt i revisjonsklare rammeverk og sertifiseringer de fleste norske leverandører allerede er vant til å dokumentere mot.
Bruk i produksjon: TLS, IPsec, maskinvare og skytjenester
I TLS 1.3 er HMAC dypt forankret, både i enkelte cipher suite-varianter og i HKDF, nøkkelavledningsfunksjonen som bygger hele nøkkelhierarkiet for en TLS-sesjon. Ingen ferdigstilt TLS-spesifikasjon gjør KMAC til en generelt brukt MAC for TLS-rekorder. Moderne TLS-trafikk lener seg uansett mer på AEAD-modi som AES-GCM og ChaCha20-Poly1305 for selve datakrypteringen, der MAC-en er bakt inn i krypteringsmodusen snarere enn beregnet separat. Les mer om hvordan kryptografiske hashfunksjoner henger sammen med slike valg i vår oversikt over kryptografiske hashfunksjoner.
I maskinvare er bildet annerledes. OpenTitan implementerer en dedikert KMAC-blokk som støtter nøkkellengder på 128, 192, 256, 384 og 512 bit, med innebygd sidekanalmaskering (DOM). Det er konkret bevis på at KMAC regnes som produksjonsmoden nok til å støpes inn i rot-av-tillit-brikker for skyservere og enheter. På skytjenestesiden er bildet motsatt: AWS KMS støtter HMAC-nøkler og operasjonene GenerateMac og VerifyMac, men verken AWS, Azure eller Google Cloud dokumenterer native KMAC-nøkkeltyper i sine administrerte nøkkeltjenester per 2026. HashiCorp Vaults Transit-motor og administrerte nøkkelintegrasjoner (mot AWS KMS, Azure Key Vault, Google Cloud KMS og PKCS#11-bakender) støtter HMAC-operasjoner, men har heller ingen dokumentert native KMAC-støtte.
OpenSSL har begynt å bevege seg. En SUSE-sikkerhetsoppdatering fra august 2026 retter en feil i “speed”-kommandoen for KMAC i FIPS-modus, noe som bekrefter at OpenSSLs FIPS-leverandør har KMAC-funksjonalitet innebygget og under aktiv vedlikehold. Det er et godt tegn for team som vil eksperimentere, men det er fortsatt et godt stykke fra å være standard i alle biblioteker.
Et viktig skille: Keccak-256 er ikke KMAC
Et vanlig misforståelse dukker opp når utviklere jobber med blokkjedesystemer. Ethereum og flere andre kjeder bruker Keccak-256 til å hashe transaksjoner og adresser, og mange antar derfor at hele Keccak-familien, inkludert KMAC, allerede er i bruk i stor skala der. Det stemmer ikke helt. Keccak-256 slik Ethereum implementerer den, er en hash-funksjon fra før FIPS 202 ble ferdigstilt, med litt andre paddingregler enn den endelige NIST-standardiserte SHA-3. Den er ikke en nøkkelbasert MAC og brukes ikke til meldingsautentisering med delt hemmelighet. KMAC er en helt separat konstruksjon, standardisert tre år senere i SP 800-185, og de to bør ikke forveksles når man vurderer hvor moden “Keccak-økosystemet” egentlig er for produksjonsbruk som MAC.
Kostnad og tilgjengelighet: pris- og støttesammenligning
Selve algoritmene er gratis og åpne. Den reelle kostnaden ligger i hvor mye infrastruktur som allerede støtter dem, og hvor mye egenutvikling som kreves for å fylle gapet. Tabellen under viser status for de store administrerte nøkkeltjenestene og maskinvaresikkerhetsmodulene per 2026.
| Tjeneste / produkt | Native HMAC-støtte | Native KMAC-støtte | Pris |
|---|---|---|---|
| AWS KMS | Ja (GenerateMac/VerifyMac) | Ikke dokumentert | 1 USD per nøkkel/måned, 0,03 USD per 10 000 API-kall, 20 000 kall gratis |
| Azure Key Vault | Ikke eksplisitt dokumentert som egen nøkkeltype | Ikke dokumentert | Avhengig av nøkkeltype og HSM-tier |
| Google Cloud KMS | Ikke eksplisitt dokumentert som egen nøkkeltype | Ikke dokumentert | Avhengig av nøkkelversjon og operasjon |
| HashiCorp Vault (Transit) | Ja, via Transit-motoren | Ikke dokumentert | Avhenger av Vault-lisens/drift, ikke en per-nøkkel-sats |
| OpenTitan (åpen maskinvare-IP) | Nei (fokus på SHA-3/KMAC) | Ja, i silisium med maskering | Åpen kildekode, ingen lisenskostnad for selve IP-en |
| YubiHSM 2 / Thales Luna HSM | Varierer med modell/firmware | Ikke offentlig dokumentert | Ingen offentlig listepris, kvoteavhengig |
Det praktiske bildet er enkelt å lese ut av tabellen. HMAC koster ingenting ekstra å bruke fordi hele skyøkosystemet allerede er bygget rundt det. KMAC koster ingenting i lisens, men det koster utviklertid, fordi svært få administrerte tjenester tilbyr det som et førstevalg i et API-kall. Et team som vil ha KMAC i produksjon i 2026, må som regel implementere eller linke inn et bibliotek selv, og i noen tilfeller legge KMAC-logikken i egen kode på toppen av en nøkkeltjeneste som kun eksponerer rå krypteringsoperasjoner.
Regner man på total kostnad over tid, ikke bare lisensavgift, blir bildet enda tydeligere. Et HMAC-prosjekt i AWS KMS har en forutsigbar driftskostnad: 1 dollar per nøkkel i måneden pluss marginale kostnader per API-kall utover den gratis kvoten på 20 000 forespørsler. Et KMAC-prosjekt har null lisenskostnad, men krever som regel en sikkerhetsgjennomgang av et egenvalgt bibliotek, egne testvektorer mot SP 800-185, og egen håndtering av nøkkelrotasjon fordi ingen ferdig administrert tjeneste gjør den jobben for deg ennå. For de fleste team er den skjulte utviklerkostnaden ved KMAC i dag høyere enn den synlige kronesummen for HMAC i en skytjeneste.
Fem reelle bruksområder i dag
Webhook-signering hos SaaS-leverandører. Stripe, GitHub og Shopify signerer webhook-kall med HMAC-SHA256. Mottakeren regner ut samme MAC over den rå forespørselskroppen og sammenligner resultatet i konstant tid, slik eksempelet i kodeseksjonen over viser. Dette er trolig den mest utbredte praktiske bruken av HMAC i norsk og nordisk SaaS-utvikling i dag, og den krever ingen ekstra infrastruktur utover en delt hemmelighet per integrasjon.
Nøkkelavledning i SHA-3-baserte protokoller. RFC 9688 bruker KMAC128 og KMAC256 direkte til nøkkelavledning for protokoller som allerede har valgt SHA-3 som primitiv, i stedet for å hente inn en separat HMAC-basert nøkkelavledningsfunksjon. Det sparer en implementasjon for å måtte vedlikeholde to forskjellige hash-familier samtidig, noe som i praksis reduserer angrepsflaten og testomfanget.
Rot-av-tillit i silisium. OpenTitan bygger KMAC inn som egen maskinvareblokk med støtte for nøkler på 128, 192, 256, 384 og 512 bit, med innebygd sidekanalmaskering. Blokken brukes til å autentisere firmware og hemmeligheter på brikkenivå før en enhet i det hele tatt starter operativsystemet sitt, noe som gjør KMAC til en kandidat i sikkerhetskritisk maskinvaredesign lenge før den blir vanlig i applikasjonskode.
API-autentisering i skytjenester. AWS KMS sine HMAC-nøkler brukes til å generere og verifisere MAC-er direkte i tjenesten, uten at applikasjonen noensinne håndterer rånøkkelen selv. Det er en driftsmodell som i dag ikke har noe KMAC-motstykke hos de store skyleverandørene, og som gjør HMAC til det praktiske valget for team som vil holde nøkler ute av egen kode.
Fremtidig IPsec/IKEv2-autentisering. IETF-utkastet for SHA-3 i IKE definerer AUTH_KMAC_128 og AUTH_KMAC_256 som egne autentiseringsmetoder. Det er et første skritt mot at VPN-konsentratorer og brannmurer etter hvert kan tilby KMAC som alternativ til dagens HMAC-baserte autentisering, selv om utkaststatusen betyr at ingen bør planlegge produksjon rundt det ennå.
Migreringsguide: fra HMAC til KMAC i sju trinn
Ingen bør bytte ut en fungerende HMAC-integrasjon uten en konkret grunn, som et krav fra RFC 9688-baserte protokoller eller et ønske om å konsolidere alt rundt SHA-3. En migrering mellom to MAC-konstruksjoner er ikke som å bytte TLS-versjon, der klienter som regel forhandler automatisk. Her må både avsender og mottaker være enige om algoritme, nøkkellengde og tilpasningsstreng samtidig, ellers feiler verifiseringen hardt og stille. Hvis beslutningen likevel er tatt, bør migreringen gjøres stegvis og med mulighet for å rulle tilbake underveis.
- Kartlegg alle steder HMAC brukes i dag: webhooks, interne API-er, JWT-signering, nøkkelavledning.
- Avgjør sikkerhetsnivå per bruksområde og velg KMAC128 eller KMAC256 ut fra NSMs anbefalte nøkkellengder.
- Velg et bibliotek med testet KMAC-implementasjon, for eksempel OpenSSLs FIPS-leverandør eller et dedikert SHA-3-bibliotek, og verifiser testvektorene mot SP 800-185.
- Design tilpasningsstrengen (S-parameteren) bevisst for hvert bruksområde, slik at ulike tjenester ikke kan forveksle hverandres MAC-er.
- Kjør HMAC og KMAC parallelt i en overgangsperiode, slik at begge tagger valideres og man kan rulle tilbake uten datatap.
- Oppdater nøkkelrotasjonsrutiner, siden KMAC-nøkler ikke trunkeres og derfor må genereres og lagres med riktig lengde fra start.
- Fjern HMAC-støtten først når alle klienter og tjenester har bekreftet KMAC-kompatibilitet i produksjonstrafikk over tid, ikke bare i test.
Kodeeksempler i Python og Node.js
Python sin innebygde hashlib-modul har lenge eksponert SHA-3- og SHAKE-funksjoner, men dokumentasjonen etablerer ikke en ferdig KMAC-funksjon i standardbiblioteket per 2026. Eksemplene under viser derfor HMAC slik det faktisk brukes i dag, og peker på hva en KMAC-kodebase må gjøre annerledes.
# Python: HMAC-SHA256 slik det brukes i produksjon i dag
import hmac
import hashlib
key = b"hemmelig-delt-nokkel"
melding = b"webhook-payload-fra-betalingsleverandor"
tag = hmac.new(key, melding, hashlib.sha256).hexdigest()
print(tag)
# Verifisering i konstant tid, aldri med ==
mottatt_tag = "..."
gyldig = hmac.compare_digest(tag, mottatt_tag)
// Node.js: HMAC-SHA256 med innebygd crypto-modul
const crypto = require('crypto');
const key = 'hemmelig-delt-nokkel';
const melding = 'webhook-payload-fra-betalingsleverandor';
const tag = crypto.createHmac('sha256', key).update(melding).digest('hex');
// Konstant-tid sammenligning
const gyldig = crypto.timingSafeEqual(
Buffer.from(tag, 'hex'),
Buffer.from(mottattTag, 'hex')
);
Legg merke til hva som mangler i disse eksemplene sammenlignet med en KMAC-kodebase. Det er ingen eksplisitt tilpasningsstreng, ingen valgfri utgangslengde og ingen enkoding av nøkkelen inn i selve inputen. Alt det er skjult i hash-funksjonens blokkstørrelse og ipad/opad-konstantene. Når et team etter hvert implementerer KMAC, enten via OpenSSLs KMAC-API eller et tredjepartsbibliotek, må disse parameterne settes eksplisitt for hvert bruksområde. Det gir mer kontroll, men også mer som kan konfigureres feil.
Fordeler og ulemper
HMAC – fordeler: moden i tretti år, støttet i absolutt alle språk og skytjenester, enkel mental modell, akselerert i maskinvare via SHA-NI på de fleste moderne CPU-er, og billig å drifte i AWS KMS og tilsvarende tjenester.
HMAC – ulemper: fast tagg-lengde styrt av hash-funksjonen, en nøkkelregel (hash hvis lang, pad hvis kort) som kan implementeres feil, og ingen innebygd mekanisme for domeneseparasjon utover selve konstruksjonen.
KMAC – fordeler: variabel utgangslengde, ingen trunkering av nøkler, innebygd domeneseparasjon via funksjonsnavn og tilpasningsstreng, dokumentert maskinvarestøtte med sidekanalmaskering i OpenTitan, og naturlig tilhørighet med SHA-3/Keccak-baserte systemer.
KMAC – ulemper: ingen administrert skytjeneste tilbyr det som et førstevalgs-API per 2026, begrenset bibliotekstøtte sammenlignet med HMAC, ingen fastsatt rolle i TLS-rekorder, og fortsatt begrenset praktisk programvarebenchmark å planlegge kapasitet etter.
Bruksanbefalinger: når velge hva
- Webhooks og generelle API-integrasjoner: hold deg til HMAC-SHA256. Økosystemet forventer det, og biblioteker på begge sider av integrasjonen støtter det uten ekstra arbeid.
- Nye protokoller bygget rundt SHA-3/Keccak: velg KMAC fra start, slik RFC 9688 gjør, i stedet for å blande inn en HMAC-konstruksjon oppå en SHA-3-hash.
- Maskinvare-rot-av-tillit og brikkedesign: KMAC med sidekanalmaskering, slik OpenTitan implementerer det, er et naturlig valg når angriperen kan ha fysisk tilgang til enheten.
- Administrerte skytjenester i dag: bruk HMAC via AWS KMS, Azure Key Vault eller Google Cloud KMS. Det finnes rett og slett ikke et KMAC-alternativ å velge der ennå.
- Fremtidig VPN- og IPsec-infrastruktur: følg med på IETFs KMAC-utkast for IKEv2, men ikke bygg produksjon på et internettutkast før det er en ferdig RFC.
- Nøkkelavledning med variabel lengde: KMAC er et bedre naturlig valg enn HMAC-basert HKDF når man uansett står i et SHA-3-økosystem og trenger output lengre eller kortere enn hash-funksjonens native bredde.
Konklusjon: verdikt for 2026
HMAC vinner på utbredelse. Tretti år med implementasjoner, innebygget støtte i TLS 1.3, AWS KMS til 1 dollar per nøkkel per måned, og et økosystem av biblioteker som ikke krever at noen tenker nøye gjennom en tilpasningsstreng. For de aller fleste norske og nordiske team som signerer webhooks, API-kall eller JWT-er i 2026, er HMAC-SHA256 fortsatt riktig standardvalg. Det er ingen god grunn til å bytte ut noe som fungerer uten et konkret krav som peker mot SHA-3.
KMAC vinner der standardene allerede har bestemt seg for SHA-3. RFC 9688 og IETFs IKEv2-utkast viser at protokollarbeidet beveger seg dit, og OpenTitans maskinvareimplementasjon viser at KMAC er moden nok til å styre tilgangen til hemmeligheter i et brikkes rot-av-tillit. Det som mangler i 2026, er skytjenestestøtte og et bredt sammenlignbart programvarebenchmark. Begge deler har historisk vært forutsetningen for at en MAC-konstruksjon går fra spesifikasjon til standardvalg. Inntil videre er KMAC riktig verktøy for nye SHA-3-native protokoller og maskinvaredesign, mens HMAC forblir arbeidshesten for alt annet.
Den praktiske regelen for et norsk utviklerteam i 2026 er derfor kort: spør om protokollen eller standarden du følger allerede krever SHA-3. Hvis svaret er ja, len deg på KMAC og de nøkkellengdene NSM anbefaler. Hvis svaret er nei, eller du er usikker, er HMAC-SHA256 fortsatt det tryggeste og billigste valget, og det kommer ikke til å forsvinne fra verktøykassen med det første.
Ofte stilte spørsmål om HMAC og KMAC
Er KMAC raskere enn HMAC?
Det finnes ikke et offentlig, kontrollert programvarebenchmark som sammenligner dem direkte under like forhold. Det som finnes er strukturelle tall: KMAC128 absorberer 168 byte per Keccak-runde, KMAC256 absorberer 136 byte, og begge kjører 24 permutasjonsrunder per blokk. HMACs fart avhenger i stedet av hvilken hash-funksjon den pakker inn og om CPU-en har SHA-NI-akselerasjon.
Kan jeg bruke KMAC i AWS, Azure eller Google Cloud i dag?
Nei, ikke som en egen, dokumentert nøkkeltype per 2026. AWS KMS støtter HMAC-nøkler med GenerateMac og VerifyMac, men ingen av de tre store skyleverandørene dokumenterer native KMAC-operasjoner i sine nøkkeltjenester.
Er HMAC usikker fordi den er fra 1996?
Nei. HMAC er en av de mest analyserte konstruksjonene i moderne kryptografi, og ingen kilde dokumenterer et praktisk brudd under normale forhold i 2026. Alderen er et tegn på modenhet, ikke svakhet.
Hva er egentlig forskjellen mellom KMAC og vanlig SHA-3-hashing med en hemmelig nøkkel foran?
Å sette en hemmelig nøkkel foran en melding og hashe det hele med SHA-3 er ikke det samme som KMAC og kan introdusere svakheter. KMAC enkoder nøkkelen med lengdeprefikser og domeneseparasjon definert i SP 800-185, en prosess som er spesifikt analysert for å være sikker som MAC, i motsetning til en hjemmesnekret konstruksjon.
Støtter Python og Node.js KMAC i standardbiblioteket?
Python sin hashlib eksponerer SHA-3 og SHAKE, men dokumentasjonen etablerer ikke en ferdig innebygd KMAC-funksjon i standardbiblioteket per 2026. Node.js sin innebygde crypto-modul er i samme situasjon. Begge krever i praksis et tredjepartsbibliotek eller et OpenSSL-lag med eksplisitt KMAC-støtte.
Bør jeg bytte eksisterende HMAC-webhooks til KMAC?
Nei, ikke uten en konkret grunn. Ingen kilde peker på et sikkerhetsproblem i HMAC som tvinger frem et bytte, og KMAC mangler fortsatt den brede klient- og skytjenestestøtten som gjør en migrering friksjonsfri.
Hvor stor nøkkel og tag bør jeg bruke?
NSMs 2025-anbefaling er minst 128 bit for både nøkkel og tag i enhver MAC, med minst 256-bits nøkkel hvis man velger KMAC256. SP 800-185 fraråder tagger under 64 bit for KMAC og advarer uttrykkelig mot alt under 32 bit.
Er KMAC det samme som Keccak-256, hashen Ethereum bruker?
Nei. Keccak-256 slik Ethereum bruker den, er en ren hash-funksjon basert på en tidlig Keccak-variant, ikke en nøkkelbasert MAC. KMAC er en separat, nøkkelbasert konstruksjon definert i SP 800-185 og bygget på den standardiserte SHA-3/cSHAKE-familien.
Kan KMAC brukes til passordhashing i stedet for Argon2?
Nei, det er feil verktøy til oppgaven. KMAC er designet for rask meldingsautentisering med en hemmelig nøkkel, ikke for å gjøre passordgjetting treg og minnekrevende. Passordhashing bør fortsatt gjøres med en dedikert funksjon som Argon2id, slik vi går gjennom i vår egen gjennomgang av kryptografiske hashfunksjoner, uansett hvor god KMAC er til sin egen oppgave.
Trenger jeg å bytte digitale signaturer samtidig som jeg vurderer KMAC?
Nei, de to er urelaterte valg. Digitale signaturer som ECDSA og Ed25519 løser et annet problem enn en symmetrisk MAC, nemlig verifisering uten delt hemmelighet. Du kan lese mer om hvordan slike signaturalgoritmer sammenlignes i vår test av HMAC mot RSA-signaturer, som også forklarer når symmetrisk autentisering er nok og når man trenger asymmetriske signaturer.
