To autentiseringsalgoritmer avgjør i praksis om en API-forespørsel, en VPN-pakke eller en chat-melding kan stoles på. HMAC har vært standarden siden 1997, formalisert i RFC 2104, og lever videre i JWT-tokens og AWS-signaturer. Poly1305, designet av Daniel J. Bernstein og standardisert sammen med ChaCha20 i RFC 8439, driver i dag WireGuard, Signal og TLS 1.3 på mobil. Begge er meldingsautentiseringskoder (MAC-er), men de løser problemet på fundamentalt ulike måter, og valget mellom dem påvirker alt fra CPU-forbruk på en IoT-enhet til hvordan et fintech-team i Oslo signerer webhooks.

Denne artikkelen sammenligner HMAC (med hovedvekt på HMAC-SHA256) og Poly1305 (som brukt i ChaCha20-Poly1305) langs seks akser: konstruksjon, ytelse, nøkkelhåndtering, standardisering, praktisk bruk og driftskostnad. Vi går gjennom seks konkrete implementasjoner, en migreringsguide for team som vil bevege seg fra ren HMAC til AEAD-basert autentisert kryptering, og en konkret anbefaling for norske og nordiske utviklerteam i 2026.

Begge konstruksjonene løser det samme grunnproblemet: hvordan bevise at en melding kommer fra en part som kjenner en hemmelig nøkkel, og at ingen har endret innholdet underveis. Forskjellen ligger i hvordan de kommer dit. HMAC pakker inn en eksisterende hash-funksjon i to runder og stoler på hash-funksjonens motstand mot kollisjoner. Poly1305 dropper hash-tilnærmingen helt og evaluerer meldingen direkte som et polynom, noe som gjør den både raskere og mer sårbar for feilbruk. Denne motsetningen, treg men tolerant mot rask men sårbar for feilbruk, går igjen i nesten hvert avsnitt under.

Hva er HMAC? Hash-basert meldingsautentisering fra RFC 2104

HMAC står for Hash-based Message Authentication Code og ble spesifisert av Bellare, Canetti og Krawczyk i RFC 2104 i 1997. Konstruksjonen tar en vilkårlig hash-funksjon H og en hemmelig nøkkel K, og beregner H((K XOR opad) || H((K XOR ipad) || melding)). Denne doble hash-rundingen beskytter mot lengdeutvidelsesangrep som kan ramme rene hash-baserte MAC-er. Sikkerhetsbeviset er formalisert videre i NIST SP 800-107 og standardisert i FIPS 198-1, som gjør HMAC til en av de mest grundig analyserte kryptografiske primitivene som finnes. Konstruksjonen har overlevd nesten tretti år med kryptoanalyse i stor grad uendret, og selv om den underliggende hash-funksjonen har flyttet seg fra MD5 og SHA-1 til SHA-256 og nyere alternativer, står selve HMAC-oppskriften fortsatt slik den ble beskrevet i den opprinnelige artikkelen fra Bellare, Canetti og Krawczyk.

Når hash-funksjonen er SHA-256, kaller vi konstruksjonen HMAC-SHA256. Den produserer en 256-bit (32-byte) tag og krever ingen nonce. Det er kanskje den viktigste praktiske forskjellen fra Poly1305: en HMAC-nøkkel kan brukes om og om igjen på ubegrenset antall meldinger uten at sikkerheten kollapser, så lenge nøkkelen holdes hemmelig og hash-funksjonen ikke er brutt.

Slik fungerer HMAC-SHA256 i praksis

I praksis betyr HMAC-SHA256 to hash-runder per melding, noe som gir et forutsigbart og konstant beregningsmønster uansett meldingslengde eller antall meldinger. Sikkerheten er bundet av bursdagsgrensen til SHA-256, altså cirka 2^128 operasjoner for en kollisjon i praksis, langt utenfor det som er beregningsmessig mulig i dag. Fordi nøkkelen kan gjenbrukes trygt, er HMAC enkelt å bygge inn i systemer der man signerer millioner av separate forespørsler med samme delte hemmelighet, som API-nøkler, webhook-signaturer og JSON Web Tokens. Denne enkle nøkkelmodellen er trolig hovedgrunnen til at HMAC-SHA256 fortsatt er standardvalget for signering av strukturerte data, tjue år etter at RFC 2104 ble publisert.

Hva er Poly1305? Engangsnøkkel og polynomautentisering

Poly1305 tilhører en helt annen familie av MAC-konstruksjoner: universal hashing. I stedet for å kjede en hash-funksjon, evaluerer Poly1305 meldingen som et polynom over det primære feltet modulo 2^130-5, og bruker en 32-byte engangsnøkkel delt i to 16-byte deler, kalt r og s. Resultatet er en 16-byte (128-bit) autentiseringstag. Ifølge libsodiums dokumentasjon er Poly1305 formelt en “one-time authentication”-MAC: forfalskningssannsynligheten er neglisjerbar bare når nøkkelen er fersk for hver enkelt melding og aldri gjenbrukes på tvers av flere uavhengige meldinger.

