AES-256 vs ChaCha20: Opptil 127% Raskere [2026]

Når en utvikler i Oslo eller Trondheim skal velge krypteringsalgoritme for en ny tjeneste, ender valget som regel opp mellom to kandidater: AES-256, standarden som har dominert siden tidlig 2000-tall, og ChaCha20-Poly1305, den yngre streamchifferen som driver WireGuard, Signal og store deler av mobiltrafikken på nett. Begge er trygge. Begge er godkjent i moderne protokoller. Men de er bygget for ulike maskiner, og forskjellen i ytelse kan bli overraskende stor avhengig av hva du kjører dem på.

Denne artikkelen går gjennom de nyeste benchmarkene fra 2025 og 2026, ser på hvem som faktisk bruker hva i produksjon, og gir deg et konkret svar på hvilken algoritme som passer best til din arbeidsbelastning – enten du bygger en VPN-tjeneste, sikrer en database, eller bare prøver å forstå hvorfor WireGuard aldri nevner AES.

Kort historie: fra DES via AES til ChaCha20

For å forstå hvorfor vi i det hele tatt har to konkurrerende standarder, hjelper det å se på hvor de kom fra. AES ble født ut av en åpen konkurranse NIST arrangerte fra 1997 til 2000, etter at den forrige standarden DES (Data Encryption Standard) med sin 56-bits nøkkel var blitt for svak til å stå imot brute force-angrep med datidens maskinvare. Rijndael-algoritmen, utviklet av de belgiske kryptografene Joan Daemen og Vincent Rijmen, vant konkurransen og ble til AES i FIPS 197 i 2001. Siden den gang har AES vært selve ryggraden i internettsikkerhet – fra HTTPS til Wi-Fi-kryptering til diskkryptering.

ChaCha20 har en helt annen opprinnelse. Daniel J. Bernstein utviklet den som en forbedring av sin egen Salsa20-chiffer, med mål om høyere diffusjon per runde og bedre ytelse i ren programvare. Google begynte å bruke ChaCha20-Poly1305 i Chrome og Android rundt 2014, nettopp fordi store deler av mobilflåten på den tiden manglet AES-maskinvare, noe som gjorde AES uforholdsmessig treg og batterikrevende på telefoner. IETF standardiserte konstruksjonen i RFC 7539 i 2015, senere oppdatert til RFC 8439. Da WireGuard-utvikleren Jason A. Donenfeld designet sin VPN-protokoll fra bunnen av rundt 2015–2016, valgte han ChaCha20-Poly1305 som eneste AEAD-alternativ, nettopp for å unngå kompleksiteten og feilrommet som følger med å støtte flere krypteringsalternativer i en sikkerhetskritisk protokoll.

Denne historiske bakgrunnen forklarer også hvorfor de to algoritmene er optimert for så ulike forhold: AES ble designet i en tid da spesialisert maskinvarestøtte var en rimelig antagelse for servere og etter hvert også allmenne prosessorer, mens ChaCha20 ble designet nettopp for verdenen der slik maskinvare ikke kunne tas for gitt.

Hva er AES-256 og ChaCha20-Poly1305?

AES-256 (Advanced Encryption Standard med 256-bits nøkkel) er en blokkchiffer standardisert av NIST i FIPS 197 i 2001. Den krypterer data i faste blokker på 128 bit, og brukes i praksis nesten alltid i GCM-modus (Galois/Counter Mode), som kombinerer kryptering og autentisering i én operasjon. AES-256-GCM er derfor den reelle sammenligningen – ikke ren AES.

ChaCha20-Poly1305 er en nyere konstruksjon: en streamchiffer (ChaCha20) designet av Daniel J. Bernstein, kombinert med Poly1305-autentisering i en AEAD-konstruksjon (Authenticated Encryption with Associated Data) spesifisert i RFC 8439. Den ble laget nettopp for å løse et problem AES har: uten dedikert maskinvarestøtte er AES treg og vanskelig å implementere i konstant tid, noe som åpner for timing-angrep.

Begge bruker 256-bits nøkler. Begge er AEAD-chiffer, altså de krypterer og autentiserer samtidig, som er standarden i moderne protokoller som TLS 1.3, SSH og VPN-tunneler. Forskjellen ligger ikke i sikkerhetsnivået, men i hvordan de er bygget internt – og det er akkurat den forskjellen som avgjør hvem som vinner på hvilken maskinvare.

AES-256 vs ChaCha20: Spesifikasjoner side ved side

Tabellen under oppsummerer de tekniske egenskapene til begge algoritmene, hentet fra offisielle spesifikasjoner og NIST-dokumentasjon.

