AES-kryptering / -dekryptering

Blokchifferen. AES (Rijndael-designet, standardiseret af NIST i 2001 som FIPS 197) krypterer præcis 16 byte ad gangen. Nøglelængden — 16, 24 eller 32 byte — vælger AES-128, -192 eller -256 og antallet af interne runder (10, 12, 14). Hver runde blander blokken med rundenøgler udledt af nøglen gennem substitutionstabeller, rækkeforskydninger og kolonneblandinger. Ingen praktisk angreb bryder selve chifferen: de virkelige fejl skyldes næsten altid tilstand, IV eller nøglehåndtering, og det er det resten af denne side handler om.

Hvorfor overhovedet en tilstand? Fordi beskeder sjældent er 16 byte. Tilstanden limer blokkrypteringer sammen: ECB krypterer blokke uafhængigt; CBC XOR'er hver blok med den forrige chiffertekst; CTR krypterer en tæller og XOR'er den med dataene som en strømchiffer; GCM bygger på CTR og tilføjer et autentificeringstag. AES forbliver det samme — tilstanden ændrer alt ved de garantier, man får.

Nøgler og adgangskoder. En AES-nøgle er 16, 24 eller 32 tilfældige bytes. En menneskelig adgangskode er ikke det: sidens adgangskodeindstilling udleder en ordentlig nøgle med PBKDF2-HMAC-SHA256 (600.000 iterationer som standard, OWASP 2023-basislinjen — se HMAC-generatoren for KDF-detaljerne). Brug aldrig en adgangskodestreng direkte som AES-nøgle: dens entropi er en lille brøkdel af længden.

Tilstand	IV / nonce	Integritet	Noter
GCM	12 byte, unik pr. besked	Ja — 96..128-bit tag	AEAD: den anbefalede standard overalt (TLS 1.3, SSH, filformater). Accepterer også AAD.
CBC	16 byte, uforudsigelig	Nej	PKCS#7-opstopning; klassisk, men kræver en MAC ved siden af. Padding-oracle-fejl er den klassiske CBC-fælde.
CTR	16-byte startællertal	Nej	Ingen opstopning, strømlignende, direkte adgang; genbrug af nonce under én nøgle lækker klartekst XOR klartekst.
ECB	ingen	Nej	Identiske blokke → identisk chiffertekst. ECB-pingvin-demonstrationen. Kun til kompatibilitet.

IV-regler i ét afsnit. IV'en er ikke hemmelig — send den sammen med chifferteksten — men kravene til dens unikhed er forskellige: CBC kræver en uforudsigelig IV; GCM og CTR kræver blot, at samme nonce aldrig genbruges med samme nøgle (genbrug af nonce i GCM er værre: det lækker autentificeringsnøglen). Sidens knap til tilfældig IV bruger browserens sikre RNG; knappen Kun nuller findes til at gengive testvektorer, ikke til rigtige beskeder.

Opstopning. CBC og ECB kræver hele blokke, så PKCS#7-opstopning tilføjer 1..16 byte, som hver er lig med opstopningslængden. Derfor vokser CBC-chiffertekster med op til 16 byte, og derfor fejler dekryptering med en forkert nøgle normalt med en opstopningsfejl. CTR og GCM er strømlignende og kræver ingen opstopning — chifferteksten har præcis samme længde som klarteksten (prøv eksemplet i CTR-tilstand: 43 byte ind, 43 byte ud).

CFB og OFB (de to resterende klassiske tilstande) er ikke implementeret på denne side: de er strømlignende som CTR, men uden fordel frem for den, og findes mest i gamle protokoller.

Autentificeret kryptering. GCM = CTR-kryptering + en GHASH-autentificator over chifferteksten, IV'en og AAD. Outputtagget er et fingeraftryk af alt: ændres én bit i chifferteksten, IV'en eller AAD, passer tagget ikke længere, så modtageren kan bevise at beskeden er intakt og stammer fra en nøgleindehaver. CBC+HMAC opnår det samme, men kun hvis det sættes korrekt sammen (encrypt-then-MAC) — GCM gør det rigtigt ved konstruktion.

AAD. Ekstra autentificerede data sendes i klartekst, men er dækket af tagget: protokolheadere, filnavne, algoritmeidentifikatorer. Modtageren skal levere de nøjagtigt samme AAD-bytes, ellers fejler tagkontrollen — det er pointen.

Taglængde. Det som standard anbefalede 128-bit tag er anbefalingen; kortere tags (96..120 bit) bytter forfalskningsmodstand mod størrelse. Under 96 bit forringes GCM-sikkerhedsbeviserne hurtigt, og derfor stopper siden der.