Dette engangskravet er både Poly1305 sin styrke og dens begrensning. Den matematiske enkelheten gjør algoritmen svært rask, men den kan aldri brukes alene med en statisk, gjenbrukt nøkkel slik HMAC kan. Bruker man samme (r,s)-nøkkelpar til å autentisere to forskjellige meldinger utenfor den engangsdisiplinen AEAD-konstruksjonen håndhever, kan en angriper løse likningssystemet algebraisk og gjenopprette nøkkelmaterialet. Derfor opptrer Poly1305 nesten aldri alene i virkelige systemer, den kombineres med en strømchiffer som genererer en fersk engangsnøkkel per melding. Navnet Poly1305 kommer for øvrig direkte fra det matematiske grunnlaget: algoritmen evaluerer et polynom, og primtallet 2^130-5 gir det numeriske “1305” i navnet, et lite spor av at dette er en konstruksjon bygget fra tallteori snarere enn fra en kjede av hash-runder.

ChaCha20-Poly1305 som AEAD-konstruksjon

ChaCha20-Poly1305, spesifisert for IETF-protokoller i RFC 8439, løser engangsproblemet elegant. Et 256-bit langtidsnøkkel brukes sammen med en nonce til å generere en ChaCha20-keystream, og de første 32 bytene av denne strømmen brukes som en fersk, unik Poly1305-nøkkel for akkurat den meldingen. Resultatet er en AEAD-konstruksjon (Authenticated Encryption with Associated Data) der ett enkelt langtidsnøkkel trygt kan kryptere og autentisere opptil rundt 2^64 meldinger, fordi Poly1305-delnøkkelen aldri gjenbrukes.

IETF-varianten bruker en 96-bit nonce, mens den originale varianten bruker 64-bit. Libsodiums veiledning setter en praktisk grense på 256 GB data per (nøkkel, nonce)-par for ChaCha20-Poly1305-IETF. For systemer med tilfeldig genererte nonce-verdier, som distribuerte systemer uten sentral tellerkoordinering, anbefaler libsodium heller XChaCha20-Poly1305-IETF, som bruker en utvidet 192-bit nonce og dermed reduserer risikoen for utilsiktet nonce-kollisjon betraktelig. XChaCha20-Poly1305 er ikke IETF-standardisert, men er bredt implementert, blant annet i libsodium siden versjon 1.0.12.

Teknisk sammenligning: HMAC vs Poly1305 side om side

Tabellen under stiller opp de viktigste tekniske egenskapene til HMAC-SHA256 og Poly1305/ChaCha20-Poly1305. Legg merke til at Poly1305 sjelden vurderes isolert i produksjon, den evalueres nesten alltid som del av ChaCha20-Poly1305-pakken, så kolonnen dekker begge nivåer der det er relevant.

EgenskapHMAC (HMAC-SHA256)Poly1305 / ChaCha20-Poly1305
AlgoritmetypeHash-basert MAC (iterert konstruksjon)Universal hashing, polynomevaluering (engangs-MAC)
StandardiseringRFC 2104 (1997), FIPS 198-1, NIST SP 800-107RFC 8439 (2018, ChaCha20-Poly1305 for IETF)
NøkkelstørrelseVariabel, typisk 256 bit32-byte engangsnøkkel (r,s), 256-bit langtidsnøkkel i AEAD
Tag-/utdatastørrelse256 bit (SHA-256-varianten)128 bit (16 byte)
NoncekravIngen nonce nødvendigObligatorisk, 96-bit (IETF) eller 192-bit (XChaCha20)
NøkkelgjenbrukTrygt over ubegrenset antall meldingerKun trygt som fersk engangsnøkkel per melding/nonce
Datagrense per nøkkel/nonceIngen praktisk grense (bursdagsgrense til hash)256 GB per (nøkkel, nonce)-par (libsodium, IETF-variant)
Meldingsgrense per langtidsnøkkelPraktisk ubegrensetOpptil ca. 2^64 meldinger i AEAD-modus
Typisk bruksområdeJWT, AWS SigV4, API-signering, webhooksVPN (WireGuard), TLS 1.3, meldingskryptering (Signal)
MaskinvareakselerasjonSHA-NI (x86), ARMv8 SHA2-utvidelserIngen dedikert maskinvare, men SIMD-vennlig (AVX2/NEON)
Ytelse uten spesialmaskinvareMiddels (avhenger av SHA-256-implementasjon)Høy (enkel modulær aritmetikk)
Egnet uten AES-NI/kryptomaskinvareJa, men fordel med SHA-utvidelserJa, ofte foretrukket her (mobil, IoT, eldre CPU-er)
Kjente adopsjonerJWT (RFC 7519), AWS SigV4, WireGuard-håndtrykkWireGuard datakanal, TLS 1.3, Signal, WhatsApp, libsodium
Kompleksitet i implementasjonLav, godt støttet i alle standardbibliotekerModerat, krever korrekt nonce-håndtering