Egenskap	AES-256-GCM	ChaCha20-Poly1305
Type	Blokkchiffer (128-bits blokker)	Streamchiffer
Nøkkelstørrelse	256 bit	256 bit
Autentiseringstag	128 bit (GCM)	128 bit (Poly1305)
Standardisert av	NIST, FIPS 197 / SP 800-38D	IETF, RFC 8439
FIPS-godkjent	Ja	Nei (per 2026)
Krever maskinvarestøtte for topp ytelse	Ja (AES-NI / ARMv8 Crypto Extensions)	Nei, rask i ren programvare
Kvantesikkerhet (Grover)	~128-bits sikkerhet mot kvantesøk	~128-bits sikkerhet mot kvantesøk
Kjente strukturelle svakheter (2026)	Ingen ved korrekt bruk	Ingen kjente
Sidekanal-risiko uten maskinvarestøtte	Høyere (tabellbasert implementasjon)	Lav (enklere å gjøre konstant tid)
Primær bruk i 2026	TLS, diskkryptering, virksomhetslagring	VPN (WireGuard), mobil, meldingsapper
Nonce-størrelse	96 bit (standard)	96 bit (IETF-variant)
Parallelliserbar	Ja	Ja

Ytelse: Hva sier benchmarkene fra 2025 og 2026?

Her skiller de to algoritmene seg mest fra hverandre, og svaret avhenger nesten utelukkende av om prosessoren har dedikert AES-maskinvare. Vi har samlet tall fra tre uavhengige kilder for å unngå å stole på ett enkelt datapunkt.

Med maskinvareakselerasjon (AES-NI / ARMv8 Crypto)

På en Intel Ice Lake-prosessor med AES-NI målte kryptografen Ash Vardanian at AES-256-GCM leverer mellom 577 og 2 617 MB/s i kryptering, mot 396 til 1 158 MB/s for ChaCha20-Poly1305, avhengig av datastørrelse (Ash Vardanian, 2025). Det gir AES-256 et forsprang på mellom 62 og 127 prosent på denne typen maskinvare. Samme benchmark viser at forspranget vokser ytterligere på AWS Graviton 2 (ARM-server), hvor AES var 91 til 118 prosent raskere enn ChaCha20 takket være ARMv8s innebygde krypteringsinstruksjoner.

Et generelt sammendrag fra Voltaire-dokumentasjonen for symmetrisk kryptering plasserer AES-256-GCM i sjiktet 3–5 GB/s med maskinvarestøtte, mot 1–2 GB/s for ChaCha20-Poly1305 på samme plattform – en forskjell på 2 til 3 ganger. Det samme mønsteret dukker opp på Apple M3, hvor AES-256-GCM med maskinvareakselerasjon når rundt 6,4 GB/s for 1 MB-blokker, mens XChaCha20-Poly1305 lander på rundt 4,2 GB/s.

Uten maskinvareakselerasjon (ren programvare)

Bildet snur helt når AES må kjøre uten dedikert maskinvare. Et studentforsøk fra Institut Teknologi Bandung i 2025 målte ChaCha20-Poly1305 til en topp-ytelse på 648,7 MB/s mot 416,6 MB/s for AES-256-GCM i ren programvare – altså rundt 55 prosent raskere for ChaCha20. Samme rapport fant at ChaCha20-Poly1305 også brukte litt mindre minne (cirka 3 MB mot 4 MB) i testene.

På Apple M3 uten maskinvareakselerasjon faller AES-256-GCM til rundt 1,8 GB/s – mer enn tre ganger tregere enn med maskinvarestøtte, og klart bak ChaCha20s programvarehastighet på 4,2 GB/s. Konklusjonen fra flere uavhengige tester er entydig: AES vinner stort med riktig maskinvare, men taper tydelig uten den.

Scenario	AES-256-GCM	ChaCha20-Poly1305	Vinner
Intel Ice Lake, med AES-NI (1 MB blokker)	opptil 2 617 MB/s	opptil 1 158 MB/s	AES-256 (+62–127%)
AWS Graviton 2 (ARM, med krypto-utvidelser)	opptil 1 104 MB/s	opptil 503 MB/s	AES-256 (+91–118%)
Apple M3, med maskinvareakselerasjon	~6,4 GB/s	~4,2 GB/s	AES-256 (~+52%)
Apple M3, ren programvare (uten akselerasjon)	~1,8 GB/s	~4,2 GB/s	ChaCha20 (~+133%)
Generisk programvarebenchmark (ITB, 2025)	416,6 MB/s	648,7 MB/s	ChaCha20 (+55%)
Filoverføring, TLS, under 4 MB per record	1 847 MB/s (64 KB)	2 134 MB/s (64 KB)	ChaCha20 (+15,5%)
Filoverføring, TLS, over 16 MB per record	6 103 MB/s (64 MB)	5 187 MB/s (64 MB)	AES-256 (+17,7%)

Én detalj er verdt å trekke frem: en 2026-analyse fra TopPriv fant et krysningspunkt rundt 4 MB filstørrelse på maskinvare med AES-NI. Under den grensen er ChaCha20-Poly1305 raskere på grunn av lavere oppstartskostnad, mens AES-256-GCM tar igjen og passerer ved større datamengder. For mikrokontrollere uten kryptoutvidelser (ESP32-klassen) viser tester fra Politeknik Jember i 2026 at ChaCha20-Poly1305 også er mer strømeffektiv, noe som gjør den til et naturlig valg for IoT-enheter med begrenset batterikapasitet.

AES-CBC vs AES-GCM: hvorfor modus betyr like mye som algoritmen

