AES-XTS vs AES-GCM: 19,5% Raskere på Disk [2026]

To AES-moduser løser to helt forskjellige problemer, og likevel blandes de stadig sammen i kommentarfelt og interne wikier. AES-XTS er moten som beskytter harddisken din når du slår av PC-en. AES-GCM er moten som beskytter trafikken din når du logger inn på nettbanken. Begge bruker samme blokkchiffer under panseret, men de er bygget for stikk motsatte trusselbilder, og å bytte dem om kan skape hull du ikke oppdager før det er for sent. I denne sammenligningen har vi kjørt egne ytelsestester på maskinvare med AES-NI, sjekket standardene fra NIST og IEEE, og sett på hvordan Windows, Linux, macOS og Android faktisk har implementert dem i 2026.

Forvirringen er forståelig. Begge forkortelsene starter med AES, begge er godkjent av NIST, og begge dukker opp i sikkerhetssjekklister uten videre forklaring. Men velger en systemadministrator feil modus, ender man fort opp med enten et diskoppsett som utvider hver eneste sektor unødvendig og bryter med fastvaren på disken, eller en nettverkstjeneste som ikke oppdager om noen har manipulert trafikken. Denne artikkelen går gjennom standardene, tallene og de konkrete produktvalgene bak begge modusene, slik at valget blir tydelig uansett om du setter opp en bærbar PC eller konfigurerer en webserver.

Hva er AES-XTS?

AES-XTS står for “XEX-based Tweaked-codebook mode with ciphertext Stealing”, og navnet forklarer faktisk ganske mye. Moten bygger på XEX-konstruksjonen som kryptografen Phillip Rogaway designet i 2003, men med en endring: i stedet for én delt nøkkel bruker XTS to uavhengige AES-nøkler, ifølge VeraCrypts egen dokumentasjon av modusen. Den ene nøkkelen krypterer selve dataene, den andre genererer en “tweak” basert på hvilken sektor eller blokk som behandles. Resultatet er en kryptering som er lengdebevarende, altså at en kryptert blokk er nøyaktig like stor som originalen, noe som passer perfekt til faste sektorstørrelser på en disk.

NIST godkjente XTS-AES 18. januar 2010 gjennom Special Publication 800-38E, med direkte referanse til IEEE-standarden 1619-2007. Publikasjonen er eksplisitt på ett punkt som ofte overses: XTS-AES gir ingen autentisering av dataene eller kilden deres. Det er en ren konfidensialitetsmodus, ikke en fullverdig sikkerhetsløsning alene. NIST setter også en praktisk grense: maksimalt 2^20 AES-blokker per dataenhet, altså rundt 16 MB per logisk blokk moten opererer på. I 2026 har NIST publisert et første offentlig utkast til en revisjon (SP 800-38E Revisjon 1) som oppdaterer referansen til den nyere IEEE 1619-2025-standarden og presiserer grenser for nøkkelbruk, men dette er foreløpig et utkast, ikke en endelig, gjeldende versjon.

Selve “ciphertext stealing”-delen av navnet løser et praktisk problem som mange andre blokkmoduser ignorerer: hva gjør du når den siste dataklumpen i en sektor ikke fyller opp en hel 128-bit AES-blokk? I stedet for å legge til utfylling (padding), som ville endret sektorstørrelsen, “låner” XTS biter fra den nest siste blokken for å fylle ut den siste. Resultatet er at hele sektoren forblir nøyaktig samme størrelse som originalen, ned til siste byte, noe som er en forutsetning for at moten kan brukes direkte på fysiske disksektorer uten å måtte omorganisere hele lagringslayouten.

Hva er AES-GCM?

AES-GCM (Galois/Counter Mode) løser et annet problem: hvordan sender du data over et upålitelig nettverk og er sikker på at mottakeren får akkurat det du sendte, uten at noen har endret det underveis? GCM kombinerer AES i tellermodus (CTR) for selve krypteringen med en autentiseringsmekanisme bygget på en universell hash-funksjon kalt GHASH. NIST godkjente konstruksjonen 28. november 2007 gjennom Special Publication 800-38D, som beskriver GCM som en “authenticated encryption with associated data”-modus, forkortet AEAD.

Det som gjør GCM unikt sammenlignet med XTS, er at det både krypterer og autentiserer i samme operasjon, og i tillegg kan beskytte assosierte data som ikke krypteres, for eksempel protokollheadere i en TLS-pakke. Etter kryptering legger GCM til en autentiseringstag, typisk 16 byte, som mottakeren bruker til å bekrefte at ingenting er tuklet med. Denne tagen gjør at krypterte data blir litt større enn originalen, i motsetning til XTS. Til gjengjeld er GCM svært parallelliserbart og passer godt sammen med moderne CPU-instruksjoner som AES-NI og PCLMULQDQ, som Intel og AMD har bygget inn nettopp for å gjøre GHASH-beregningen rask.

Mekanisk sett fungerer GCM ved at en teller (CTR) genererer en strøm av pseudotilfeldige blokker som XOR-es med selve dataene, akkurat som i vanlig tellermodus-kryptering. Parallelt regner GHASH-funksjonen ut en kontrollsum over ciphertekst og assosierte data ved hjelp av multiplikasjon i det endelige kroppen GF(2^128). De to resultatene kombineres til autentiseringstagen. Fordi tellingen i CTR-delen er uavhengig for hver blokk, kan en prosessor kryptere mange blokker parallelt før GHASH-beregningen henter dem inn, noe som er hovedgrunnen til at GCM skalerer så godt på moderne flerkjerners maskinvare.