Legg merke til hvor mange rader som handler om nonce og nøkkelgjenbruk. Det er ikke tilfeldig. Nesten hver praktiske forskjell mellom HMAC og Poly1305 kan spores tilbake til akkurat dette ene designvalget: at HMAC ble bygget for å tåle gjentakelse, mens Poly1305 ble bygget for å være rask under forutsetning av at nøkkelen aldri gjentas. Alt annet, ytelse, standardiseringsvalg, hvilke protokoller som bruker hvilken konstruksjon, følger som konsekvens av dette ene punktet.

Ytelse og gjennomstrømning: hva viser benchmarkene?

Ytelsestall for kryptografiske primitiver varierer med CPU-arkitektur, kompilator, biblioteksversjon og om maskinvareakselerasjon er tilgjengelig. Tallene under er derfor typiske og representative størrelsesordener hentet fra flere kilder, ikke eksakte målinger fra én bestemt maskin, og bør leses som “omtrent” heller enn presise fasitverdier.

KonstruksjonTypisk gjennomstrømningSykler per byte (omtrentlig)
HMAC-SHA256 uten SHA-utvidelseromtrent 400-800 MB/sca. 12-20 sykler/byte
HMAC-SHA256 med SHA-NI / ARMv8 SHA2omtrent 1-2 GB/sca. 4-8 sykler/byte
Poly1305 aleneomtrent 1-2 GB/sca. 3-5 sykler/byte
Full ChaCha20-Poly1305 AEADomtrent 1 GB/sca. 7-10 sykler/byte

Mønsteret som går igjen på tvers av kilder: HMAC-SHA256 uten maskinvarestøtte ligger typisk lavest, mens Poly1305 isolert sett er blant de raskeste MAC-konstruksjonene som finnes, takket være enkel modulær aritmetikk fremfor gjentatte hash-runder. Når HMAC får hjelp av SHA-NI eller ARMv8 sine SHA2-utvidelser, snevres gapet inn betraktelig, og de to konstruksjonene havner i samme størrelsesorden. Den fulle ChaCha20-Poly1305-pakken, som inkluderer selve krypteringen og ikke bare autentiseringen, lander noe lavere enn Poly1305 alene fordi ChaCha20-krypteringen legger til egen beregningskostnad. For team uten kontroll på target-maskinvaren er derfor “2-3x raskere” en fornuftig tommelfingerregel for Poly1305 versus programvare-HMAC uten SHA-utvidelser, mens forskjellen nesten forsvinner på servere med moderne Intel- eller AMD-prosessorer bygget etter 2019.

Maskinvareakselerasjon: SHA-NI, AVX2/NEON og hvorfor CPU-valget betyr noe

Tallene over forklarer hvorfor valget mellom HMAC og Poly1305 sjelden kan vurderes uavhengig av hvilken maskinvare koden faktisk skal kjøre på. Intel og AMD innførte SHA-utvidelser (SHA-NI) i x86-prosessorer fra rundt 2016 og fremover, og ARM la til tilsvarende SHA2-instruksjoner i ARMv8-arkitekturen. Der disse instruksjonene finnes, kan en enkelt CPU-syklus utføre deler av SHA-256-kompresjonsfunksjonen direkte i maskinvare, og HMAC-SHA256 nærmer seg ytelsen til Poly1305 selv om de to fortsatt bruker helt forskjellige matematiske tilnærminger.

Poly1305 har derimot aldri fått en tilsvarende dedikert maskinvareinstruksjon, ganske enkelt fordi den ikke trenger det. Algoritmens kjerne er multiplikasjon og modulo-reduksjon i et 130-bit primtallsfelt, operasjoner som allerede kjører raskt på generelle SIMD-enheter som AVX2 på x86 og NEON på ARM. Det er nettopp dette som gjør Poly1305, og dermed ChaCha20-Poly1305, til et naturlig valg på plattformer der man ikke kan garantere at AES-NI eller SHA-NI finnes i prosessoren. Eldre Android-telefoner, billige IoT-brikker og en del innebygde nettverksenheter mangler ofte begge utvidelsene, og her vinner ChaCha20-Poly1305 typisk over AES-GCM og programvare-HMAC med klar margin, noe som er hovedgrunnen til at TLS 1.3-stakker som BoringSSL historisk har prioritert ChaCha20-Poly1305 høyere enn AES-GCM på mobilklienter uten kryptomaskinvare.

Sikkerhetsmodeller: nøkkelgjenbruk, nonce og angrepsflater

Det viktigste sikkerhetsskillet mellom de to konstruksjonene handler ikke om styrke, men om driftsdisiplin. HMAC krever ingen nonce og tolererer nøkkelgjenbruk over hele nøkkelens levetid, noe som gjør det vanskelig å skyte seg selv i foten operasjonelt. Sikkerheten er formelt bundet av birthday-grensen til den underliggende hash-funksjonen, dokumentert i NIST SP 800-107, og et angrep krever i praksis at man finner en kollisjon i selve hash-funksjonen.