En vanlig misforståelse er å tro at «AES» er én ting. I praksis er AES en blokkchiffer som må kombineres med en driftsmodus, og valget av modus har historisk vært en større sikkerhetsrisiko enn selve algoritmen. Eldre systemer brukte ofte AES-CBC (Cipher Block Chaining) sammen med en separat HMAC for autentisering – en konstruksjon som er vanskelig å implementere korrekt og som har vært kilde til flere reelle sårbarheter, blant annet padding oracle-angrep mot TLS-implementasjoner på 2010-tallet.

AES-GCM løser dette ved å slå sammen kryptering og autentisering i én AEAD-konstruksjon, akkurat som ChaCha20-Poly1305 gjør. Det betyr at når vi sammenligner AES-256 mot ChaCha20 i 2026, sammenligner vi to moderne AEAD-chiffer med lignende sikkerhetsegenskaper – ikke gammeldags CBC mot en ny streamchiffer. Skal du fortsatt vedlikeholde eldre systemer som bruker AES-CBC, bør oppgradering til AES-GCM eller ChaCha20-Poly1305 være en prioritet uavhengig av hvilken av de to du til slutt lander på.

Sikkerhet: Er den ene tryggere enn den andre?

Kort svar: nei, ikke i praksis. Begge algoritmene gir effektiv 256-bits sikkerhet mot klassiske angrep, og ingen strukturelle svakheter er kjent for noen av dem per 2026 når de brukes riktig. Forskjellen ligger i implementasjonsrisiko, ikke i matematisk styrke.

AES i programvare uten maskinvarestøtte krever tabelloppslag som kan lekke informasjon gjennom cache-timing – et velkjent sidekanalproblem som har vært utnyttet i akademiske angrep siden midt på 2000-tallet. Med AES-NI forsvinner denne risikoen fordi krypteringen skjer i dedikert silisium, isolert fra CPU-cachen. ChaCha20 er designet fra bunnen av for å være enkel å implementere i konstant tid, uavhengig av maskinvare, og unngår dermed denne klassen sårbarheter helt.

Nonce-gjenbruk: den kritiske feilen som gjelder begge algoritmene

Det største praktiske sikkerhetsproblemet med både AES-GCM og ChaCha20-Poly1305 handler ikke om algoritmen selv, men om hvordan den brukes. Begge er avhengige av en unik nonce (number used once) for hver kryptering med samme nøkkel. Gjenbrukes en nonce med samme nøkkel i GCM-modus, kan det i verste fall avsløre autentiseringsnøkkelen og gjøre det mulig å forfalske meldinger. ChaCha20-Poly1305 har samme svakhet ved nonce-gjenbruk.

Med en 96-bits nonce, som er standard for begge i IETF-varianten, er risikoen for tilfeldig kollisjon lav ved normal bruk, men den øker betydelig i systemer som krypterer svært mange meldinger med samme nøkkel, eller som gjenoppretter tilstand feil etter en omstart. Praktisk råd: bruk biblioteker som håndterer nonce-generering automatisk (slik som Node.js sitt innebygde crypto-modul), roter nøkler regelmessig, og unngå egenutviklet nonce-logikk med mindre du har god grunn og god testing bak deg.

På kvantesikkerhet er de to identiske: under Grovers algoritme mister en 256-bits nøkkel halvparten av bitlengden i effektiv sikkerhet, noe som gir omtrent 128-bits beskyttelse mot en fremtidig kvantedatamaskin. Verken AES-256 eller ChaCha20 er postkvante-algoritmer i seg selv – det problemet ligger i nøkkelutvekslingen (der ML-KEM tar over for RSA), ikke i selve symmetriske krypteringen. Se vår sammenligning av ML-KEM mot RSA for hvordan det skiftet påvirker resten av kryptostacken.

Compliance er der forskjellen faktisk teller. AES-256-GCM er validert i FIPS 140-moduler og er standard i statlige og regulerte miljøer i Norge og EU. ChaCha20-Poly1305 er ikke FIPS-godkjent per 2026, noe som i praksis stenger den ute fra offentlig sektor og finansinstitusjoner som må dokumentere samsvar med NIST SP 800-38D eller tilsvarende standarder.

Prising og kostnad: Hva koster valget i praksis?

Ingen av algoritmene har en lisenskostnad – begge er åpne, patentfrie standarder som er gratis å implementere. Den reelle kostnaden ligger i regnekraft (CPU-tid), som direkte påvirker skyregningen din. Tabellen under viser omtrentlig kostnadseffekt basert på gjeldende compute-priser hos store skyleverandører, beregnet ut fra kjent CPU-tid per GB kryptert data.

Scenario	AES-256-GCM (med AES-NI)	ChaCha20-Poly1305	Kommentar
Server-CPU (x86-64, moderne)	Lavere CPU-tid per GB	2–3x høyere CPU-tid per GB	AES-NI gjør AES billigst på vanlig skyserver
ARM-instans (Graviton, Ampere)	Lavere CPU-tid per GB	~2x høyere CPU-tid per GB	ARMv8 krypto-utvidelser favoriserer AES
Eldre mobil / IoT uten kryptomaskinvare	Høyere CPU-tid, mer batteriforbruk	Lavere CPU-tid og batteriforbruk	ChaCha20 billigst der maskinvare mangler
Lisenskostnad	0 kr (åpen standard)	0 kr (åpen standard)	Ingen forskjell
FIPS-sertifiseringskostnad (kun AES)	Kan kreve validert modul (kostnad varierer per leverandør)	Ikke relevant – ikke FIPS-godkjent	Gjelder kun regulerte bransjer