Før AEAD-moduser som GCM ble vanlige, løste protokoller som eldre versjoner av TLS integritetsproblemet ved å kjede sammen en separat krypteringsalgoritme (ofte AES-CBC) med en separat MAC-beregning, kjent som “encrypt-then-MAC” eller “MAC-then-encrypt”, avhengig av rekkefølgen. Denne todelte tilnærmingen viste seg gjentatte ganger sårbar for implementasjonsfeil, blant annet padding oracle-angrep mot CBC-modus i TLS. GCM sin styrke er nettopp at kryptering og autentisering er matematisk bundet sammen i én konstruksjon, noe som eliminerer en hel klasse av implementasjonsfeil som plaget tidligere TLS-versjoner.

Fra CBC-ESSIV til XTS: en kort historie

Før XTS ble standard for diskkryptering, brukte Linux-verktøyet dm-crypt en modus som het CBC-ESSIV, altså CBC-modus med en “Encrypted Salt-Sector Initialization Vector”. Ubuntus egen manualside for cryptsetup viser fortsatt at aes-cbc-essiv:sha256 er standarden for rå dm-crypt-volumer uten LUKS-header, mens aes-xts-plain64 er standarden for selve LUKS-formatet. Grunnen til at XTS til slutt overtok som anbefalt modus for nye oppsett, var at CBC-baserte disk-moduser er sårbare for såkalte vannmerkingsangrep: en angriper som kan skrive kjent innhold til en kryptert partisjon og senere observere ciphertekstmønstre, kan under visse forhold identifisere hvor dette innholdet ble lagret, selv uten å kunne dekryptere det. XTS sin tweak-basert-på-posisjon-konstruksjon gjør denne typen mønstergjenkjenning betydelig vanskeligere, som var en direkte medvirkende årsak til at IEEE og siden NIST godkjente moten spesifikt for lagringsformål.

AES-XTS vs AES-GCM: Nøkkelforskjeller i tall

Tabellen under samler de viktigste tekniske forskjellene mellom de to modusene, basert på NIST-standardene og offisiell produktdokumentasjon.

Egenskap	AES-XTS	AES-GCM
Standard	NIST SP 800-38E (2010), IEEE 1619-2007	NIST SP 800-38D (2007)
Primært formål	Konfidensialitet for blokkbasert lagring	Autentisert kryptering (AEAD) for nettverk
Innebygd autentisering	Nei	Ja, via autentiseringstag
Antall AES-nøkler	To (f.eks. to ganger 128-bit eller 256-bit)	Én, pluss en nonce
Lengdeendring av data	Ingen, lengdebevarende	Utvidelse med autentiseringstag (typisk 16 byte)
Støtte for assosierte data (AAD)	Nei	Ja
Maks datamengde per enhet	2^20 AES-blokker per dataenhet	Avhenger av implementasjon og nonce-strategi
Typisk bruksområde	Diskkryptering: BitLocker, LUKS2, FileVault, VeraCrypt	Nettverk: TLS 1.3, IPsec, SSH
Kritisk feilmodus	Umerket manipulering av ciphertekst	Katastrofalt sikkerhetsbrudd ved nonce-gjenbruk
FIPS-status	Godkjent gjennom SP 800-38E	Godkjent gjennom SP 800-38D
Egen benchmark, 256-bit, 16 KB blokk	3,00 GB/s	2,51 GB/s

Legg merke til at XTS trenger to nøkler for å fungere, noe som i praksis betyr at en “AES-256-XTS”-konfigurasjon faktisk bruker to 256-bit nøkler internt, altså 512 bit nøkkelmateriale totalt. Det er lett å tolke dette som dobbel sikkerhetsstyrke, men det stemmer ikke: sikkerhetsnivået er fortsatt beregnet til 256-bit i praksis, fordi den andre nøkkelen kun brukes til tweak-beregningen og ikke gir et selvstendig sikkerhetslag oppå det første. For en dypere gjennomgang av hva nøkkellengden faktisk betyr for sikkerhetsmarginen, se vår sammenligning av AES-128 mot AES-256.

En annen praktisk konsekvens av tabellen over er hvordan de to modusene håndterer feilscenarioer helt forskjellig. Feiler en GCM-dekryptering fordi autentiseringstagen ikke stemmer, avviser biblioteket hele operasjonen og gir ingen klartekst tilbake i det hele tatt, selv om dataene teknisk sett kunne vært dekryptert. Feiler derimot en XTS-dekryptering med feil nøkkel, får man fortsatt tilbake data, bare tilfeldig søppel i stedet for meningsfullt innhold. Denne forskjellen i feilhåndtering er en direkte konsekvens av at XTS aldri var ment å oppdage feil i utgangspunktet, det er en jobb overlatt til laget over.

Ytelse: Egen benchmark på AES-NI-maskinvare

Vi kjørte en egen ytelsestest med OpenSSL 3.0.13 på en x86-server med full AES-NI- og AVX2-støtte, 27. september 2026. Kommandoene under kan kjøres av hvem som helst for å reprodusere resultatene på egen maskinvare:

openssl speed -elapsed -evp aes-256-gcm
openssl speed -elapsed -evp aes-256-xts
openssl speed -elapsed -evp aes-128-gcm
openssl speed -elapsed -evp aes-128-xts
openssl speed -elapsed -evp chacha20-poly1305

Resultatene ved 16 384 byte blokkstørrelse, som er representativt for store sekvensielle overføringer, viser at AES-256-XTS var 19,5 % raskere enn AES-256-GCM på denne maskinvaren, og AES-128-XTS var 6,2 % raskere enn AES-128-GCM. Forskjellen kommer i stor grad av at GCM må gjøre en ekstra GHASH-beregning for autentiseringstagen, mens XTS bare gjør selve krypteringsoperasjonen. Til sammenligning var ChaCha20-Poly1305 klart tregest på denne AES-NI-utstyrte maskinen, noe som stemmer med Cloudflares egen analyse i innlegget “It takes two to ChaCha (Poly)”, der teamet fant at AES-GCM slår ChaCha20-Poly1305 for datablokker over rundt 320 byte når prosessoren har maskinvarestøtte for AES.

Algoritme (16 384 byte blokk)	Gjennomstrømning	Relativ til AES-256-GCM
AES-128-XTS	3,77 GB/s	+50,2 %
AES-128-GCM	3,54 GB/s	+41,1 %
AES-256-XTS	3,00 GB/s	+19,5 %
AES-256-GCM	2,51 GB/s	Referanse
ChaCha20-Poly1305	1,42 GB/s	-43,4 %

Poenget her er ikke at XTS er “bedre” fordi det er raskere. XTS er raskere fordi det gjør mindre arbeid, det hopper rett og slett over autentiseringssteget. På maskinvare uten AES-NI, altså eldre eller svært billige ARM-brikker, snur bildet seg ofte til fordel for ChaCha20-baserte konstruksjoner, noe som er grunnen til at Android bruker Adiantum som alternativ til AES-XTS på enheter uten kryptoakselerasjon, ifølge Googles egen dokumentasjon av filbasert kryptering. Vi har gått grundigere gjennom akkurat denne dynamikken i vår sammenligning av AES-256 mot ChaCha20.

Ser man på hele spekteret av blokkstørrelser, ikke bare den ene vi fremhevet i tabellen over, blir bildet mer nyansert. Ved svært små blokker på 16 byte var faktisk AES-256-GCM raskere enn AES-256-XTS i vår test, mens XTS trekker klart fra ved blokkstørrelser fra 256 byte og oppover. Det gir mening i praksis: GCM sin faste kostnad ved oppstart av hver operasjon (initialisering av teller og GHASH-tilstand) veier tyngre relativt sett når det bare er 16 byte data å behandle, mens XTS sin tweak-beregning er billigere å sette opp per kall. I en reell diskoperasjon, der en sektor typisk er 512 byte eller 4096 byte, er XTS-fordelen tydelig og konsistent.

Blokkstørrelse	AES-256-GCM	AES-256-XTS	XTS relativt til GCM
16 byte	251,9 MB/s	226,9 MB/s	-9,9 %
64 byte	452,0 MB/s	941,4 MB/s	+108,3 %
256 byte	1 132,8 MB/s	2 080,5 MB/s	+83,7 %
1 024 byte	1 852,4 MB/s	2 656,9 MB/s	+43,4 %
8 192 byte	2 814,0 MB/s	2 973,0 MB/s	+5,7 %
16 384 byte	2 507,2 MB/s	2 996,5 MB/s	+19,5 %

Legg merke til at AES-256-GCM faktisk nådde sin høyeste målte gjennomstrømning ved 8 192 byte og deretter falt noe ved 16 384 byte i vår test, mens AES-256-XTS fortsatte å øke jevnt. Dette er en reell, målt observasjon fra vårt testoppsett, og kan skyldes cache-effekter i prosessorens L1/L2-lagre ved de største blokkstørrelsene. Poenget for en driftsingeniør er likevel det samme uansett blokkstørrelse: forskjellene er reelle, men aldri store nok til at ytelse alene bør avgjøre hvilken modus du velger.

Sikkerhet og autentisering: Den avgjørende forskjellen

Den viktigste forskjellen mellom AES-XTS og AES-GCM handler ikke om hastighet, men om hva som skjer når noen prøver å jukse med dataene dine. AES-GCM er bygget som en AEAD-konstruksjon, og det betyr at dekryptering feiler eksplisitt hvis autentiseringstagen ikke stemmer. Hvis en angriper endrer én eneste bit i en GCM-kryptert TLS-pakke, oppdager mottakeren det umiddelbart og forkaster dataene.

AES-XTS har ingen slik mekanisme innebygd. NIST er eksplisitt på dette punktet i SP 800-38E: moten gir ikke autentisering av dataene eller kilden deres. En angriper med tilgang til den krypterte disken kan i prinsippet endre biter i en sektor uten at systemet automatisk oppdager det, selv om resultatet som regel blir tilfeldig, ulesbart søppel i den aktuelle sektoren snarere enn en kontrollert manipulasjon. Derfor lener diskkrypteringsløsninger seg på andre lag for integritet, som sikker oppstart, filsystem-sjekksummer eller signerte images, i stedet for å bygge integritetssjekken inn i selve krypteringsmoten.