Poly1305 er motsatt: en engangsfeil kan være katastrofal. Gjenbrukes samme (r,s)-nøkkelpar på to forskjellige meldinger utenfor AEAD-konstruksjonens engangsdisiplin, kan en angriper trekke ut nøkkelinformasjon algebraisk fra de to tag-verdiene og forfalske fremtidige meldinger. Dette er grunnen til at ChaCha20-Poly1305 alltid avleder en fersk Poly1305-nøkkel fra en unik (nøkkel, nonce)-kombinasjon for hver melding. Gjenbrukes en nonce sammen med samme langtidsnøkkel i AEAD-modus, kollapser hele sikkerhetsgarantien, ikke bare autentiseringen, men også konfidensialiteten. For konstruksjoner med 128-bit tag, som Poly1305, angir libsodium at tilfeldig genererte nonce-verdier er trygge opp til rundt 2^48 meldinger for å holde kollisjonssannsynligheten under 2^-32, noe som forklarer hvorfor XChaCha20-Poly1305 med sin 192-bit nonce foretrekkes i systemer som genererer nonce-verdier tilfeldig fremfor sekvensielt.

I praksis betyr dette at et team som velger HMAC nesten aldri trenger å bekymre seg for et helt sikkerhetsproblem: nonce-styring. Et team som velger ChaCha20-Poly1305 må derimot bygge dette inn i arkitekturen fra dag én, enten som en synkronisert teller per tilkobling, slik WireGuard gjør det for hver pakke, eller som en tilstrekkelig lang tilfeldig verdi via XChaCha20-Poly1305. Dette gjør ikke Poly1305 til en svakere algoritme i seg selv. Kryptografisk sett regnes begge konstruksjonene som trygge når de brukes riktig, men ansvaret for å bruke dem riktig flyttes fra biblioteket til utvikleren som kobler alt sammen.

Virkelige eksempler: seks protokoller som viser forskjellen i praksis

Teori er én ting, men det er i produksjonssystemer forskjellen mellom HMAC og Poly1305 blir tydelig. Under følger seks eksempler som til sammen dekker API-signering, VPN, meldingskryptering, TLS-transport og biblioteksvalg. Felles for alle seks er at valget av MAC-konstruksjon sjelden var et isolert kryptografisk spørsmål, det fulgte som regel av hvilket problem protokollen egentlig skulle løse.

HMAC i praksis: JWT og AWS SigV4

JWT og HS256. JSON Web Token, definert i RFC 7519 fra mai 2015, krever at konforme implementasjoner støtter HS256 og “none” som grunnleggende algoritmer. HS256 er rett og slett HMAC-SHA256 påført JWT-headeren og payloaden, konkatenert og base64url-kodet. Alle større JWT-biblioteker, i Node.js, Java, Python og .NET, implementerer HS256, HS384 og HS512, men ingen av dem tilbyr Poly1305-basert tokensignering. Det gjør HMAC til det ubestridte standardvalget for API-autentisering med delte hemmeligheter.

AWS Signature Version 4. AWS SigV4 pålegger algoritmestrengen “AWS4-HMAC-SHA256”. Signaturen beregnes som HMAC-SHA256(SigningKey, StringToSign), der selve signeringsnøkkelen avledes gjennom en kjede av HMAC-operasjoner over dato, region og tjenestenavn før den til slutt brukes på selve forespørselen. Denne kjedede nøkkelavledningen er mulig nettopp fordi HMAC tåler gjentatt bruk uten engangskrav. Poly1305 tilbys ikke som signeringsalternativ i SigV4, og det finnes ingen indikasjon på at AWS planlegger å legge det til, siden HMAC-modellen passer bedre til nøkkelavledningskjeden AWS bruker.

Poly1305 i praksis: WireGuard, Signal og TLS 1.3

WireGuard. WireGuard er et godt eksempel på hybridbruk av begge konstruksjonene i samme protokoll. Selve datakanalen, altså den løpende krypteringen av VPN-trafikk, bruker ChaCha20-Poly1305 for både konfidensialitet og autentisering av hver pakke. Håndtrykket og nøkkelavledningen bruker derimot HKDF bygget på HMAC, vanligvis HMAC-BLAKE2s. WireGuards tekniske whitepaper beskriver denne arbeidsdelingen eksplisitt: HMAC-baserte konstruksjoner for nøkkelavledning der gjenbruk og kjeding er en fordel, ChaCha20-Poly1305 for selve datastrømmen der hastighet og engangsnøkler er ønskelig.

Signal og WhatsApp. Signal-protokollens Double Ratchet-spesifikasjon bruker en ChaCha20-Poly1305-lignende AEAD-konstruksjon for selve meldingskrypteringen, noe som gjør Poly1305 til standard-MAC i Signal og applikasjoner bygget på samme protokoll, inkludert WhatsApp og enkelte Matrix-utrullinger. Fordi hver melding i en ende-til-ende-kryptert samtale får en unik nøkkel fra ratchet-mekanismen, passer Poly1305 sitt engangskrav naturlig inn i designet, uten at appen selv må bekymre seg for nonce-gjenbruk på tvers av separate meldinger.