For de fleste norske og nordiske virksomheter som drifter på moderne x86-64- eller ARM-servere i AWS, Azure eller GCP, betyr dette at AES-256-GCM gir lavere driftskostnad per krypterte gigabyte, rett og slett fordi maskinvarestøtten allerede er der og reduserer CPU-belastningen. Kostnadsbildet snur bare når arbeidslasten kjører på eldre eller svakere maskinvare uten kryptoinstruksjoner.

Hvem bruker hva i 2026?

Den beste måten å forstå forskjellen på er å se hvem som faktisk har valgt hva – og hvorfor. Her er fem konkrete eksempler fra dagens landskap.

WireGuard – bruker utelukkende ChaCha20-Poly1305 som sin AEAD-konstruksjon, spesifisert direkte i protokollen (WireGuard, offisiell protokolldokumentasjon). Designfilosofien var å velge én enkelt, moderne primitiv som fungerer likt godt på rutere, telefoner og servere – uavhengig av om maskinvaren har AES-akselerasjon.
Cloudflare og store CDN-er – kjører AES-GCM som standard for TLS-trafikk, med ChaCha20-Poly1305 som sekundært alternativ for klienter uten AES-maskinvare. Begrunnelsen er ren ytelse: med AES-NI på nesten alle moderne serverchip gir AES-GCM 2 til 3 ganger høyere gjennomstrømning for massekryptering.
Android og eldre mobilklienter – foretrekker ofte ChaCha20-Poly1305 når enheten mangler AES-maskinvare, noe som historisk har vært vanlig på billigere og eldre ARM-brikker uten kryptoutvidelser.
Signal-protokollen og meldingsapper bygget på libsignal – bruker moderne AEAD-konstruksjoner tilpasset mobil, der ChaCha20s programvarehastighet og enkle konstant-tid-implementasjon er en fordel på tvers av ulike telefonmodeller.
Virksomhetslagring, databaser og FIPS-sertifiserte moduler – går så godt som alltid for AES-256-GCM (eller AES-256-XTS for diskkryptering), drevet av krav til NIST/FIPS-samsvar og av at server- og lagringsmaskinvare nesten alltid har AES-NI innebygd.
Apple-økosystemet – bruker AES-256-GCM med maskinvareakselerasjon som standard i mange av sine krypteringslag, siden Apple Silicon (M-serien) har dedikert AES-akselerasjon som gir betydelig høyere gjennomstrømning enn programvarebaserte alternativer, ifølge benchmarks på M3-brikken referert over.
Utviklerbiblioteker for kryssplattform-kryptografi – moderne kryptografibiblioteker tilbyr som regel begge algoritmene og lar utvikleren eller til og med biblioteket selv velge basert på hvilken maskinvare koden faktisk kjører på, nettopp fordi ingen av dem er universelt best.

Adopsjon: Hvor stor andel av TLS-trafikken bruker hva?

Tall fra TLS-telemetri og CDN-analyser i 2025 og 2026 viser at AES-GCM-suiter (AES-128 og AES-256 kombinert) står for mellom 70 og 90 prosent av observert TLS-trafikk hos store CDN-er og sikkerhetsskanninger. ChaCha20-Poly1305 utgjør typisk 10 til 30 prosent, med en klart høyere andel blant mobiltung trafikk, spesielt Android-enheter i regioner med eldre maskinvare.

Til sammenligning: en fersk analyse av 8,7 milliarder SSL-sertifikater fant at RSA SHA-256-signaturer alene utgjorde 54,9 prosent av alle sertifikater i andre kvartal 2026 (Technology Checker, sertifikattransparens-rapport 2026). Det sier riktignok noe om signaturalgoritmer og ikke symmetrisk kryptering direkte, men det illustrerer hvor treg utskiftingen av etablerte standarder som AES faktisk går, selv når nyere alternativer finnes.

I VPN-økosystemet er bildet mer polarisert: WireGuard er praktisk talt 100 prosent ChaCha20-Poly1305 i sin standardmodus, mens tradisjonelle IPsec- og OpenVPN-oppsett i økende grad går for AES-GCM når maskinvarestøtte er tilgjengelig, med ChaCha20 som fallback for mobile og eldre klienter.

AES-256 og ChaCha20 i norsk og nordisk sammenheng

For norske virksomheter er valget mellom AES-256 og ChaCha20 sjelden bare et teknisk spørsmål – det henger sammen med regelverk. Nasjonal sikkerhetsmyndighet (NSM) sine grunnprinsipper for IKT-sikkerhet legger vekt på bruk av anerkjente, standardiserte krypteringsalgoritmer i systemer som behandler skjermingsverdig informasjon, og AES er den algoritmen som er mest utbredt i godkjente løsninger og HSM-er som brukes av offentlig sektor og kritisk infrastruktur i Norge.