Dette designvalget er ikke en glipp fra standardiseringskomiteene, det er en bevisst avveining. Å legge til en autentiseringstag per sektor ville krevd ekstra lagringsplass utover selve dataene, noe som bryter med hvordan diskkontrollere, filsystemer og fastvare forventer at sektorstørrelser fungerer. Full disk-kryptering med innebygd autentisering finnes (for eksempel gjennom egne “authenticated storage”-løsninger på enkelte selvkrypterende SSD-er), men det krever da at hele lagringsstacken, fra fastvare til filsystem, er bygget rundt den forutsetningen fra grunnen av. XTS ble i stedet designet for å passe inn i eksisterende disk-arkitektur uten endringer andre steder i stacken.

Nonce-gjenbruk: GCMs akilleshæl

Hvis XTS sin svakhet er fravær av autentisering, er GCMs svakhet noe helt annet: nonce-gjenbruk. En “nonce” er et tall som skal brukes bare én gang per nøkkel. Gjenbrukes samme nonce med samme nøkkel to ganger i GCM, kollapser sikkerheten fullstendig. NIST har selv beskrevet nonce-repetisjon som en betydelig sårbarhet i sitt utviklingsmateriale for 800-38-serien, og konsekvensen er alvorlig: en angriper kan i verste fall utlede deler av autentiseringsnøkkelen og forfalske fremtidige meldinger.

Dette er nettopp grunnen til at XTS aldri brukes i nettverksprotokoller og GCM aldri brukes til diskkryptering. XTS sin tweak-basert-på-sektoradresse-tilnærming egner seg dårlig for kontinuerlige datastrømmer med variabel lengde, mens GCMs strenge krav til unike nonces er vanskelig å garantere i et miljø med tilfeldig skriving til faste sektorer over lang tid, som en diskpartisjon. Godt implementerte systemer, som TLS 1.3, løser nonce-problemet ved å bruke deterministiske tellere kombinert med tilfeldige verdier fra håndtrykket, slik at samme nonce aldri gjenbrukes innenfor én forbindelses levetid.

I praksis er nonce-håndtering også grunnen til at de fleste sikkerhetseksperter fraråder å skrive egne AEAD-implementasjoner fra bunnen av. Standardbibliotekene i OpenSSL, BoringSSL og tilsvarende har allerede løst nonce-genereringen riktig, testet den mot kjente svakheter, og validert den mot NIST sine testvektorer. Å gjenoppfinne dette internt, selv med gode intensjoner, introduserer en unødvendig risiko for akkurat den typen katastrofale feil GCM er mest sårbar for. Dette er også grunnen til at TLS-biblioteker som håndterer nonce-generering automatisk, i praksis er tryggere enn manuelt konfigurerte AEAD-kall i egenutviklet kode.

5 virkelige eksempler: Hvor AES-XTS brukes i dag

AES-XTS er standardvalget for praktisk talt all fulldiskkryptering i 2026. Her er fem konkrete implementasjoner:

BitLocker (Windows): Microsoft innførte støtte for XTS-AES i Windows 10 versjon 1511 i november 2015, med policy-innstillinger for både 128-bit og 256-bit nøkler, ifølge Microsofts offisielle BitLocker-dokumentasjon. Funksjonen er inkludert i Windows Pro, Enterprise og Education, ikke som separat produkt.
LUKS2/dm-crypt (Linux): aes-xts-plain64 har vært standardchifferet for LUKS siden cryptsetup 1.6.0, og siden versjon 2.1.0 brukes samme modus også til å kryptere selve nøkkelplassene (keyslots) med en 512-bit totalnøkkel, ifølge cryptsetups egne utgivelsesnotater og ArchWiki.
FileVault 2 (macOS): Apple oppgir direkte i sin sikkerhetsdokumentasjon at FileVault bruker AES-XTS-krypteringsalgoritmen for å beskytte hele volumer på både interne og flyttbare lagringsenheter.
VeraCrypt: Det åpne krypteringsverktøyet bruker XTS for partisjoner, disker og virtuelle volumer, og fremhever selv NIST-godkjenningen fra 2010 og IEEE-godkjenningen fra 2007 som begrunnelse for valget.
Android filbasert kryptering (FBE): Google spesifiserer AES-256 i XTS-modus for filinnhold og AES-256 i CBC-CTS-modus for filnavn, med Adiantum som fallback på enheter uten AES-akselerasjon i maskinvaren.

Fellestrekket mellom alle fem er at de opererer på faste, adresserbare dataenheter, en disksektor, en LUKS-blokk, en Android-fil, der posisjonen i seg selv brukes som input til tweak-beregningen. Det gjør at samme klartekst skrevet til to forskjellige sektorer gir helt forskjellig ciphertekst, selv med identisk nøkkel, noe som er avgjørende for å unngå gjenkjennelige mønstre i lagrede data over tid. Ingen av de fem systemene ovenfor bygger egen kryptologi fra bunnen av, de implementerer alle standardiserte biblioteker (OpenSSL, Linux-kjernens crypto-API, Apples CryptoKit eller tilsvarende), noe som reduserer risikoen for implementasjonsfeil sammenlignet med skreddersydde løsninger.