TLS 1.3 og libsodium. TLS 1.3 definerer cipher-suiten TLS_CHACHA20_POLY1305_SHA256, implementert i OpenSSL, BoringSSL, LibreSSL og rustls. Denne suiten foretrekkes ofte fremfor AES-GCM på mobile og innebygde enheter som mangler AES-maskinvareakselerasjon, siden ChaCha20-Poly1305 er raskere i ren programvare. Libsodiums AEAD-veiledning anbefaler XChaCha20-Poly1305-IETF som det tryggeste standardvalget nettopp når mål-CPU-en mangler AES-NI. IETF CFRG-utkastet draft-irtf-cfrg-cryptography-specification-02 fra 7. juli 2025 viser til RFC 8439 og behandler ChaCha20-Poly1305 som en kjerneanbefalt primitiv for protokolldesign i 2025 og 2026, side om side med HMAC-basert HKDF for nøkkelavledning.

Nordiske fintech-API-er. Norske og nordiske betalings- og eID-tjenester, i mønster med Vipps og BankID Norway, følger den globale normen for symmetrisk API-forespørselssignering: HMAC-SHA256, ofte pakket inn i en JWS-struktur (JSON Web Signature). Poly1305 deltar her bare på transportlaget, gjennom TLS 1.3 sin forhandling av cipher-suite, ikke som en del av selve API-signeringen. Det betyr at et norsk fintech-team i praksis møter HMAC ved hver API-kall-signatur, og Poly1305 usynlig, ett lag lenger ned i TLS-forbindelsen. Denne to-lags-modellen, HMAC i applikasjonslaget og ChaCha20-Poly1305 eller AES-GCM i transportlaget, er trolig den vanligste kryptografiske arkitekturen i norske fintech-systemer i dag, selv om få team beskriver den eksplisitt i disse ordene når de designer API-ene sine.

Standardisering og revisjonskrav: FIPS, NIST og nordisk regelverk

Standardiseringsstatusen til de to konstruksjonene påvirker direkte hvor lett et team kan svare på revisjonsspørsmål og etterlevelseskrav. HMAC er standardisert av NIST gjennom FIPS 198-1 og videre presisert i NIST SP 800-107, som spesifikt dekker HMAC bygget på godkjente hash-funksjoner som SHA-256. For virksomheter som må kunne dokumentere FIPS-samsvar, typisk offentlig sektor, banker og selskaper med amerikanske kunder, gjør dette HMAC til et enklere valg å forsvare i en revisjonsprosess, fordi FIPS-sertifiserte kryptomoduler nesten alltid inkluderer HMAC som ferdig godkjent byggestein.

ChaCha20-Poly1305 står i en litt annen posisjon. Konstruksjonen er standardisert gjennom RFC 8439 og anerkjent av IETF, men har historisk stått utenfor de eldste FIPS-listene, selv om den er allment akseptert i moderne TLS- og VPN-implementasjoner. For nordiske fintech- og bank-API-er, som ofte må forholde seg til krav om sterk kundeautentisering og sikker dataoverføring uten at regelverket foreskriver en spesifikk algoritme, er dette sjelden et reelt hinder. De fleste norske og nordiske virksomheter velger likevel HMAC-SHA256 for selve signeringslaget rett og slett fordi det er det JWT- og SigV4-økosystemet allerede forutsetter, mens ChaCha20-Poly1305 får jobbe i bakgrunnen som del av TLS 1.3-forbindelsen uten at det krever egen dokumentasjon utover å bekrefte at cipher-suiten er godkjent av IT-sikkerhetsavdelingen.

Implementeringskostnad: bibliotekstøtte, kompleksitet og revisjon

Kryptografiske primitiver har ikke en prislapp i kroner og øre på samme måte som et produkt, men de har en reell driftskostnad i utviklertid, revisjonsomfang og operasjonell risiko. Tabellen under oppsummerer denne kostnaden fra et team-perspektiv.

KostnadsfaktorHMAC-SHA256Poly1305 / ChaCha20-Poly1305
BibliotekstøtteUniversell, innebygd i praktisk talt alle språk og TLS-stackerGod i moderne biblioteker (libsodium, OpenSSL 1.1+, rustls), svakere i eldre stacker
IntegrasjonskompleksitetLav, ingen nonce-håndtering, nøkkel gjenbrukes frittModerat, krever korrekt, garantert unik nonce per melding
CPU-overheadLav til middels, forbedres med SHA-NILav, ofte lavere enn HMAC uten maskinvarestøtte
NøkkelhåndteringskompleksitetEnkel, én langtidsnøkkel per partModerat til høy, krever nonce-generering/-sporing i tillegg til nøkkel
Revisjonskostnad (sikkerhetsgjennomgang)Lav, velkjent mønster, mange ferdige sjekklisterMiddels, revisor må verifisere nonce-unikhet og engangsdisiplin
Risiko ved feilkonfigurasjonLav, gjenbruk av nøkkel er sjelden farlig aleneHøy, nonce-gjenbruk kan gi fullstendig nøkkelkompromittering
Modenhet i standardverktøy (JWT, SigV4-stil signering)Svært høy, direkte støttetIkke støttet i disse standardene

Konklusjonen fra denne tabellen er ikke at Poly1305 er dyrere i absolutt forstand, men at kostnaden flytter seg. HMAC krever lite oppmerksomhet under drift, men gir liten fleksibilitet utover signering. Poly1305, nesten alltid i form av ChaCha20-Poly1305, krever mer nøye nonce-styring i utviklingsfasen, men betaler det tilbake i form av innebygd kryptering og typisk lavere CPU-forbruk i produksjon.