Med EUs NIS2-direktiv, som utvider kravene til kryptografisk sikring av nettverks- og informasjonssystemer for et bredere sett virksomheter i EU/EØS, blir dokumentert bruk av standardiserte og godt analyserte algoritmer enda viktigere. AES-256-GCM sin lange historie med FIPS-validering og NIST-standardisering gjør revisjons- og dokumentasjonsjobben enklere for virksomheter som må vise samsvar overfor tilsynsmyndigheter. GDPR og Datatilsynets veiledning stiller ikke krav om en spesifikk algoritme, men forventer at kryptering er «tilstrekkelig sterk» og i tråd med anerkjent praksis – noe begge algoritmene oppfyller teknisk, selv om AES har det tyngste papirsporet.

Samtidig er WireGuard i praksis standardvalget for moderne VPN-løsninger i nordiske bedrifter og hos flere skandinaviske skyleverandører, nettopp fordi den er enkel å revidere (koden er svært kompakt sammenlignet med eldre VPN-protokoller) og fordi ChaCha20-Poly1305 gir forutsigbar ytelse på tvers av de blandede enhetsflåtene mange nordiske organisasjoner drifter, fra kontor-PC-er til feltutstyr uten moderne kryptomaskinvare.

Vanlige implementeringsfeil å unngå

Uavhengig av hvilken algoritme du velger, er det implementasjonen – ikke matematikken – som oftest svikter i praksis. Her er feilene som går igjen:

Gjenbruk av nonce med samme nøkkel. Den klart vanligste og alvorligste feilen for begge algoritmene, spesielt i systemer som gjenoppretter tilstand feil etter omstart eller skalering.
Å anta at «AES» automatisk betyr sikker modus. AES-ECB og AES-CBC uten korrekt autentisering er fortsatt utbredt i eldre kodebaser og bør fases ut til fordel for AES-GCM.
Å hoppe over ytelsestesting på faktisk målmaskinvare. Generelle benchmarks som dem i denne artikkelen er et utgangspunkt, men den eneste måten å vite sikkert hvilken algoritme som er raskest for din arbeidsbelastning, er å teste på produksjonslik maskinvare.
Å bytte algoritme uten å planlegge bakoverkompatibilitet. Eldre klienter som ikke støtter den nye algoritmen, kan miste tilkoblingen helt hvis overgangen ikke støtter forhandling mellom begge et stykke inn i overgangsperioden.
Å ignorere autentiseringstaggen. Både GCM og Poly1305 er verdiløse for integritet hvis applikasjonskoden ikke faktisk verifiserer taggen før dataene brukes videre – en feil som dessverre dukker opp i egenskrevne integrasjoner.

Ordliste: sentrale begreper

Noen begreper går igjen i denne sammenligningen. Her er en kort forklaring av dem.

AEAD (Authenticated Encryption with Associated Data): En krypteringskonstruksjon som krypterer og autentiserer data i samme operasjon, slik at mottakeren kan oppdage om noe er endret underveis. Både AES-GCM og ChaCha20-Poly1305 er AEAD-chiffer.
Nonce: Et tall som kun brukes én gang per kryptering med en gitt nøkkel. Kritisk for sikkerheten i begge algoritmene – gjenbruk kan bryte ned beskyttelsen fullstendig.
GCM (Galois/Counter Mode): Driftsmodusen som gjør AES om til en AEAD-chiffer, ved å kombinere telle-modus-kryptering med Galois-feltautentisering.
Poly1305: Autentiseringsfunksjonen som brukes sammen med ChaCha20 for å danne AEAD-konstruksjonen ChaCha20-Poly1305.
AES-NI: Instruksjonssett i Intel- og AMD-prosessorer som utfører AES-operasjoner direkte i maskinvare, og som er hovedårsaken til at AES vinner ytelsestester på moderne servere.
Sidekanalangrep: Angrep som utnytter indirekte informasjon – som tidsbruk eller strømforbruk – i stedet for å bryte selve matematikken i algoritmen.
Konstant tid (constant-time): En implementasjon der kjøretiden ikke avhenger av hemmelige data, som gjør timing-baserte sidekanalangrep vanskeligere.

Bruksområder: Når bør du velge hva?

Valget mellom AES-256 og ChaCha20-Poly1305 handler i praksis om tre spørsmål: hvilken maskinvare kjører du på, hva krever compliance-regimet ditt, og hvor variert er klientflåten din? Her er fem konkrete anbefalinger.

Bygger du en VPN-tjeneste eller peer-to-peer-tunnel for et bredt spekter av enheter? Velg ChaCha20-Poly1305. Det er nettopp derfor WireGuard valgte den – jevn ytelse uansett om klienten er en rack-server eller en fem år gammel Android-telefon.
Drifter du API-er eller webtjenester på moderne skyservere (AWS, Azure, GCP)? Velg AES-256-GCM. Nesten all moderne x86-64- og ARM-serverinfrastruktur har AES-NI eller tilsvarende, og du får 2 til 3 ganger høyere gjennomstrømning nesten gratis.
Jobber du i offentlig sektor, finans eller andre regulerte bransjer i Norge/EU? Velg AES-256-GCM. FIPS-status og etablert revisjonspraksis gjør compliance-jobben enklere, og de fleste HSM-er og sikkerhetsmoduler støtter kun AES.
Bygger du for IoT-enheter eller mikrokontrollere uten kryptomaskinvare? Velg ChaCha20-Poly1305. Lavere strømforbruk og bedre ytelse i ren programvare gjør den til et naturlig valg for batteridrevne sensorer og innebygde systemer.
Krypterer du store filer eller hele diskvolumer på servere med AES-NI? Velg AES-256-GCM (eller AES-256-XTS for diskkryptering). Krysningspunktet på rundt 4 MB betyr at AES vinner klart for alt over den grensen på akselerert maskinvare.

