Nesten all trafikk som går gjennom norske og nordiske datasentre i dag er beskyttet av en variant av AES. Spørsmålet er ikke lenger om du skal kryptere, men hvilken nøkkellengde som faktisk gir mening for jobben. AES-128 og AES-256 er begge del av samme standard, godkjent av NIST i FIPS 197, men de oppfører seg forskjellig på ekte maskinvare, og forskjellen blir tydelig når du legger et VPN-oppsett, en TLS-terminering eller en database med sensitive data på vekten. Denne artikkelen går gjennom tallene: rundeantall, gjennomstrømming i MB/s, hva Grovers algoritme faktisk betyr for sikkerhetsmarginen, og hvorfor AWS, Azure og Google Cloud alle har landet på 256-bit som standard for lagret data, selv om 128-bit fortsatt driver store deler av verdens VPN-trafikk.
Hva er egentlig forskjellen mellom AES-128 og AES-256?
AES, eller Advanced Encryption Standard, er en symmetrisk blokkchiffer som ble standardisert av NIST i 2001 gjennom FIPS 197. Algoritmen finnes i tre nøkkellengder: 128, 192 og 256 bit. AES-128 bruker en 128-bit nøkkel og kjører gjennom 10 krypteringsrunder. AES-256 bruker en 256-bit nøkkel og kjører gjennom 14 runder. De ekstra fire rundene er hovedgrunnen til at AES-256 koster mer regnekraft enn lillebroren sin, uansett hvor godt optimalisert implementasjonen er.
Selve blokkstørrelsen er identisk i begge variantene: 128 bit per blokk, uavhengig av nøkkellengde. Det som endres er nøkkelplanen (key schedule) og antallet ganger dataene går gjennom SubBytes-, ShiftRows-, MixColumns- og AddRoundKey-trinnene. En lengre nøkkel gir eksponentielt flere mulige kombinasjoner å brute-force seg gjennom: 2^128 for AES-128 mot 2^256 for AES-256. Forskjellen i tallstørrelse er så enorm at den er vanskelig å forestille seg i praktiske termer, men det avgjørende poenget for en sikkerhetsansvarlig er noe annet: AES-128 er ikke “svak”. Ingen praktisk brute-force-metode mot noen AES-variant eksisterer i dag, og det er ingen offentlig kjent kryptoanalytisk vei inn i noen av de to.
Så hvorfor bry seg med 256-bit i det hele tatt? Svaret handler om marginer for fremtiden, ikke om dagens brute-force-risiko. Kvantedatamaskiner med Grovers algoritme kan i teorien halvere den effektive sikkerheten til en symmetrisk nøkkel. Det betyr at AES-128 i en post-kvante-verden kan falle til et effektivt sikkerhetsnivå på rundt 64 bit, mens AES-256 fortsatt sitter igjen med rundt 128 bit, som fortsatt regnes som solid. Det er derfor NIST og europeiske myndigheter gradvis dytter langtidsdata mot 256-bit, mens de fortsatt aksepterer 128-bit for kortlevd trafikk.
Historien bak AES: hvorfor Rijndael vant over DES og 3DES
For å forstå hvorfor akkurat AES-128 og AES-256 finnes side om side i dag, hjelper det å se på hvordan standarden ble til. Frem til slutten av 1990-tallet var DES (Data Encryption Standard) den dominerende krypteringsalgoritmen i amerikansk og internasjonal industri. DES brukte en nøkkel på bare 56 bit, og på slutten av 1990-tallet ble det demonstrert at spesialbygget maskinvare kunne knekke DES gjennom brute force på under ett døgn. Bransjen løste dette midlertidig med 3DES, som kjørte DES-algoritmen tre ganger etter hverandre med opptil tre forskjellige nøkler, men løsningen var treg og bar preg av å være en lapp på et grunnleggende problem.
NIST lyste i 1997 ut en åpen konkurranse for å finne en erstatning, og ba forskere fra hele verden om å sende inn forslag til en ny standard. Femten algoritmer kom inn i første runde, og etter flere år med offentlig kryptoanalyse, konferanser og runde etter runde med eliminering, stod den belgiske designen Rijndael, laget av Joan Daemen og Vincent Rijmen, igjen som vinner i 2000. Rijndael ble formalisert som Advanced Encryption Standard gjennom FIPS 197 i 2001, og algoritmen fikk innebygd støtte for tre nøkkellengder fra første stund: 128, 192 og 256 bit, med henholdsvis 10, 12 og 14 runder.
Det er verdt å merke seg at Rijndael i sin opprinnelige form faktisk støttet flere kombinasjoner av blokkstørrelse og nøkkellengde enn det som endte opp i den offisielle AES-standarden. NIST valgte å låse blokkstørrelsen til 128 bit uansett nøkkellengde, delvis for å forenkle implementasjon og delvis for å gjøre kryptoanalyse av algoritmen mer håndterbar for forskningsmiljøet. Denne beslutningen er grunnen til at både AES-128 og AES-256 i dag deler nøyaktig samme blokkstruktur, og at forskjellen mellom dem utelukkende ligger i nøkkelplanen og antall runder, ikke i selve datablokkene som behandles.
Vanlige implementeringsfeil som svekker AES uansett nøkkellengde
En vanlig misforståelse er at valget mellom AES-128 og AES-256 er det som avgjør hvor sikkert et system er. I praksis er det langt vanligere at svakheter kommer fra hvordan algoritmen implementeres, ikke fra selve nøkkellengden. En AES-256-implementasjon med dårlig nøkkelhåndtering er ofte mindre sikker enn en korrekt implementert AES-128-løsning. Her er de vanligste fallgruvene sikkerhetsteam i Norge og Norden støter på.
Den første og vanligste feilen er gjenbruk av initialiseringsvektorer (IV) i modus som CBC eller GCM. I GCM-modus, som er den mest brukte AEAD-modusen for AES i TLS 1.3 i dag, fører gjenbruk av samme IV med samme nøkkel til en katastrofal svekkelse som kan avsløre både klartekst og autentiseringsnøkkelen i verste fall. Dette gjelder uavhengig av om man bruker AES-128-GCM eller AES-256-GCM, siden problemet ligger i modusen og nøkkelhåndteringen, ikke i selve blokkchifferet. Den andre vanlige feilen er å bruke ECB-modus (Electronic Codebook) i det hele tatt, siden ECB krypterer identiske datablokker til identiske krypterte blokker, noe som kan lekke mønstre i dataene selv om selve nøkkelen aldri kompromitteres.
Et tredje problem som dukker opp jevnlig i sikkerhetsrevisjoner er svak nøkkelavledning. Å bruke et passord direkte som AES-nøkkel uten en skikkelig nøkkelavledningsfunksjon som PBKDF2, scrypt eller Argon2 gjør systemet sårbart uavhengig av om man velger 128 eller 256 bit, fordi det reelle sikkerhetsnivået da bestemmes av passordets entropi, ikke av AES sin nøkkellengde. Til sist ser man ofte at sidekanalangrep overses. Implementasjoner som ikke kjører i konstant tid kan lekke informasjon om nøkkelen gjennom timing, strømforbruk eller cache-oppførsel, og dette er en risiko som gjelder likt for begge nøkkellengder med mindre biblioteket eksplisitt er designet for å motstå slike angrep. Konklusjonen for de fleste sikkerhetsteam er at riktig bruk av en veldokumentert kryptografibibliotek, som OpenSSL, libsodium eller plattformens innebygde kryptografi-API, betyr mer for den reelle sikkerheten enn selve valget mellom AES-128 og AES-256.
Teknisk spesifikasjonstabell: AES-128 mot AES-256
Under følger en oversikt over de tekniske egenskapene som faktisk driver beslutningen i et virkelig produksjonsmiljø. Tallene er hentet fra FIPS 197-standarden og offentlig tilgjengelige benchmarks fra OpenSSL, BearSSL og uavhengige ytelsestester i 2025 og 2026.
| Egenskap | AES-128 | AES-256 |
|---|---|---|
| Nøkkellengde | 128 bit | 256 bit |
| Antall runder | 10 | 14 |
| Blokkstørrelse | 128 bit | 128 bit |
| Nøkkelrom (mulige nøkler) | 2^128 | 2^256 |
| Effektiv sikkerhet mot Grovers algoritme (kvante) | ~64 bit | ~128 bit |
| Standard for skylagring (AWS, Azure, GCP) | Sjelden standard | Standard for data i ro |
| Ytelse (OpenSSL CBC, store blokker) | ~777 MB/s | ~558 MB/s |
| Ytelse med AES-NI-akselerasjon | Marginalt raskere | Under 10% tregere enn AES-128 |
| Typisk bruk | VPN, IoT, høy gjennomstrømming | Diskkryptering, langtidsarkiv, myndighetsdata |
| Godkjent av NIST FIPS 197 | Ja | Ja |
| Egnet for NIS2/GDPR “state of the art”-krav | Akseptabel | Anbefalt for kritiske data |
Ytelsesbenchmark: hvor mye tregere er AES-256 i praksis?
Tallene varierer med maskinvare, modus og bibliotek, men mønsteret er konsekvent på tvers av uavhengige tester. På en vanlig serverprosessor uten dedikert akselerasjon viser OpenSSL sine egne CBC-benchmarks at AES-128-CBC leverer rundt 777 MB/s, mens AES-256-CBC leverer rundt 558 MB/s på samme maskin. Det tilsvarer omtrent 28 % lavere gjennomstrømming for AES-256 i denne konfigurasjonen.
Et annet datapunkt kommer fra en sammenligning av rustls og OpenSSL 3.3.2 på ARM64-maskinvare i TLS-sammenheng. Der målte man AES-128-GCM til rundt 2 101 MB/s i TLS 1.2, mot 1 741 MB/s for AES-256-GCM i TLS 1.3. Justert for protokollforskjellen havner gapet i området 15-20 %, noe som stemmer godt overens med tester fra andre miljøer. En 2025-studie som sammenlignet en “streng” TLS-profil (AES-256-GCM) mot en “balansert” profil (AES-128-GCM) fant at store filoverføringer gikk med 32,4 MB/s på AES-128-GCM mot 28,8 MB/s på AES-256-GCM, en forskjell på 12,5 % i favør av den kortere nøkkelen. Håndtrykksytelsen var derimot tilnærmet identisk, siden nøkkelutveksling og selve blokkrypteringen er to separate operasjoner i TLS 1.3 (RFC 8446).
VPN-scenarioer viser det samme mønsteret, bare tydeligere. Benchmarks fra 2025-2026 rapporterer at AES-128-GCM klarer rundt 410 Mbps ved 30 % CPU-bruk, mens AES-256-GCM lander på rundt 380 Mbps ved 45 % CPU-bruk. Det er 8 % lavere gjennomstrømming, men nesten 50 % høyere CPU-last for den lengre nøkkelen, en kostnad som merkes raskt på rutere og eldre maskinvare med begrenset regnekraft. En separat sammenligning av server- og mobilytelse fant at AES-128-GCM ga 5,1 GB/s på server og 2,8 GB/s på mobil, mot 4,2 GB/s og 2,3 GB/s for AES-256-GCM, altså rundt 18 % lavere i begge miljøer.
Det viktigste nyanserte poenget kommer fra tester med maskinvareakselerasjon. BearSSLs offentlige hastighetstabeller viser at AES-128-CBC med AES-NI på x86-64 leverer rundt 680 MB/s, mens en generisk AES-256-implementasjon uten samme optimalisering lander på rundt 125 MB/s, et stort gap som i praksis skyldes implementasjonsforskjeller mer enn selve algoritmen. Når begge varianter kjører på moderne CPU-er med AES-NI eller ARMv8 kryptoutvidelser, krymper forskjellen til under 10 % på de fleste skyinstanser hos AWS, Azure og Google Cloud. Konklusjonen fra en samlet gjennomgang av flere benchmarks er at kostnaden for AES-256 relativt til AES-128 ligger et sted mellom 8 % og 40 %, avhengig av modus, maskinvare og om AES-NI er tilgjengelig, og at gapet er størst på ressursbegrensede enheter og minst på moderne servere.
Sikkerhetsmargin: nøkkelrom, brute force og kvantetrusselen
Her ligger den egentlige begrunnelsen for å velge AES-256 fremfor AES-128, og den handler ikke om dagens datamaskiner. AES-128 gir 2^128 mulige nøkler. Det tallet er så stort at selv om alle datamaskiner på jorden jobbet sammen fra Big Bang og frem til i dag, ville de fortsatt ikke ha prøvd en meningsfull andel av kombinasjonene. Med klassisk databehandling er AES-128 i praksis ubrytelig gjennom brute force, og det kommer til å forbli slik i overskuelig fremtid.
Kvantedatamaskiner endrer regnestykket, men ikke dramatisk. Grovers algoritme gir en kvadratisk hastighetsøkning mot symmetriske nøkler, noe som i praksis halverer eksponenten i sikkerhetsnivået. Det betyr at en fullverdig, feilkorrigert kvantedatamaskin i teorien kunne redusere AES-128 til et effektivt sikkerhetsnivå på rundt 64 bit, og AES-256 til rundt 128 bit. 64-bit sikkerhet er ikke lenger nok til å beskytte data som må holde seg konfidensielt i flere tiår, mens 128-bit fortsatt anses som solid selv i et post-kvante-scenario. Dette er hovedgrunnen til at NIST og europeiske standardiseringsorganer som ENISA anbefaler 256-bit nøkler for data med lang levetid, som medisinske journaler, myndighetsarkiver eller kryptografiske nøkler som beskytter andre nøkler.
Det er verdt å presisere at ingen slik kvantedatamaskin eksisterer i dag, og de fleste eksperter regner med at en maskin kraftig nok til å true AES ligger flere tiår unna, om den i det hele tatt blir realisert i den formen. Grovers algoritme er dessuten fundamentalt annerledes enn Shors algoritme, som truer RSA og elliptisk kurve-kryptografi direkte. AES og andre symmetriske chiffer er langt mer robuste mot kvanteangrep enn asymmetriske systemer, og det er derfor NISTs post-kvante-standarder fokuserer på å erstatte RSA og ECDSA, ikke AES. Målinger av entropi i genererte AES-nøkler viser for øvrig at både 128-bit og 256-bit nøkler er nesten maksimalt tilfeldige, med rundt 7,98 til 7,99 bit entropi per byte. Sikkerhetsfordelen til AES-256 kommer altså fra et større nøkkelrom, ikke fra bedre tilfeldighet i selve nøkkelgenereringen.
Slik bruker skyleverandørene AES-256 og AES-128 i 2026
De tre store skyplattformene har alle landet på samme grunnleggende mønster: 256-bit som standard for lagret data, med 128-bit tilgjengelig der gjennomstrømming teller mer enn maksimal sikkerhetsmargin. AWS, Azure og Google Cloud krypterer alle data i ro med AES-256 som standard, i tråd med FIPS 197 og NISTs anbefalinger for langtidslagring. Azure Storage Service Encryption bruker 256-bit AES på alt som lagres, inkludert blob-lagring, diskvolumer og databaser, med nøkkelhierarkier styrt gjennom Azure Key Vault. Google krypterer alt lagret data som standard, men bruker et flerlags nøkkelhierarki der enkelte lag kan benytte både AES-256 og AES-128 avhengig av tjeneste.
For trafikk i bevegelse er bildet mer nyansert. TLS 1.3-oppsett foretrekker ofte AES-256-GCM på servere med maskinvareakselerasjon, siden ytelseskostnaden der er minimal, mens AES-128-GCM fortsatt er utbredt der gjennomstrømming er kritisk eller hvor AES-NI-støtten er svakere, for eksempel på eldre IoT-enheter og rimelige rutere. En 2025-studie som sammenlignet de to i TLS-sammenheng konkluderte med at AES-128-GCM gir den beste balansen mellom sikkerhet og effektivitet for datatunge miljøer, mens en gjennomgang av skyleverandørenes cipher-anbefalinger i RFC 5288 peker på AES-256-GCM som standardvalg for TLS-terminering, backend-tjenester og masselagring når maskinvarestøtte er på plass.
VPN-verdenen følger samme logikk, bare med enda tydeligere skille. AES-128-GCM velges ofte for høy båndbredde, mens AES-256-GCM reserveres til det som gjerne kalles “høy-sikkerhets”-profiler, der CPU-budsjettet tillater den ekstra kostnaden. For norske og nordiske virksomheter som drifter egne VPN-tunneler mellom kontorer eller datasentre, betyr dette i praksis at valget ofte kommer ned til hvilken maskinvare som står i andre enden av tunnelen, ikke bare hvilket sikkerhetsnivå man ønsker på papiret.
Prisimplikasjoner: hva koster nøkkellengden i skyen?
Selve krypteringsalgoritmen koster ingenting ekstra hos noen av de store skyleverandørene, AES-128 og AES-256 er begge inkludert i standard lagrings- og nettverkspriser. Kostnadsforskjellen ligger et annet sted: i CPU-forbruket som går med til kryptering og dekryptering, og i nøkkelhåndteringstjenestene som styrer selve nøklene.
| Tjeneste | AES-128-kostnad | AES-256-kostnad | Merknad |
|---|---|---|---|
| AWS KMS (nøkkeloperasjoner) | Samme pris per API-kall | Samme pris per API-kall | Prises per forespørsel, ikke per nøkkellengde |
| Azure Key Vault | Samme pris per operasjon | Samme pris per operasjon | Nøkkellengde påvirker ikke fakturert beløp |
| Google Cloud KMS | Samme pris per operasjon | Samme pris per operasjon | Standardkryptering inkludert i lagringsprisen |
| EC2/VM-beregning (CPU-overhead) | Lavere | 8-40 % høyere CPU-bruk | Merkes først ved høyt volum eller eldre instanstyper |
| Egen VPN-infrastruktur (strømforbruk) | Lavere strømtrekk | Opptil 50 % mer CPU-last på eldre rutere | Relevant for kontorer med eget nettverksutstyr |
For de fleste virksomheter er altså ikke prisforskjellen mellom AES-128 og AES-256 en direkte fakturapost, den er en indirekte kostnad gjennom CPU-forbruk og eventuelt behov for kraftigere instanser dersom man krypterer enorme datamengder kontinuerlig. På moderne skyinstanser med AES-NI eller ARMv8-kryptoutvidelser er denne kostnaden så lav at den sjelden er avgjørende. Det er først på eldre maskinvare, i IoT-enheter, eller ved svært høyt gjennomstrømmingsvolum at forskjellen begynner å telle i praksis.
Fem virkelige eksempler på valg mellom AES-128 og AES-256
Teori er én ting, men beslutningen tas konkret, avdeling for avdeling. Her er fem situasjoner der valget faktisk gjør en forskjell.
1. Site-to-site VPN mellom to norske kontorer. En mellomstor bedrift med begrenset nettverksutstyr velger ofte AES-128-GCM for tunnelen mellom hovedkontor og filial, siden gjennomstrømming og lav CPU-belastning på ruterne veier tyngre enn den teoretiske sikkerhetsmarginen. Trafikken er dessuten kortlevd, den mister ikke verdi om den i teorien kunne knekkes om flere tiår.
2. Diskkryptering på bærbare PC-er med sensitive kundedata. Her går de fleste virksomheter for AES-256, fordi en stjålet eller mistet maskin kan inneholde data som må forbli konfidensielt i årevis. Full-disk-kryptering med BitLocker eller FileVault bruker som standard AES-256, og ytelseskostnaden er neppe merkbar på moderne CPU-er med AES-NI.
3. TLS-terminering på en høyvolum API-gateway. En tjeneste som håndterer titusenvis av forespørsler i sekundet kan spare reell CPU-tid ved å tillate AES-128-GCM i cipher-listen, spesielt for klienter som ikke krever maksimal sikkerhetsmargin. Mange velger likevel AES-256-GCM som førstevalg og lar AES-128-GCM ligge som fallback.
4. Arkivering av myndighetsdata under NIS2. For kritisk infrastruktur og offentlig sektor i Norge og Norden er AES-256 i praksis blitt normen, fordi det dokumenterer “state of the art”-kryptering overfor tilsyn og revisorer, selv om regelverket ikke eksplisitt krever en bestemt nøkkellengde.
5. IoT-sensorer med begrenset batterikapasitet. Enheter som sender telemetridata fra industrianlegg eller smarte strømmålere velger ofte AES-128 fordi hver ekstra CPU-syklus koster batteritid. Her er dataene dessuten typisk kortlevde måleverdier, ikke informasjon som krever tiår med konfidensialitet.
Migreringsguide: fra AES-128 til AES-256 (eller omvendt)
Å bytte nøkkellengde er sjelden en ren “flip en bryter”-affære, men det er heller ikke en full re-arkitektur. Her er stegene de fleste team følger.
- Kartlegg alle steder AES brukes i dag: TLS-cipher-lister, diskkryptering, databasekryptering, VPN-konfigurasjon og eventuelle egne krypteringsrutiner i applikasjonskode.
- Sjekk maskinvarestøtte for AES-NI eller ARMv8 kryptoutvidelser på alle servere og enheter som skal håndtere den nye nøkkellengden, siden ytelsesgapet er langt større uten akselerasjon.
- Oppdater cipher-suiter i TLS-konfigurasjonen (nginx, Apache, load balancer) til å prioritere den ønskede AES-varianten, og behold den andre som fallback under overgangsperioden.
- Roter krypteringsnøkler gjennom en nøkkelhåndteringstjeneste som AWS KMS, Azure Key Vault eller Google Cloud KMS, slik at gamle 128-bit-nøkler ikke blir liggende aktive lenger enn nødvendig.
- Re-krypter eksisterende data i ro der det er praktisk mulig, med en plan for gradvis migrering fremfor en big-bang-rekryptering av hele datasettet på én gang.
- Test ytelsen i et representativt lastscenario før full utrulling, spesielt på eldre maskinvare, VPN-endepunkter og IoT-flåter der CPU-marginen er tynnere.
- Dokumenter endringen i sikkerhetspolicyer og eventuell DPIA, slik at valget av nøkkellengde er sporbart for revisjon under GDPR eller NIS2.
- Overvåk feilrater og ytelsesmetrikker i minst en driftssyklus etter migreringen, siden enkelte eldre klienter kan mangle støtte for enkelte cipher-suiter.
Et praktisk eksempel på hvordan man tvinger frem en spesifikk cipher i en OpenSSL-basert tjeneste, for testing av ytelsesforskjellen lokalt før produksjonsendring:
# Test gjennomstrømming for AES-128 og AES-256 lokalt
openssl speed -evp aes-128-gcm
openssl speed -evp aes-256-gcm
# Tving en spesifikk cipher-suite i nginx for A/B-testing
ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384';
ssl_prefer_server_ciphers on;Fordeler og ulemper med AES-128
AES-128 er ikke et kompromiss-valg for de som “ikke bryr seg om sikkerhet”. Det er den anbefalte standarden for svært mange bruksområder, og den har vært det i over to tiår uten et eneste praktisk gjennombrudd.
- Fordel: Opptil 40 % raskere i ren programvare, og fortsatt raskere selv med maskinvareakselerasjon.
- Fordel: Lavere CPU- og strømforbruk, avgjørende for IoT, mobil og batteridrevne enheter.
- Fordel: Fullt ut sikker mot alle kjente klassiske brute-force-angrep, med 2^128 mulige nøkler.
- Fordel: Godkjent av NIST FIPS 197 og akseptert i de fleste compliance-rammeverk for ikke-kritiske data.
- Ulempe: Effektiv sikkerhet kan i teorien falle til rundt 64 bit under Grovers algoritme, noe som er utilstrekkelig for data som må holde seg hemmelig i flere tiår.
- Ulempe: Mindre egnet som dokumentasjon av “state of the art”-kryptering overfor revisorer og tilsyn under NIS2.
Fordeler og ulemper med AES-256
AES-256 er standardvalget når marginen for fremtidig sikkerhet veier tyngre enn noen ekstra millisekunder CPU-tid, noe som i praksis gjelder stadig mer data etter hvert som lagringskostnadene faller og prosessorene blir raskere.
- Fordel: 2^256 mulige nøkler gir en enorm sikkerhetsmargin, også mot fremtidige kvanteangrep via Grovers algoritme.
- Fordel: Standard for data i ro hos AWS, Azure og Google Cloud, noe som forenkler compliance-dokumentasjon.
- Fordel: Ytelsesgapet mot AES-128 krymper til under 10 % på moderne CPU-er med AES-NI eller ARMv8-utvidelser.
- Fordel: Foretrukket for langtidsarkivering, myndighetsdata og alt som må forbli konfidensielt i flere tiår.
- Ulempe: Opptil 40 % tregere i ren programvare uten maskinvareakselerasjon, og opptil 50 % høyere CPU-last i enkelte VPN-scenarioer.
- Ulempe: Dårligere egnet for batteridrevne IoT-enheter og eldre nettverksutstyr uten AES-NI-støtte.
Fem bruksområder og anbefalt valg
Anbefalingen avhenger alltid av kombinasjonen av datalevetid, maskinvare og hvor mye gjennomstrømming som faktisk kreves. Her er en kortfattet oversikt over hva som typisk anbefales.
| Bruksområde | Anbefalt variant | Begrunnelse |
|---|---|---|
| Diskkryptering på bærbare enheter | AES-256 | Data må forbli konfidensielt selv om enheten mistes i flere år |
| Site-to-site VPN mellom kontorer | AES-128-GCM | Lav CPU-last, kortlevd trafikk, god nok margin |
| TLS-terminering på høyvolum API | AES-256-GCM (med AES-128 fallback) | Minimal ytelseskostnad med AES-NI, sterkere compliance-historie |
| IoT-sensorer og batteridrevne enheter | AES-128 | Lavere strømforbruk avgjørende for levetid |
| Skylagring av myndighets- og helsedata | AES-256 | Krav til langtidskonfidensialitet under NIS2/GDPR |
AES i norsk banksektor, offentlig forvaltning og telekom
Norske og nordiske bransjer med strenge krav til datasikkerhet har historisk vært tidlig ute med å standardisere på den sterkeste tilgjengelige nøkkellengden, selv der det koster noe i ytelse. I banksektoren, der løsninger som BankID og de underliggende betalingssystemene håndterer transaksjonsdata som må forbli konfidensielt i mange år etter selve transaksjonen, er AES-256 det klare normvalget for lagring av transaksjonslogger og kundedata. Kostnaden i ekstra CPU-tid er marginal sammenlignet med den regulatoriske risikoen ved å bruke en svakere nøkkellengde på finansielle data som kan bli gjenstand for revisjon flere tiår frem i tid.
Offentlig forvaltning i Norge, inkludert løsninger knyttet til ID-porten og andre nasjonale digitale tjenester, opererer under tilsvarende logikk. Data om innbyggere som samles inn av det offentlige har ofte en forventet levetid på flere tiår, noe som gjør AES-256 til det naturlige valget for lagring, mens selve kommunikasjonen mellom klient og server i mange tilfeller kan bruke TLS-oppsett som tillater begge nøkkellengder avhengig av klientens kapabiliteter. Telekomsektoren, med aktører som Telenor og Telia i førersetet i Norden, står overfor et litt annet dilemma: enorme mengder trafikk må krypteres i sanntid, samtidig som nettverksutstyr ofte har begrenset regnekraft sammenlignet med en dedikert skyserver. Her ser man oftere en bevisst bruk av AES-128 i deler av infrastrukturen der gjennomstrømming er kritisk, kombinert med AES-256 for de delene av nettverket som håndterer sensitive abonnementsdata og fakturainformasjon.
Et fellestrekk på tvers av disse bransjene er at valget av nøkkellengde sjelden tas isolert av utviklerteamet alene. Det er som regel en beslutning som involverer sikkerhetsarkitekter, complianceansvarlige og i noen tilfeller eksterne revisorer, nettopp fordi konsekvensene av et feil valg kan bety alt fra bøter under GDPR til tapt kundetillit etter en eventuell hendelse. Dette er også grunnen til at mange norske virksomheter velger å standardisere på AES-256 på tvers av hele organisasjonen for lagrede data, selv i systemer der AES-128 teknisk sett ville vært tilstrekkelig, rett og slett for å unngå kompleksiteten ved å administrere to forskjellige policyer parallelt.
GDPR, NIS2 og krav til nøkkellengde i Norge og EU
Verken GDPR eller NIS2-direktivet, implementert i Norge gjennom digitalsikkerhetsloven, spesifiserer en eksakt nøkkellengde i lovteksten. Begge rammeverkene bruker formuleringer som “passende tekniske tiltak” og “state of the art”-sikkerhet, og overlater den konkrete tolkningen til virksomheten og eventuelt tilsynsmyndigheten. I praksis har dette ført til at 256-bit AES har blitt referansepunktet organisasjoner viser til når de skal dokumentere at de følger anerkjent beste praksis, spesielt for kritisk infrastruktur som dekkes av NIS2.
ENISA, EUs cybersikkerhetsbyrå, har lenge publisert anbefalinger om algoritmer og nøkkellengder som europeiske myndigheter og virksomheter bruker som referanse. Der fremgår det at 128-bit symmetriske nøkler fortsatt regnes som akseptable for de fleste formål, mens 256-bit foretrekkes for systemer som krever høy sikkerhetsmargin eller lang levetid på konfidensialiteten. For norske virksomheter som er omfattet av NIS2 gjennom digitalsikkerhetsloven, betyr dette i praksis at valget av AES-256 for kritiske systemer er den tryggeste dokumentasjonsstrategien overfor tilsyn, selv om AES-128 ikke i seg selv er et brudd på regelverket.
Verdikt: hvilken bør du velge?
Basert på tallene over er svaret ikke et enkelt “alltid 256-bit”, selv om det ofte er den tryggeste standardinnstillingen. Velg AES-128 når du drifter høyvolum-trafikk med begrenset maskinvare, batteridrevne enheter, eller kortlevd data der en teoretisk fremtidig kvantetrussel er irrelevant. Ytelsesgevinsten på 8-40 % er reell og merkbar på eldre eller ressursbegrenset maskinvare. Velg AES-256 når dataene skal forbli konfidensielle i årevis, når du drifter på moderne servere med AES-NI der ytelsesgapet krymper til under 10 %, eller når du trenger en klar “state of the art”-dokumentasjon overfor revisorer under NIS2 og GDPR.
For de fleste nordiske virksomheter i 2026 er den pragmatiske løsningen en hybrid tilnærming: AES-256 som standard for data i ro og for TLS-terminering på moderne infrastruktur, med AES-128 reservert for spesifikke tilfeller der maskinvarebegrensninger eller ekstreme gjennomstrømmingskrav gjør ytelsesgevinsten avgjørende. Det er nøyaktig mønsteret AWS, Azure og Google Cloud selv har landet på i sine standardinnstillinger, og det er et godt utgangspunkt for de fleste andre.
Det viktigste å ta med seg fra tallene i denne artikkelen er at debatten om AES-128 mot AES-256 sjelden bør avgjøres av en generell magefølelse om at “mer bit er alltid bedre”. Den bør avgjøres av tre konkrete spørsmål: Hvor lenge må disse spesifikke dataene forbli konfidensielle? Hvilken maskinvare skal faktisk gjøre krypteringsarbeidet, og støtter den AES-NI eller tilsvarende akselerasjon? Og hvilke compliance-krav, som NIS2 eller sektorspesifikke regler, stiller føringer for dokumentert sikkerhetsnivå? Når disse tre svarene er på plass, faller valget mellom 10 og 14 runder som regel naturlig ut av seg selv, uten at man trenger å gjette.
Hvordan AES-256 og AES-128 måler seg mot andre krypteringsstandarder
AES lever ikke i et vakuum. I praksis må sikkerhetsarkitekter også vurdere hvordan AES-familien plasserer seg mot alternative chiffer, og hvordan valget av nøkkellengde påvirker resten av kryptografistabelen. ChaCha20, en strømchiffer designet av Daniel Bernstein, har blitt et populært alternativ på enheter uten AES-NI, siden ChaCha20 er raskt i ren programvare uavhengig av maskinvarestøtte. Der AES-256 kan tape opptil 40 % ytelse mot AES-128 uten akselerasjon, er ChaCha20-Poly1305 designet for å levere jevn ytelse på tvers av plattformer, noe som gjør det til et naturlig valg for mobilapper og eldre maskinvare der man ikke kan garantere AES-NI-støtte.
Det er også viktig å skille mellom selve blokkchifferet AES og resten av kryptosystemet en tjeneste bruker. AES-256 løser kun symmetrisk kryptering, altså selve datakrypteringen når begge parter allerede deler en nøkkel. Nøkkelutvekslingen som etablerer den delte nøkkelen håndteres typisk av asymmetriske algoritmer som RSA eller elliptisk kurve-baserte metoder som ECDHE, og signering av data håndteres av digitale signaturalgoritmer som ECDSA eller Ed25519. Dette betyr at et system kan ha maksimal AES-256-kryptering på selve dataene, men fortsatt være sårbart hvis nøkkelutvekslingen bruker en svak eller utdatert asymmetrisk algoritme. Post-kvante-migrasjonen som nå pågår i bransjen retter seg da også primært mot disse asymmetriske komponentene, som ML-KEM for nøkkelutveksling og ML-DSA for signaturer, nettopp fordi disse er langt mer sårbare for kvantedatamaskiner enn AES er.
For en nordisk virksomhet som skal sette opp et helhetlig kryptografioppsett i 2026, er derfor riktig rekkefølge å først sikre nøkkelutveksling og signering med moderne, godt validerte algoritmer, og deretter velge AES-nøkkellengde basert på dataenes levetid og ytelseskravene beskrevet tidligere i denne artikkelen. AES-256 og AES-128 er begge trygge byggeklosser, men de er bare én del av en større kjede der det svakeste leddet avgjør den reelle sikkerheten.
Veien videre: hva skjer med AES etter 2026?
AES som algoritme er ikke under noe umiddelbart press for å byttes ut. I motsetning til RSA og elliptisk kurve-kryptografi, som NIST allerede har satt en klar utfasingsplan for gjennom post-kvante-standardene ML-KEM og ML-DSA, finnes det ingen tilsvarende utfasingsplan for AES. Grunnen er enkel: symmetrisk kryptografi som AES er langt mer motstandsdyktig mot kvantedatamaskiner enn asymmetrisk kryptografi, og en dobling av nøkkellengden fra 128 til 256 bit gir tilstrekkelig margin mot Grovers algoritme uten at algoritmen selv trenger å endres.
Det man derimot ser i bransjen fremover mot 2027 og videre, er en gradvis dreining der flere organisasjoner rett og slett hopper over AES-128 for nye systemer og går rett til AES-256 som standardvalg, ettersom maskinvarestøtten for AES-NI og ARMv8-kryptoutvidelser nå er så utbredt at ytelseskostnaden har blitt marginal for de fleste vanlige arbeidslaster. Unntaket er og forblir ressursbegrensede enheter som IoT-sensorer, eldre nettverksutstyr og batteridrevne systemer, der hver prosentandel CPU-besparelse fortsatt teller. For disse nisjene vil AES-128 trolig forbli det pragmatiske valget i mange år fremover, rett og slett fordi den underliggende maskinvaren ikke endrer seg like raskt som skyinfrastrukturen gjør.
Ofte stilte spørsmål om AES-128 og AES-256
Er AES-128 usikkert sammenlignet med AES-256?
Nei. Ingen praktisk brute-force-metode eksisterer mot noen av variantene i dag. AES-128 gir 2^128 mulige nøkler, et tall så stort at klassisk brute force forblir umulig i overskuelig fremtid. Forskjellen ligger i sikkerhetsmarginen mot fremtidige trusler, ikke i dagens praktiske risiko.
Hvor mye tregere er AES-256 enn AES-128?
Avhengig av modus og maskinvare varierer forskjellen fra rundt 8 % til 40 %. Uten maskinvareakselerasjon som AES-NI kan gapet nærme seg 40 % i ren programvare. Med AES-NI eller ARMv8 kryptoutvidelser på moderne servere krymper forskjellen ofte til under 10 %.
Hvilken nøkkellengde bruker AWS, Azure og Google Cloud som standard?
Alle tre skyleverandørene bruker AES-256 som standard for kryptering av data i ro. For trafikk i bevegelse via TLS varierer det etter cipher-suite-konfigurasjon, men AES-256-GCM er ofte førstevalget på moderne infrastruktur med maskinvareakselerasjon.
Kan en kvantedatamaskin knekke AES-256?
Ikke med noen kjent metode i dag. Grovers algoritme kan i teorien halvere den effektive sikkerheten til symmetriske nøkler, noe som ville redusere AES-256 til et effektivt nivå på rundt 128 bit, fortsatt regnet som solid. AES-128 ville i samme scenario falle til rundt 64 bit, som er svakere enn ønskelig for langtidsdata.
Er AES-192 fortsatt relevant?
AES-192 finnes i standarden med 12 runder og en 192-bit nøkkel, men den er sjelden brukt i praksis. De fleste implementasjoner og skytjenester tilbyr kun AES-128 og AES-256 som praktiske valg, og AES-192 har derfor liten reell utbredelse.
Krever NIS2 eller GDPR spesifikt AES-256?
Nei, ingen av regelverkene spesifiserer en eksakt nøkkellengde. Begge bruker formuleringer om “passende” eller “state of the art”-sikkerhet. AES-256 har likevel blitt referansepunktet mange virksomheter bruker for å dokumentere at de følger anerkjent beste praksis overfor tilsyn.
Bør jeg bytte fra AES-128 til AES-256 på eksisterende systemer?
Det avhenger av datatypen. For langtidsdata som helseopplysninger eller myndighetsarkiv gir det mening. For høyvolum VPN-trafikk eller IoT-telemetri med kort levetid er kostnaden ved migrering sjelden verdt gevinsten, siden AES-128 allerede gir tilstrekkelig sikkerhet for den typen data.
Påvirker valg av nøkkellengde TLS-håndtrykket?
Nei, selve nøkkelutvekslingen og håndtrykket i TLS 1.3 er uavhengig av hvilken AES-variant som brukes til selve bulk-krypteringen. Studier har vist at håndtrykksytelsen er tilnærmet identisk mellom AES-128-GCM og AES-256-GCM, mens forskjellen først viser seg i gjennomstrømmingen av selve datatrafikken etter håndtrykket.
Hva er forskjellen mellom AES-CBC og AES-GCM, uavhengig av nøkkellengde?
CBC er en eldre modus som kun gir konfidensialitet og krever en separat mekanisme for å sikre at data ikke er tuklet med. GCM er en nyere, autentisert modus (AEAD) som gir både konfidensialitet og integritet i samme operasjon, og er i dag standardvalget i TLS 1.3, uavhengig av om man bruker AES-128 eller AES-256.
Bruker Signal, WhatsApp og andre krypterte meldingstjenester AES-128 eller AES-256?
De fleste moderne ende-til-ende-krypterte meldingsapper, inkludert Signal-protokollen som ligger til grunn for flere store tjenester, bruker AES-256 for selve meldingsinnholdet, kombinert med moderne nøkkelutvekslingsprotokoller for å etablere de delte nøklene mellom avsender og mottaker.