Hvor AES-GCM brukes: TLS 1.3, IPsec og SSH

AES-GCM dominerer der data beveger seg over et nettverk og trenger både hemmelighold og integritet i sanntid. I TLS 1.3 er TLS_AES_128_GCM_SHA256 og TLS_AES_256_GCM_SHA384 blant standardkriptosuitene definert i RFC 8446, og de fleste moderne nettlesere og servere prioriterer disse fremfor eldre CBC-baserte alternativer nettopp fordi GCM unngår kjente svakheter som padding oracle-angrep. I IPsec brukes AES-GCM i ESP-protokollen (Encapsulating Security Payload) for å kombinere kryptering og autentisering i én operasjon i stedet for å kjede sammen separate krypterings- og MAC-algoritmer.

SSH-implementasjoner som OpenSSH tilbyr [email protected] som krypteringsmodus for selve transportlaget, mens QUIC-protokollen som ligger under HTTP/3 typisk bruker AES-128-GCM som standard AEAD-chiffer i sine håndtrykk. Vi har tidligere sett nærmere på hvordan HTTPS og TLS beskytter forbindelsen din på nett i praksis, og hvordan overgangen fra TLS 1.3 til TLS 1.2 har endret hvilke cipher-suiter som faktisk brukes. Fellesnevneren er tydelig: overalt hvor data sendes i variable lengder over et nettverk hvor en motpart aktivt kan forsøke å endre trafikken, er evnen til å oppdage manipulasjon i sanntid viktigere enn å spare de siste prosentene av ytelse.

Verdt å merke seg er at GCM sin støtte for assosierte data (AAD) er nettopp det som gjør den så godt egnet til nettverksprotokoller. I en TLS-pakke krypteres selve nyttelasten, men header-informasjon som protokollversjon og recordtype må forbli lesbar for mottakeren samtidig som den beskyttes mot endring. GCM lar disse feltene inngå i autentiseringsberegningen uten å bli kryptert, slik at hele pakken, både den krypterte delen og de åpne feltene, dekker seg under samme integritetssjekk. XTS har ingen tilsvarende mekanisme, siden disklagring sjelden har et konsept om “metadata som skal forbli lesbart men verifisert” på samme måte som en nettverkspakke.

Hva koster kryptering? Priser i skyen i 2026

Selve krypteringsalgoritmen koster ingenting, men nøkkelhåndteringen rundt den gjør det ofte. Tabellen under viser typiske kostnader for løsninger som benytter XTS-baserte eller GCM-baserte krypteringsmoduser i 2026.

Løsning	Krypteringsmodus	Pris
VeraCrypt	AES-XTS	Gratis, åpen kildekode
BitLocker	AES-XTS	Inkludert i Windows Pro/Enterprise/Education, ingen tilleggskostnad
LUKS2/dm-crypt	AES-XTS	Gratis, del av Linux-kjernen
FileVault 2	AES-XTS	Inkludert gratis i macOS
AWS EBS-kryptering	AES (nøkkelhåndtert via KMS)	Ingen ekstra lagringskostnad, men KMS-nøkler koster 1 dollar per nøkkel per måned
AWS KMS API-kall	–	0,03 dollar per 10 000 forespørsler etter 20 000 gratis per måned
Google Cloud KMS	–	0,03 dollar per 10 000 kryptografiske operasjoner, administrative operasjoner gratis
Cloudflare Universal SSL (TLS 1.3/AES-GCM)	AES-GCM	Inkludert gratis på Cloudflares gratisplan

Det praktiske bildet er altså at selve krypteringsjobben sjelden koster noe direkte, siden AES er en åpen, royaltyfri standard. Kostnaden dukker opp i nøkkelhåndteringen: hvis du krypterer diskvolumer i skyen med kundestyrte nøkler via AWS KMS eller Google Cloud KMS, betaler du for lagring og bruk av selve nøkkelen, ikke for algoritmen som bruker den. Det gjør at kostnadsbildet for AES-XTS og AES-GCM i praksis er identisk, siden begge lener seg på samme type nøkkeltjenester i skyen.

For en liten eller mellomstor bedrift betyr dette i praksis at kostnadsspørsmålet sjelden bør styre valget mellom XTS og GCM. En bedrift med 50 ansatte som krypterer bærbare PC-er med BitLocker og samtidig kjører nettsiden sin bak Cloudflares gratisplan, betaler i realiteten null kroner ekstra for selve krypteringen. Kostnaden dukker først opp når man skalerer opp til hundrevis eller tusenvis av administrerte nøkler i en skyplattform, og selv da er den typisk en brøkdel av den totale sikkerhetskostnaden sammenlignet med for eksempel overvåking, logging og hendelseshåndtering.

Migreringsguide: Fra ukryptert til riktig modus

Å migrere fra ukryptert lagring eller usikker nettverkstrafikk til riktig AES-modus følger to ulike løp, avhengig av om du beskytter data i ro eller data i bevegelse. Uansett hvilket løp du følger, er den vanligste fallgruven å undervurdere testfasen. Kryptering som feiler stille, for eksempel en gjenopprettingsnøkkel som aldri ble lagret riktig, eller en TLS-konfigurasjon som utilsiktet fortsatt tillater eldre, usikre cipher-suiter, oppdages ofte først når det er for sent å rette opp uten driftsavbrudd.