Fordeler og ulemper

AES-256-GCM

Fordeler: Ekstremt rask med AES-NI eller ARMv8 Crypto Extensions (2–3x raskere enn ChaCha20 på slik maskinvare). FIPS 140-validert og godkjent i regulerte miljøer. Universell maskinvarestøtte i moderne serverchip. Lang analysehistorikk siden 2001 uten kjente strukturelle svakheter.

Ulemper: Betydelig tregere uten dedikert maskinvare (kan tape med over 100 prosent mot ChaCha20 i ren programvare). Tabellbasert programvareimplementasjon er mer utsatt for cache-timing-sidekanaler. Mer komplisert å implementere korrekt i konstant tid uten maskinvarestøtte.

ChaCha20-Poly1305

Fordeler: Jevn og forutsigbar ytelse uavhengig av maskinvare. Enklere å implementere i konstant tid, som reduserer sidekanalrisiko. Lavere strømforbruk på mobil og IoT. Vinner klart i ren programvare (opptil 55–133 prosent raskere enn AES uten akselerasjon).

Ulemper: Ikke FIPS-godkjent, noe som utelukker den fra mange regulerte bransjer. Taper tydelig på ytelse mot AES-256-GCM på maskinvare med AES-NI (opptil 127 prosent tregere). Mindre utbredt i eldre virksomhetsverktøy og HSM-er som bare støtter AES.

Migrasjonsguide: Slik bytter du fra AES til ChaCha20 (eller omvendt)

Skal du faktisk bytte krypteringsalgoritme i et eksisterende system, er dette stegene som reduserer risikoen for feil:

Kartlegg klientflåten. Sjekk om trafikken din primært kommer fra moderne servere/skrivebord (AES-NI nesten garantert) eller fra en variert flåte med eldre mobil og IoT-enheter (ChaCha20 sannsynligvis raskere i snitt).
Test faktisk maskinvare, ikke anta. Kjør en enkel benchmark med OpenSSL: openssl speed -evp aes-256-gcm og openssl speed -evp chacha20-poly1305 på representativ produksjonsmaskinvare før du bestemmer deg.
Sjekk compliance-krav først. Hvis du er underlagt FIPS 140, PCI-DSS eller tilsvarende, er AES-256-GCM ofte det eneste reelle alternativet uavhengig av ytelsestall.
Oppdater cipher suite-prioritering i TLS-konfigurasjonen. I nginx, Apache eller last balancer-konfigurasjonen din setter du ønsket rekkefølge i ssl_ciphers-direktivet, men la klienten forhandle – moderne TLS 1.3-biblioteker velger automatisk riktig chiffer basert på klientens kapabiliteter i de fleste tilfeller.
Behold begge som støttede alternativer i overgangsperioden. Ikke fjern den gamle algoritmen brått. La biblioteket forhandle mellom AES-256-GCM og ChaCha20-Poly1305 slik at eldre klienter fortsatt fungerer.
Verifiser med reell trafikkmåling. Overvåk CPU-bruk og forhandlet cipher suite i produksjonslogger i minst to uker etter endringen, ikke bare i syntetiske tester.
Dokumenter endringen for revisjon. Spesielt viktig i regulerte bransjer – noter dato, begrunnelse og hvilke systemer som er berørt.

Kodeeksempel: Begge algoritmene i praksis

Under følger et minimalt eksempel i Node.js som viser hvordan begge algoritmene brukes med det innebygde crypto-modulet. Legg merke til hvor like API-ene er – forskjellen ligger i ytelse, ikke i hvordan du bruker dem.

const crypto = require('crypto');

// AES-256-GCM
function encryptAES(plaintext, key) {
  const iv = crypto.randomBytes(12);
  const cipher = crypto.createCipheriv('aes-256-gcm', key, iv);
  const ciphertext = Buffer.concat([cipher.update(plaintext), cipher.final()]);
  const authTag = cipher.getAuthTag();
  return { iv, ciphertext, authTag };
}

// ChaCha20-Poly1305
function encryptChaCha(plaintext, key) {
  const iv = crypto.randomBytes(12);
  const cipher = crypto.createCipheriv('chacha20-poly1305', key, iv, { authTagLength: 16 });
  const ciphertext = Buffer.concat([cipher.update(plaintext), cipher.final()]);
  const authTag = cipher.getAuthTag();
  return { iv, ciphertext, authTag };
}

På en server med AES-NI vil encryptAES normalt være raskere for store datamengder. På en eldre ARM-enhet uten kryptoutvidelser, eller for svært mange små meldinger, vil encryptChaCha ofte vinne. Kjør begge mot din egen arbeidsbelastning før du bestemmer deg – generelle benchmarks er et utgangspunkt, ikke en fasit.