Nonce-katastrofen. Genbrug af en 12-byte GCM-nonce under samme nøgle lækker XOR'en af de to klartekster og autentificeringsundernøglen — hvorefter forfalskninger er mulige for alle fremtidige beskeder under den nøgle. Systemer, der ikke kan garantere unikhed, bruger nonce-misbrugsbestandige varianter (AES-GCM-SIV, RFC 8452).

Den første række er det berømte FIPS 197-eksempel med én blok; resten er genereret af en uafhængig native implementation (OpenSSL via Node.js) og verificeret igen i sidens motorer. Indsæt nøgle, IV og input på siden for at gengive hver linje.

Tilfælde	Input	Forventet output
AES-128 enkelt blok (FIPS 197-stil)	key 000102..0f, plaintext 00112233..ff	69c4e0d86a7b0430d8cdb78070b4c55a
AES-128-GCM	key 000102..0f, IV 606162..6b, plaintext 0011..ef ×2	ct 275f095bedfda377063fee326128892188377b410698ed03a022b9971bb4bdbe, tag 87ea7770714048977de2fd8dac645ecf
AES-256-GCM, samme men med AAD deadbeef	key 000102..1f	ct eacab966ff15e518f48f5390be502fbc2756ccee0dcfff36a282c50bf5593ae7, tag aead900e895c88252d0388d7aefce5c8
AES-256-CBC	key 000102..1f, IV 101112..1f, plaintext 0011..ef ×2	0e2392dd6f690b44a5a1b4fdff3b7f83cb9ab59d9900119cc5f83e062d95fb643b1a94b514ea2f3b95f84c900b5c98a8
AES-256-CTR (samme input som CBC ovenfor)	43-byte plaintext → 43-byte ciphertext	e9d2cdb9f661359178ed366dfa3a4671f8e20efd723f090eb7d1d524d480fd3c

• At bruge ECB, fordi den ikke kræver en IV. Bekvemmeligheden er fælden: blokmønstre lækker direkte ind i chifferteksten (krypterer man et bitmap, kan billedet stadig ses). ECB er kun acceptabel for enkeltblokke eller nøjagtigt 16-byte tilfældige nøgler — i praksis aldrig et bevidst valg.
• Genbrug af nonce/IV. Med GCM eller CTR under samme nøgle er det den ene fejl, der knækker alt på én gang. Tællerbaserede systemer (sidens knap til tilfældig IV) findes for at gøre det umuligt.
• At behandle IV'en som hemmelig. Det er den ikke. Gem eller send den sammen med chifferteksten. At skjule den gør ingen forskel og fristes til genbrug.
• At bruge en adgangskode som nøgle. "hunter2hunter2hunter2hunter2" er 32 byte, men ikke 256 bit entropi — det er et ordbogsord med fyld. Udled nøglen med PBKDF2 (indbygget på denne side) eller generér en tilfældig nøgle.
• At antage at CBC opdager manipulation. Vend en bit i CBC-chifferteksten, og dekrypteringen "lykkes" med stille beskadiget klartekst. Kun GCM-tagget (eller en eksplicit HMAC) gør manipulation synlig.
• At sammenligne GCM-chiffertekster for lighed. Med tilfældige nonces krypteres samme klartekst forskelligt hver gang — det er en egenskab. Deterministisk kryptering er et andet, specialiseret værktøj.

Er AES-128 stadig sikker, eller er 256 nødvendig? Begge er sikre over for realistiske angribere; de bedste kendte angreb reducerer kun en brøkdel af marginen. AES-256 betyder mest for langtidshemmeligheder og post-kvante-sikkerhed (Grovers algoritme halverer nøglestyrken, så AES-256 ligger på ca. 128-bit-ækvivalent).

Hvorfor kan openssl enc ikke GCM? Kommandoen enc er ældre end AEAD og har ingen måde at bære et tag på; OpenSSL 3.3 tilføjede i stedet en særskilt kommando aesgcm. GCM-outputtet på denne side holder tagget på en egen linje, så både tag og ciphertext kan flyttes eksplicit.

Hvad er nøgle-indpakning (AES-KW)? En specialiseret tilstand til kryptering af andre nøgler i faste 64-bit bidder med sin egen integritetskontrol. Den tilbydes ikke her, fordi input og output er nøgleformede og ikke meddelelsesformede — fejlbrug er normen.

Hvorfor har min CTR-chifertekst samme længde som klarteksten, mens CBC-teksten er længere? CTR og GCM er strømlignende (ingen opstopning); CBC/ECB udfylder til en hel 16-byte blok med PKCS#7. Længdeforskellen er bevidst og ikke en fejl.

Kan man dekryptere noget, der er krypteret et andet sted? Ja, hvis den præcise tilstand, nøglen og IV (og for GCM tagget) kendes. Outputlinjerne på denne side registrerer alle disse præcist, så parametrene kan flyttes mellem værktøjer — OpenSSL-boksen ovenfor viser de tilsvarende kommandolinjer.