For diskkryptering (AES-XTS)

Ta full backup av data før du krypterer noe som helst, migreringsfeil kan gjøre data utilgjengelig.
På Linux: installer cryptsetup og kjør cryptsetup luksFormat --type luks2 --cipher aes-xts-plain64 --key-size 512 /dev/sdX.
På Windows: aktiver BitLocker via Innstillinger eller manage-bde -on C: -RecoveryPassword, og lagre gjenopprettingsnøkkelen et trygt sted utenfor enheten.
På macOS: slå på FileVault under Systeminnstillinger > Personvern og sikkerhet, og noter gjenopprettingsnøkkelen.
Test at gjenopprettingsprosedyren faktisk fungerer før du stoler på oppsettet i produksjon.
Sett opp separat integritetskontroll, som sikker oppstart eller filsystem-sjekksummer, siden XTS alene ikke oppdager manipulering.
Roter krypteringsnøkler ved mistanke om kompromittering, ikke rutinemessig, siden XTS-nøkkelrotasjon krever full omkryptering av volumet.

For nettverkskryptering (AES-GCM)

Kartlegg hvilke tjenester som fortsatt tillater eldre TLS-versjoner eller CBC-baserte cipher-suiter.
Oppdater TLS-konfigurasjonen til å prioritere TLS_AES_256_GCM_SHA384 og TLS_AES_128_GCM_SHA256 i TLS 1.3.
Deaktiver eksplisitt eldre, sårbare suiter som bruker CBC-modus uten autentisert kryptering.
Test nonce-håndteringen i egne implementasjoner grundig, siden feil her er katastrofale, ikke gradvise.
Aktiver AES-GCM i IPsec/ESP-konfigurasjonen hvis VPN-infrastrukturen fortsatt bruker eldre kombinasjoner av kryptering og separat MAC.
Overvåk ytelsen etter overgangen, spesielt på eldre maskinvare uten AES-NI, der ChaCha20-Poly1305 kan være et bedre alternativ.

Fordeler og ulemper med AES-XTS

Oppsummert er AES-XTS et smalt, godt utformet verktøy for én jobb: rask, lengdebevarende kryptering av data som ligger stille på en fysisk lagringsenhet.

Fordeler:

Rask, og i vår egen test 19,5 % raskere enn AES-256-GCM ved 256-bit nøkler
Lengdebevarende, krypterte data tar akkurat like mye plass som originalen
Passer perfekt til faste sektorstørrelser på disker og SSD-er
Godkjent av både NIST og IEEE siden henholdsvis 2010 og 2007
Implementert som standard i alle store operativsystemer

Ulemper:

Ingen innebygd autentisering eller integritetssjekk
Krever separate mekanismer for å oppdage manipulering av data
Upraktisk for nettverksprotokoller med variabel datalengde
Trenger to nøkler å administrere i stedet for én
Begrenset til maksimalt 2^20 AES-blokker per dataenhet

Fordeler og ulemper med AES-GCM

AES-GCM er derimot bygget for et bredere formål: å beskytte data som beveger seg gjennom et miljø hvor en motstander aktivt kan forsøke å lese eller endre dem underveis.

Fordeler:

Autentisert kryptering, konfidensialitet og integritet i én operasjon
Støtter assosierte data som protokollheadere
Svært rask på moderne CPU-er med AES-NI og PCLMULQDQ
Standard i TLS 1.3, IPsec og moderne SSH-implementasjoner
Bredt støttet på tvers av nettlesere, servere og biblioteker

Ulemper:

Katastrofal sikkerhetssvikt hvis en nonce gjenbrukes med samme nøkkel
Legger til en autentiseringstag som utvider datastørrelsen
Merkbart tregere enn ChaCha20-Poly1305 på maskinvare uten AES-akselerasjon
Feilimplementert GHASH-håndtering kan introdusere sidekanalsvakheter
Ikke lengdebevarende, derfor uegnet for sektorbasert disklagring

Bruksanbefalinger: Hvilken modus passer hvor?

Valget mellom AES-XTS og AES-GCM bør aldri handle om hvilken som “er best” generelt, men om hvilket problem du faktisk løser. Under følger syv konkrete scenarioer hentet fra vanlige driftssituasjoner, med begrunnelse for hvorfor den ene moten passer bedre enn den andre i hvert tilfelle. Legg merke til at mønsteret gjentar seg: alt som ligger stille på en disk peker mot XTS, alt som beveger seg over et nettverk med en potensiell motstander til stede peker mot GCM.