For å bekrefte hvilken CPU-instruksjon som faktisk brukes under panseret, kan du sjekke om prosessoren annonserer AES-NI-støtte. På Linux avslører cat /proc/cpuinfo | grep aes om flagget er til stede. OpenSSL har et innebygd benchmark-verktøy som gir et raskt førsteinntrykk: openssl speed -evp aes-256-gcm chacha20-poly1305 kjører begge algoritmene på forskjellige datastørrelser og skriver ut gjennomstrømning i kilobyte per sekund, direkte på din egen maskinvare. Dette gir mer pålitelige tall for din spesifikke situasjon enn å stole blindt på generelle benchmarks fra andre plattformer.

Kvantesikkerhet og fremtiden for symmetrisk kryptering

Et vanlig spørsmål er om AES-256 eller ChaCha20 blir sårbare når kvantedatamaskiner blir kraftige nok. Svaret er nyansert: Grovers algoritme halverer effektivt nøkkellengden for symmetrisk kryptering, så en 256-bits nøkkel gir omtrent 128-bits sikkerhet mot et kvanteangrep – fortsatt godt nok for de fleste praktiske formål i overskuelig fremtid.

Det virkelige presset kommer fra en annen kant: nøkkelutvekslingen. RSA og elliptisk kurve-kryptografi (ECC), som brukes til å etablere de symmetriske nøklene i utgangspunktet, er derimot fullstendig knuste av Shors algoritme på en tilstrekkelig stor kvantedatamaskin. Det er derfor NIST har standardisert ML-KEM (tidligere Kyber) som postkvante-erstatning for RSA i nøkkelutveksling, mens selve AES- og ChaCha20-krypteringen som følger etterpå, kan fortsette omtrent som i dag – eventuelt med noe lengre nøkler for ekstra margin.

Beslutningsrammeverk: fire spørsmål som avgjør valget

Hvis du fortsatt er usikker etter å ha lest benchmarkene over, kan valget som regel forenkles til fire spørsmål stilt i rekkefølge.

Først: krever regelverket ditt FIPS-godkjenning? Hvis svaret er ja – typisk offentlig sektor, forsvarsrelatert virksomhet eller amerikanske kontrakter med føderale krav – er valget tatt for deg. AES-256-GCM er eneste alternativ.

Deretter: vet du hvilken maskinvare koden faktisk kjører på? Hvis alt kjører i egen skyinfrastruktur på moderne x86-64- eller ARM-instanser du kontrollerer selv, kan du trygt anta AES-NI eller tilsvarende er til stede, og AES-256-GCM blir det raskeste og billigste valget.

Så: hvor variert er klientflåten på den andre siden av forbindelsen? Hvis du bygger noe som skal kjøre på alt fra eldre Android-telefoner til IoT-sensorer til rack-servere – altså maskinvare du ikke kontrollerer og ikke kan garantere har kryptoakselerasjon – peker jevn ytelse mot ChaCha20-Poly1305, slik WireGuard demonstrerer i praksis.

Til slutt: hvor store er datamengdene per operasjon? For arbeidsbelastninger med mye små meldinger under noen kilobyte er forskjellen mellom algoritmene ofte marginal og dominert av annen overhead. For store filer og strømmer over noen megabyte blir maskinvarestøtte den avgjørende faktoren, og AES-256-GCM vinner konsekvent når den støtten finnes.

Verdikt: Hvilken bør du velge?

Basert på benchmarkene over er svaret ikke «den ene er bedre», men «det kommer an på maskinvaren og kravene dine». Likevel kan vi trekke en klar konklusjon for de vanligste scenarioene:

Velg AES-256-GCM hvis du drifter på moderne x86-64- eller ARM-servere med AES-NI eller tilsvarende (som dekker det store flertallet av skyinfrastruktur i 2026), hvis du trenger FIPS-samsvar, eller hvis arbeidsbelastningen din primært består av store datamengder over 4 MB per operasjon. Her gir AES 50 til over 100 prosent høyere gjennomstrømning, praktisk talt gratis.

Velg ChaCha20-Poly1305 hvis klientflåten din er variert eller inkluderer eldre/svakere maskinvare uten kryptoutvidelser, hvis du bygger noe VPN-lignende der jevn ytelse på tvers av enheter betyr mer enn topp-ytelse på én plattform, eller hvis du optimerer for batteriforbruk på mobil og IoT. Her kan ChaCha20 være 55 til over 130 prosent raskere enn programvare-AES.

For de fleste norske bedrifter som drifter standard skyinfrastruktur uten spesielle IoT- eller mobilkrav, er AES-256-GCM det pragmatiske standardvalget i 2026 – ikke fordi det er mer sikkert, men fordi maskinvaren allerede favoriserer det. WireGuard-brukere og utviklere av kryssplattform-VPN-er bør derimot fortsette å stole på ChaCha20-Poly1305, akkurat slik protokollen ble designet for.

Det viktigste å ta med seg er at dette ikke er en sikkerhetsdiskusjon – det er en ytelses- og compliance-diskusjon. Begge algoritmene har tålt over et tiår med offentlig kryptoanalyse uten alvorlige strukturelle funn, og velger du feil algoritme for din arbeidsbelastning, taper du prosentpoeng i gjennomstrømning, ikke sikkerhet. Bruk benchmarkene i denne artikkelen som utgangspunkt, men test alltid på egen maskinvare før du låser valget i produksjon.