Fordeler og ulemper ved HMAC og Poly1305

HMAC-SHA256: fordeler

  • Ingen nonce-krav, nøkkel kan gjenbrukes trygt over ubegrenset antall meldinger
  • Standardvalg i JWT (HS256), AWS SigV4 og de fleste API-signeringsskjemaer
  • Godt formalisert sikkerhetsbevis via NIST SP 800-107 og FIPS 198-1
  • Universell bibliotekstøtte i alle vanlige programmeringsspråk
  • Lav operasjonell risiko, vanskelig å konfigurere feil på en katastrofal måte

HMAC-SHA256: ulemper

  • Tregere enn Poly1305 i ren programvare uten SHA-utvidelser
  • Gir kun autentisering, ingen konfidensialitet, må kombineres separat med kryptering
  • Ikke egnet som eneste byggestein i moderne AEAD-design uten HKDF-kjeding

Poly1305 / ChaCha20-Poly1305: fordeler

  • Blant de raskeste MAC-konstruksjonene i ren programvare, spesielt uten AES-NI
  • Inngår naturlig i en AEAD-pakke som gir både kryptering og autentisering samtidig
  • Foretrukket på mobil, IoT og eldre CPU-er uten kryptomaskinvare
  • Standardisert i RFC 8439, bredt implementert i OpenSSL, BoringSSL, LibreSSL og rustls
  • Ett langtidsnøkkel kan trygt kryptere opptil rundt 2^64 meldinger i AEAD-modus

Poly1305 / ChaCha20-Poly1305: ulemper

  • Krever streng nonce-unikhet, gjenbruk kan gi katastrofalt nøkkeltap
  • Ikke støttet som signeringsalgoritme i JWT eller AWS SigV4
  • Høyere operasjonell risiko ved feilkonfigurasjon enn HMAC
  • Datagrense på 256 GB per (nøkkel, nonce)-par i IETF-varianten krever oppmerksomhet i høyvolum-systemer

Migreringsguide: fra HMAC-only til ChaCha20-Poly1305 AEAD

Noen team, spesielt de som bygger VPN-tunneler, meldingssystemer eller høyvolum dataoverføring, vurderer å gå fra en ren HMAC-basert signering til en AEAD-basert ChaCha20-Poly1305-løsning. Motivasjonen er som regel en av to ting: enten vil man kutte CPU-forbruk på enheter uten AES-maskinvare, eller man vil slå sammen kryptering og autentisering til ett steg for å redusere antall steder feil kan oppstå. Dette er en praktisk sekvens for en trygg overgang.

  1. Kartlegg dagens nøkkelbruk. Identifiser hvor HMAC-nøkler i dag gjenbrukes på tvers av tjenester, og noter volum og meldingsfrekvens per nøkkel.
  2. Velg bibliotek. Gå for et modent, revidert bibliotek som libsodium, OpenSSL 1.1+ eller den native ChaCha20-Poly1305-implementasjonen i rustls, fremfor å skrive egen Poly1305-kode.
  3. Design nonce-strategien først. Bestem om nonce skal være en teller (krever synkronisert tilstand) eller tilfeldig generert (krever XChaCha20-Poly1305 for å redusere kollisjonsrisiko ved 192-bit nonce).
  4. Kjør parallelt i en testfase. La nye meldinger autentiseres med både HMAC og ChaCha20-Poly1305 samtidig, slik at man kan sammenligne resultater uten å bryte eksisterende integrasjoner.
  5. Rotér nøkler ved overgang. Ikke gjenbruk en gammel HMAC-nøkkel som ChaCha20-nøkkel. Generer nye 256-bit nøkler spesifikt for AEAD-bruk.
  6. Test nonce-unikhet under last. Kjør belastningstester som simulerer produksjonsvolum for å bekrefte at nonce-genereringen faktisk aldri kolliderer innenfor 256 GB-grensen per (nøkkel, nonce)-par.
  7. Overvåk og logg feilrater. Sett opp alarmer på autentiseringsfeil under utrulling, en brå økning kan indikere nonce-synkroniseringsproblemer mellom klient og server.
  8. Ha en rollback-plan. Behold HMAC-verifisering aktiv i en overgangsperiode slik at man kan rulle tilbake uten datatap dersom AEAD-utrullingen avdekker uforutsette feil.

Det motsatte scenariet, å gå fra ChaCha20-Poly1305 til ren HMAC-signering, er mindre vanlig, men kan være aktuelt for team som forenkler en arkitektur ned til bare signering uten behov for kryptering, for eksempel ved overgang til et API-gateway-lag som håndterer TLS separat. Her er trinnene enklere: velg HMAC-SHA256, avled signeringsnøkler med samme kjede-mønster som AWS SigV4 bruker, og fjern nonce-avhengigheten fullstendig fra applikasjonslaget. Uansett retning bør et team sette av tid til faktisk penetrasjonstesting av den nye implementasjonen før den settes i full produksjon, siden feil i nonce-håndtering eller nøkkelavledning ofte er usynlige i vanlig funksjonell testing og først dukker opp under målrettet sikkerhetstesting eller, verre, etter et faktisk brudd.