Fulldiskkryptering på en bærbar PC: Bruk AES-XTS via BitLocker, FileVault eller LUKS2. Trusselen her er en stjålet eller mistet maskin, ikke aktiv manipulering under overføring.
Nettrafikk til og fra en webapplikasjon: Bruk AES-GCM gjennom TLS 1.3. Her er integritetssjekken i sanntid avgjørende, siden en angriper på nettverket aktivt kan forsøke å endre data underveis.
VPN- eller IPsec-tunneler mellom kontorer: Bruk AES-GCM i ESP-protokollen for å slippe å kjede sammen separate krypterings- og autentiseringsalgoritmer.
Krypterte backup-arkiver på eksterne disker: Bruk AES-XTS gjennom en VeraCrypt-kontainer, siden dataene ligger i ro og du uansett bør ha separate integritetssjekker av selve backupfilene.
Tjeneste-til-tjeneste-kommunikasjon i en mikrotjenestearkitektur: Bruk AES-GCM via mTLS, slik at hver forespørsel er både kryptert og autentisert individuelt.
Sensitive filer lagret lokalt på en Android-telefon: Stol på den innebygde filbaserte krypteringen, som allerede bruker AES-256-XTS for innhold og CBC-CTS for filnavn.
Objektlagring i skyen, som S3 eller Azure Blob: Bruk leverandørens innebygde server-side kryptering med kundestyrte nøkler via KMS, siden den underliggende moten uansett håndteres automatisk av tjenesten.

Et praktisk unntak fra tommelfingerregelen dukker opp i hybridscenarioer, som når en database krypterer data at rest med XTS-baserte diskvolumer, men samtidig eksponerer et API over TLS med GCM-baserte cipher-suiter. Da bruker du begge modusene samtidig i samme system, hver på sitt lag, og det er faktisk den vanligste og mest korrekte arkitekturen i moderne skyapplikasjoner: XTS beskytter dataene når serveren er av, GCM beskytter dem når de er på vei ut til en klient.

Vanlige feil og sikkerhetsfeller

Den vanligste feilen er å anta at kryptering automatisk betyr integritet. Et system som bare bruker AES-XTS uten noen form for autentisering av selve filsystemet, kan i teorien la en angriper med fysisk tilgang til disken gjøre kontrollerte endringer i spesifikke sektorer, selv om de ikke kan lese innholdet uten nøkkelen. Løsningen er lagdeling: kombiner diskkryptering med sikker oppstart og signerte systemimages, ikke stol på XTS alene som en fullstendig sikkerhetsgaranti.

En annen vanlig feil er å blande sammen nøkkelstyrke og driftssikkerhet. Et oppsett med AES-256-XTS er verdiløst hvis gjenopprettingsnøkkelen ligger i en tekstfil på skrivebordet eller sendes ukryptert på e-post til IT-avdelingen. Tilsvarende er et TLS-oppsett med moderne AES-GCM-cipher-suiter verdiløst hvis serveren fortsatt tillater nedgradering til TLS 1.0 eller 1.1 for eldre klienter. Kryptografien er sjelden det svakeste leddet, det er nesten alltid nøkkelhåndteringen og konfigurasjonen rundt den.

På GCM-siden er den klassiske fellen egen implementasjon av nonce-generering. Utviklere som bygger egne krypteringslag i stedet for å bruke godt utprøvde biblioteker, ender ofte opp med tellere som nullstilles ved omstart, tidsstempler med for lav oppløsning, eller tilfeldige verdier med for kort lengde til å garantere unikhet over tid. Alle disse feilene kan føre til nonce-gjenbruk, og konsekvensen er ikke en gradvis svekket sikkerhet, men et fullstendig sammenbrudd av konfidensialiteten for de berørte meldingene. Bruk alltid etablerte TLS-biblioteker fremfor å bygge egen AEAD-håndtering fra bunnen av.

Standardenes vei videre: Hva skjer i 2026 og fremover?

NIST jobber i 2026 med en revisjon av XTS-standarden gjennom et første offentlig utkast til SP 800-38E Revisjon 1. Utkastet oppdaterer referansen fra den gamle IEEE 1619-2007-teksten til den nyere IEEE 1619-2025-standarden, og presiserer blant annet omfanget av bruk, grenser for nøkkelbruk og rekkefølgen for ciphertext stealing. Dette er foreløpig et utkast til offentlig kommentering, ikke en vedtatt endring, så eksisterende implementasjoner av aes-xts-plain64 i LUKS2, BitLocker og FileVault påvirkes ikke før en endelig versjon er klar.

For GCM er bildet mer stabilt, men presset kommer fra en annen kant: overgangen til post-kvante kryptografi. Selve AES-GCM regnes fortsatt som trygt mot kvantedatamaskiner i overskuelig fremtid siden symmetrisk kryptering rammes langt mildere av Grovers algoritme enn asymmetriske nøkkelutvekslinger, men nøkkelutvekslingen som beskytter GCM-nøkkelen i TLS-håndtrykket erstattes gradvis med hybridløsninger som kombinerer klassiske og post-kvante algoritmer. Det endrer ikke selve GCM-moten, men det endrer hvordan nøkkelen kommer frem til den i utgangspunktet.

Det er verdt å understreke hva denne revisjonsprosessen faktisk betyr for deg som driftsansvarlig i praksis: ingenting umiddelbart. NIST-utkast til revisjon går normalt gjennom en lang periode med offentlig høring før de blir endelige, og produsenter av operativsystemer og krypteringsverktøy venter typisk til en standard er ferdigstilt før de endrer standardoppførsel. Både aes-xts-plain64 i LUKS2 og XTS-AES i BitLocker vil fortsette å fungere som i dag i lang tid fremover, uavhengig av hvordan revisjonsarbeidet konkluderer.

Konklusjon: Hvem vinner egentlig?