Ofte stilte spørsmål

Er ChaCha20-Poly1305 like sikkert som AES-256?

Ja. Begge gir effektiv 256-bits sikkerhet mot klassiske angrep, og ingen strukturelle svakheter er kjent for noen av dem per 2026. Forskjellen ligger i implementasjonsrisiko og maskinvareavhengighet, ikke i matematisk styrke.

Hvorfor bruker WireGuard ChaCha20 og ikke AES?

WireGuards designfilosofi var å velge én enkelt, moderne primitiv som yter godt på alle plattformer – fra rack-servere til fem år gamle telefoner uten AES-maskinvare. ChaCha20-Poly1305 gir den jevnheten på tvers av svært ulik maskinvare, spesifisert direkte i WireGuards offisielle protokoll.

Er AES-256 raskere enn ChaCha20 på alle maskiner?

Nei. AES-256-GCM er kun raskere når prosessoren har dedikert AES-maskinvare (AES-NI på x86-64, eller ARMv8 Crypto Extensions). Uten slik maskinvare vinner ChaCha20-Poly1305 ofte med 55 til over 130 prosent, ifølge flere uavhengige 2025/2026-benchmarks.

Kan jeg bruke ChaCha20-Poly1305 i en FIPS-regulert bransje?

Per 2026 er ChaCha20-Poly1305 ikke FIPS 140-godkjent, mens AES-256-GCM er validert i FIPS-moduler. Offentlig sektor, finans og andre regulerte bransjer i Norge/EU må derfor som regel velge AES-256-GCM for å oppfylle compliance-krav.

Er noen av algoritmene sårbare for kvantedatamaskiner?

Begge beholder omtrent 128-bits sikkerhet mot Grovers kvantealgoritme, siden en 256-bits nøkkel effektivt halveres. Det er nøkkelutvekslingen (RSA/ECC), ikke selve AES- eller ChaCha20-krypteringen, som er akutt sårbar for kvanteangrep via Shors algoritme. Se vår sammenligning av ML-KEM mot RSA for mer om det skiftet.

Bruker Signal og WhatsApp AES eller ChaCha20?

Signal-protokollen og apper bygget på libsignal støtter moderne AEAD-konstruksjoner tilpasset mobil, hvor ChaCha20s programvarehastighet og enklere konstant-tid-implementasjon er en fordel på tvers av mange ulike telefonmodeller med varierende maskinvare.

Hva bør jeg velge for en enkel Node.js- eller Python-webtjeneste i sky?

For de fleste standard skytjenester på moderne x86-64- eller ARM-instanser (AWS, Azure, GCP) er AES-256-GCM det pragmatiske valget, siden nesten all serverinfrastruktur i 2026 har innebygd AES-maskinvarestøtte som gir 2–3 ganger høyere gjennomstrømning.

Hvor stor andel av TLS-trafikken bruker hvilken algoritme i 2026?

AES-GCM-suiter (AES-128 og AES-256 samlet) står for rundt 70 til 90 prosent av observert TLS-trafikk hos store CDN-er, mens ChaCha20-Poly1305 typisk utgjør 10 til 30 prosent, med høyere andel blant mobiltung trafikk.

Hvem oppfant ChaCha20, og hvorfor het den ikke bare AES 2.0?

ChaCha20 ble designet av kryptografen Daniel J. Bernstein som en forbedring av hans egen Salsa20-chiffer, og er en helt annen konstruksjon enn AES – en streamchiffer i stedet for en blokkchiffer. Den ble ikke laget som en direkte etterfølger til AES, men som et alternativ optimert for høy ytelse i ren programvare, uten avhengighet av spesialisert maskinvare.

Bør jeg bytte fra AES-CBC til AES-GCM eller ChaCha20-Poly1305?

Ja, hvis du fortsatt kjører systemer med AES-CBC og separat HMAC-autentisering, bør oppgradering til en moderne AEAD-konstruksjon som AES-256-GCM eller ChaCha20-Poly1305 prioriteres. Eldre CBC-baserte oppsett har historisk vært utsatt for padding oracle-angrep i TLS-implementasjoner, en risikoklasse begge de moderne AEAD-alternativene unngår helt.

Kan jeg bruke begge algoritmene samtidig i samme system?

Ja, og det er faktisk vanlig praksis i overgangsperioder. TLS 1.3-biblioteker forhandler automatisk mellom AES-GCM- og ChaCha20-Poly1305-suiter basert på hva klient og server begge støtter, slik at eldre og nyere enheter kan koble til samme tjeneste uten at du må velge én algoritme for alle.

Hvor lang tid tar det å bytte krypteringsalgoritme i et produksjonssystem?

Det avhenger av systemets kompleksitet, men for en TLS-tjeneste som allerede bruker moderne biblioteker, er selve konfigurasjonsendringen ofte et spørsmål om timer. Den tidkrevende delen er testing, overvåking av produksjonstrafikk i en overgangsperiode og eventuell revisjonsdokumentasjon – sett av dager til uker for et forsvarlig gjennomført bytte, ikke minutter.