Bruksanbefalinger: når bør du velge HMAC eller Poly1305?

Ingen av konstruksjonene er universelt best. Valget avhenger av hva slags system som skal beskyttes og hvilke driftsbegrensninger teamet har. Bruk listen under som en sjekkliste før neste arkitekturbeslutning, ikke som en absolutt regel, siden enkeltsystemer alltid kan ha unntak som taler for det motsatte valget.

  • Bruk HMAC hvis du bygger JWT-baserte API-er som må følge RFC 7519 sitt HS256-krav, eller integrerer mot AWS-tjenester som krever AWS4-HMAC-SHA256.
  • Bruk HMAC hvis du signerer webhooks eller fintech-forespørsler der samme delte nøkkel skal gjenbrukes over uker eller måneder uten nonce-styring.
  • Bruk Poly1305/ChaCha20-Poly1305 hvis du bygger eller drifter en VPN-løsning i WireGuard-stil, der datakanalens ytelse er kritisk.
  • Bruk Poly1305/ChaCha20-Poly1305 hvis målplattformen er mobil eller innebygd maskinvare uten AES-NI, der ren programvarehastighet betyr mer enn maskinvareakselerert AES-GCM.
  • Bruk Poly1305/ChaCha20-Poly1305 hvis du bygger meldingskryptering i Signal-stil der hver melding naturlig får en unik nøkkel fra en ratchet-mekanisme.
  • Bruk HMAC hvis du driver høyvolum-loggpipelines der milliarder av korte meldinger skal signeres med samme statiske nøkkel over lang tid, og nonce-styring ville lagt til unødvendig kompleksitet.
  • Bruk ChaCha20-Poly1305 hvis du trenger konfidensialitet og autentisering i samme operasjon, og vil unngå å implementere kryptering og MAC som to separate trinn.
  • Bruk begge, som WireGuard, hvis systemet ditt har et tydelig skille mellom nøkkelavledning/håndtrykk (HMAC/HKDF) og løpende datakryptering (ChaCha20-Poly1305).

Verdikt: hva bør nordiske utviklerteam velge i 2026?

Det finnes ikke én vinner her, og det bør det heller ikke gjøre. HMAC-SHA256 og ChaCha20-Poly1305 er designet for forskjellige jobber, og de beste systemene, som WireGuard, bruker faktisk begge samtidig. For et norsk fintech- eller DevSecOps-team er den praktiske regelen enkel å følge.

Signerer dere API-kall, webhooks eller JWT-tokens der en delt hemmelighet skal gjenbrukes over tid, er HMAC-SHA256 fortsatt riktig verktøy, det er det RFC 7519 og AWS SigV4 forutsetter, og det er mønsteret Vipps- og BankID-lignende integrasjoner allerede følger. Bygger dere derimot noe som beveger data, en VPN-tunell, en mobilapp-backend uten AES-maskinvare, en meldingstjeneste eller en høyvolum krypteringspipeline, gir ChaCha20-Poly1305 typisk bedre gjennomstrømning og en enklere sikkerhetsmodell fordi kryptering og autentisering skjer i samme steg. TLS 1.3 sin TLS_CHACHA20_POLY1305_SHA256 og IETF CFRG sitt 2025-utkast peker begge i samme retning: ChaCha20-Poly1305 er ikke lenger et nisjevalg, men en likestilt standardanbefaling ved siden av AES-GCM og HMAC-basert HKDF for protokoller bygget i 2026.

Den mest presise anbefalingen er derfor en to-delt regel, ikke en enkelt vinner. For signeringsproblemer, der en delt hemmelighet stadfester at en forespørsel er ekte, vinner HMAC-SHA256 på standardstøtte, revisjonsmodenhet og operasjonell enkelhet. For krypteringsproblemer, der data faktisk skal beskyttes i transitt eller lagring og ikke bare signeres, vinner ChaCha20-Poly1305 på ytelse og en enklere trusselmodell fordi kryptering og autentisering håndteres i ett steg. De færreste systemer trenger å velge én konstruksjon for alt. Som WireGuard demonstrerer i praksis, er det fullt mulig, og ofte riktig, å bruke HMAC der nøkkelavledning og gjenbruk gir mening, og ChaCha20-Poly1305 der rå hastighet og innebygd konfidensialitet betyr mest.

Relatert dekning

For mer dybde om beslektede kryptografiske valg, se disse artiklene fra shattered.io:

Ofte stilte spørsmål

Er Poly1305 sikrere enn HMAC-SHA256?

Ikke i seg selv. De to har forskjellige sikkerhetsmodeller. HMAC-SHA256 er trygt over ubegrenset nøkkelgjenbruk og bundet av SHA-256 sin bursdagsgrense, mens Poly1305 er sikkert bare når nøkkelen er fersk per melding. Begge regnes som svært solide når de brukes riktig, ifølge deres respektive spesifikasjoner (RFC 2104 og RFC 8439). Sikkerheten avhenger mer av korrekt implementasjon enn av hvilken av de to man velger.