Spørsmålet “hvem vinner” er egentlig feil spørsmål å stille om AES-XTS og AES-GCM. De er ikke konkurrenter, de er verktøy laget for helt ulike jobber, og dataene i denne sammenligningen bekrefter det. AES-XTS var 19,5 % raskere i vår egen benchmark ved 256-bit nøkler, men den farten kommer utelukkende av at moten hopper over autentisering, noe som ville vært uakseptabelt i en nettverksprotokoll der en aktiv angriper kan endre trafikken din i sanntid. AES-GCM bruker de ekstra CPU-syklene på nettopp den jobben, og det er derfor RFC 8446 gjør det til standard i TLS 1.3.

Vår klare anbefaling: bruk AES-XTS for alt som ligger i ro på en fysisk disk, fra bærbare PC-er til backup-disker, og lag integritet gjennom andre lag som sikker oppstart. Bruk AES-GCM for alt som beveger seg over et nettverk der en tredjepart kan forsøke å manipulere trafikken, fra TLS-tilkoblinger til VPN-tunneler. Det er ikke et spørsmål om hvilken algoritme som er “sterkest”, begge bygger på samme AES-kjerne og samme nøkkellengder, men om hvilken jobb du faktisk skal løse. For mer om grunnlaget begge modusene deler, se vår oversikt over kryptografi, hashfunksjoner og digital tillit.

Hvis du sitter igjen med bare én ting fra denne sammenligningen, la det være dette: spør aldri “hvilken modus er raskest” før du har spurt “hva slags data beskytter jeg, og hvem er trusselen”. Et bortkommet backup-lager har en helt annen trusselmodell enn en aktiv nettverksforbindelse med en angriper i midten. Match moten til trusselen, ikke til benchmark-tallene alene, så havner du riktig hver gang, uavhengig av hvilke prosentvise forskjeller en test som denne måtte vise.

Ofte stilte spørsmål

Kan jeg bruke AES-GCM til diskkryptering i stedet for AES-XTS?
Teknisk sett er det mulig, men det er upraktisk i stor skala. GCM utvider datastørrelsen med en autentiseringstag per blokk, noe som ikke passer med faste sektorstørrelser, og GCM krever strengt unike nonces, noe som er vanskelig å garantere over et helt diskvolums levetid med tilfeldig skriving. Enkelte spesialiserte løsninger bruker likevel AEAD-moduser for lagring i nisjetilfeller, men da typisk med en egen datastruktur bygget rundt formatet, ikke som en direkte erstatning for XTS i eksisterende filsystemer.

Kan jeg bruke AES-XTS i TLS?
Nei, ingen større TLS-implementasjon støtter XTS som cipher-suite. TLS trenger autentisert kryptering av data med variabel lengde, og det er nøyaktig det XTS ikke er designet for å levere.

Er AES-XTS mindre sikkert enn AES-GCM fordi det mangler autentisering?
Ikke nødvendigvis mindre sikkert, men det løser et annet problem. Konfidensialiteten i XTS er like sterk som i GCM for samme nøkkellengde. Forskjellen er at XTS forutsetter at du legger integritetssjekk på et annet lag, mens GCM har den innebygd. Så lenge disklagringssystemet ditt faktisk har et slikt annet lag, for eksempel sikker oppstart eller filsystem-sjekksummer, er den reelle sikkerheten sammenlignbar for det bruksområdet moten er designet for.

Hvor mye raskere er AES-XTS enn AES-GCM i praksis?
I vår egen test med OpenSSL 3.0.13 på AES-NI-maskinvare var AES-256-XTS 19,5 % raskere enn AES-256-GCM, og AES-128-XTS var 6,2 % raskere enn AES-128-GCM, målt ved 16 384 byte blokkstørrelse.

Hva skjer hvis en GCM-nonce gjenbrukes?
Konsekvensen er alvorlig. Gjenbruk av samme nonce med samme nøkkel kan la en angriper avdekke deler av autentiseringsnøkkelen og i verste fall forfalske fremtidige meldinger, ifølge NIST sitt eget utviklingsmateriale for 800-38-serien.

Bruker skylagringstjenester som AWS S3 og Azure Blob AES-XTS eller AES-GCM?
Dette varierer med leverandør og implementasjonsdetaljer som ikke alltid er offentliggjort i detalj. Det som er sikkert, er at nøkkelhåndteringen skjer gjennom tjenester som AWS KMS eller Google Cloud KMS, og at kostnaden ligger i nøkkelbruken, ikke i selve krypteringsalgoritmen.

Er ChaCha20-Poly1305 et bedre alternativ enn både AES-XTS og AES-GCM?
Det kommer an på maskinvaren. I vår test var ChaCha20-Poly1305 klart tregest på en AES-NI-utstyrt server, men på eldre eller enkle ARM-brikker uten AES-akselerasjon snur bildet seg ofte, noe som er grunnen til at Android bruker en ChaCha20-basert løsning som fallback på slik maskinvare.

Kommer NIST til å oppdatere AES-XTS-standarden i 2026?
Et første offentlig utkast til en revisjon er publisert, men det er ikke vedtatt ennå. Utkastet oppdaterer referansen til IEEE 1619-2025 og presiserer flere grenser, men eksisterende implementasjoner i BitLocker, LUKS2 og FileVault berøres ikke før en endelig versjon eventuelt vedtas.