Kan jeg bruke Poly1305 til å signere JWT-tokens?

Nei, ikke innenfor JWT-standarden. RFC 7519 spesifiserer HS256, HS384 og HS512, alle HMAC-baserte, samt asymmetriske alternativer som RS256 og ES256. Poly1305 er ikke en del av den offisielle JWT-algoritmelisten, og ingen av de store JWT-bibliotekene i Node.js, Java, Python eller .NET tilbyr det som signeringsalgoritme.

Hvorfor bruker WireGuard både HMAC og Poly1305?

Fordi de to konstruksjonene passer forskjellige deler av protokollen. Håndtrykket, der nøkler avledes og forhandles, bruker HKDF bygget på HMAC (typisk HMAC-BLAKE2s), fordi denne fasen krever kjeding og gjenbruk av mellomliggende nøkkelmateriale. Selve datakanalen, som krypterer VPN-trafikk pakke for pakke, bruker ChaCha20-Poly1305 for hastighet og fordi hver pakke naturlig får en unik nonce.

Hvor mye raskere er Poly1305 enn HMAC-SHA256 i praksis?

Typiske målinger viser omtrent 1-2 GB/s for Poly1305 alene mot omtrent 400-800 MB/s for HMAC-SHA256 uten SHA-maskinvareutvidelser, altså en forskjell i størrelsesordenen 2-3x. Med SHA-NI eller ARMv8 sine SHA2-utvidelser krymper forskjellen betydelig, og HMAC-SHA256 kan nå omtrent 1-2 GB/s, samme størrelsesorden som Poly1305. Tallene er representative, ikke eksakte, og varierer med CPU-generasjon og implementasjon.

Hva skjer hvis en nonce gjenbrukes i ChaCha20-Poly1305?

Det er alvorlig. Gjenbrukes samme (nøkkel, nonce)-par til å kryptere to forskjellige meldinger, lekker informasjon om begge klartekstene gjennom XOR av keystreamene, og Poly1305-autentiseringstaggen kan i verste fall gjøre det mulig å forfalske fremtidige meldinger. Dette er hovedgrunnen til at biblioteker som libsodium anbefaler XChaCha20-Poly1305 med sin 192-bit nonce i systemer der nonce-verdier genereres tilfeldig fremfor med en synkronisert teller.

Passer HMAC eller ChaCha20-Poly1305 best for AWS SigV4-signering?

HMAC er det eneste alternativet. AWS SigV4 krever eksplisitt algoritmestrengen “AWS4-HMAC-SHA256” og bygger signeringsnøkkelen gjennom en kjede av HMAC-operasjoner over dato, region og tjeneste. Poly1305 tilbys ikke, og siden hele SigV4-designet forutsetter en gjenbrukbar, kjedet HMAC-nøkkelavledning, er det heller ikke teknisk kompatibelt med Poly1305 sitt engangsnøkkelkrav.

Bør et nordisk fintech-team bytte fra HMAC til ChaCha20-Poly1305 for API-signering?

For selve API-signeringen, sannsynligvis ikke. Standarder som JWS, JWT og AWS SigV4, som norske og nordiske fintech-integrasjoner i stor grad bygger på, forutsetter HMAC. Der ChaCha20-Poly1305 derimot gir reell verdi for det samme teamet, er i valg av TLS 1.3-cipher-suite for transportlaget, spesielt mot mobilklienter, og i eventuell VPN-infrastruktur som WireGuard for intern trafikk.

Hvordan forholder Poly1305 seg til GMAC, MAC-en i AES-GCM?

Begge tilhører samme familie av universal hashing-baserte MAC-er og produserer en 128-bit tag, men de bygger på forskjellig aritmetikk. GMAC opererer i det binære feltet GF(2^128) og er tett koblet til AES-blokkchiffer-strukturen, mens Poly1305 opererer i primtallsfeltet modulo 2^130-5 og er uavhengig av hvilken strømchiffer som genererer engangsnøkkelen. I praksis konkurrerer AES-GCM og ChaCha20-Poly1305 om den samme rollen som AEAD-standardvalg i TLS 1.3, der AES-GCM vanligvis vinner på maskiner med AES-NI og ChaCha20-Poly1305 vinner uten den maskinvarestøtten.

Må jeg implementere Poly1305 selv, eller finnes det ferdige biblioteker?

Skriv aldri egen kryptografisk kode i produksjon uten sterk grunn. Poly1305 og ChaCha20-Poly1305 er tilgjengelig i modne, reviderte biblioteker som libsodium, OpenSSL fra versjon 1.1 og oppover, BoringSSL, LibreSSL og rustls, i tillegg til innebygde implementasjoner i de fleste moderne programmeringsspråks standardbiblioteker. Det samme gjelder HMAC, som finnes i praktisk talt hvert eneste kryptografibibliotek som eksisterer. Den vanskelige delen er sjelden selve MAC-beregningen, det er nonce-styringen, nøkkellagringen og integrasjonen mot resten av systemet som krever nøye arbeid.