AES-kryptering / -dekryptering

Blockchiffret. AES (Rijndael-konstruktionen, standardiserad av NIST 2001 som FIPS 197) krypterar exakt 16 byte åt gången. Nyckellängden — 16, 24 eller 32 byte — väljer AES-128, -192 eller -256 och antalet interna rundor (10, 12, 14). Varje runda blandar blocket med rundnycklar som härletts ur nyckeln genom substitutionstabeller, radförskjutningar och kolumnblandning. Ingen praktisk attack bryter själva chiffret: de verkliga felen är nästan alltid läges-, IV- eller nyckelhanteringsmisstag, vilket resten av sidan handlar om.

Varför alls ett läge? För att meddelanden sällan är 16 byte. Läget limmar ihop blockkrypteringarna: ECB krypterar bara block var för sig; CBC XOR:ar varje block med föregående chiffertext; CTR krypterar en räknare och XOR:ar den med data som ett strömchiffer; GCM bygger på CTR och lägger till en autentiseringstagg. AES förblir detsamma — läget ändrar allt om vilka garantier man får.

Nycklar och lösenord. En AES-nyckel är 16, 24 eller 32 slumpmässiga byte. Ett lösenord skrivet av en människa är inte det: sidans lösenordsalternativ härleder en korrekt nyckel med PBKDF2-HMAC-SHA256 (600 000 iterationer som standard, OWASP 2023 som grund — se HMAC-generatorn för detaljer om KDF). Använd aldrig en lösenordssträng direkt som AES-nyckel: dess entropi är en liten del av längden.

Läge	IV / nonce	Integritet	Anteckningar
GCM	12 byte, unik per meddelande	Ja — 96–128-bitars tagg	AEAD: den rekommenderade standarden överallt (TLS 1.3, SSH, filformat). Accepterar även AAD.
CBC	16 byte, oförutsägbar	Nej	PKCS#7-utfyllnad; klassiskt men kräver en MAC bredvid. Utfyllnadsorakelfel är den klassiska CBC-fallgropen.
CTR	16-byte initial räknare	Nej	Ingen utfyllnad, strömliknande, direktåtkomst; återanvänd nonce under en nyckel läcker klartext XOR klartext.
ECB	ingen	Nej	Identiska block → identisk chiffertext. Pingvindemonstrationen för ECB. Endast för kompatibilitet.

IV-regler i ett stycke. IV:n är inte hemlig — skicka den tillsammans med chiffertexten — men dess unikhetskrav skiljer sig: CBC kräver en oförutsägbar IV; GCM och CTR kräver bara att samma nonce aldrig återanvänds med samma nyckel (återanvändning av nonce i GCM är värre: den läcker autentiseringsnyckeln). Sidans knapp för slumpmässig IV använder webbläsarens säkra slumpgenerator; knappen för alla nollor finns för att återskapa testvektorer, inte för riktiga meddelanden.

Utfyllnad. CBC och ECB behöver hela block, så PKCS#7-utfyllnad lägger till 1 till 16 byte, var och en lika med utfyllnadens längd. Därför växer CBC-chiffertexter med upp till 16 byte, och därför misslyckas dekryptering med fel nyckel oftast med ett utfyllnadsfel. CTR och GCM är strömliknande och behöver ingen utfyllnad — chiffertextens längd är exakt lika med klartextens (prova exemplet i CTR-läget: 43 byte in, 43 byte ut).

CFB och OFB (de två återstående klassiska lägena) finns inte på den här sidan: de är strömliknande som CTR men utan fördel jämfört med den, och lever mest kvar i gamla protokoll.

Autentiserad kryptering. GCM = CTR-kryptering + en GHASH-autentiserare över chiffertexten, IV:n och AAD. Utdatataggen är ett fingeravtryck av allt: ändras en enda bit i chiffertexten, IV:n eller AAD stämmer inte taggen längre, så mottagaren kan bevisa att meddelandet är intakt och kommer från en nyckelinnehavare. CBC+HMAC uppnår samma sak först om man sätter ihop det rätt (encrypt-then-MAC) — GCM gör det rätt i konstruktionen.

AAD. Ytterligare autentiserad data skickas i klartext men täcks av taggen: protokollhuvuden, filnamn, algoritmidentifierare. Mottagaren måste ange identiska AAD-byte, annars misslyckas taggkontrollen — det är själva poängen.

Taggens längd. Den förvalda 128-bitarstaggen är rekommendationen; kortare taggar (96–120 bitar) byter förfalskningsmotstånd mot storlek. Under 96 bitar försämras GCM:s säkerhetsbevis snabbt, varför sidan stannar där.

Nonce-katastrofen. Att återanvända en 12-byte GCM-nonce under samma nyckel läcker XOR:en av klartexterna i de två meddelandena och autentiseringsundernyckeln — därefter går det att förfalska alla framtida meddelanden under den nyckeln. System som inte kan garantera unikhet använder varianter som tål felanvändning av nonce (AES-GCM-SIV, RFC 8452).

Den första raden är det klassiska enblocksexemplet från FIPS 197; resten har tagits fram av en oberoende nativ implementering (OpenSSL via Node.js) och verifierats på nytt med sidans egna motorer. Klistra in nyckeln, IV:n och indatan på sidan för att återskapa varje rad.

Fall	Indata	Förväntad utdata
AES-128 enblock (i 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, samma 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 (samma indata som CBC ovan)	43-byte plaintext → 43-byte ciphertext	e9d2cdb9f661359178ed366dfa3a4671f8e20efd723f090eb7d1d524d480fd3c

• Att använda ECB eftersom det inte behöver någon IV. Bekvämligheten är fällan: blockmönster läcker rakt in i chiffertexten (krypterar man en bitmapp syns bilden fortfarande). ECB är acceptabelt bara för enstaka block eller exakt 16-byte slumpmässiga nycklar — i praktiken aldrig av eget val.
• Återanvändning av nonce/IV. Med GCM eller CTR under samma nyckel är det det enda misstag som bryter allt på en gång. Räknarbaserade system (sidans knapp för slumpmässig IV) finns för att göra det omöjligt.
• Att behandla IV:n som hemlig. Det är den inte. Lagra eller skicka den tillsammans med chiffertexten. Att gömma den ger ingenting och lockar till återanvändning.
• Att använda ett lösenord som nyckel. "hunter2hunter2hunter2hunter2" är 32 byte men inte 256 bitar entropi — det är ett ordboksord med utfyllnad. Härled med PBKDF2 (inbyggt på sidan) eller generera en slumpmässig nyckel.
• Att anta att CBC upptäcker manipulation. Vänder man en bit i CBC-chiffertexten lyckas dekrypteringen tyst med skadad klartext. Endast GCM:s tagg (eller en explicit HMAC) gör manipulation synlig.
• Att jämföra GCM-chiffertexter för likhet. Med slumpmässiga nonces krypteras samma klartext olika varje gång — det är en egenskap. Deterministisk kryptering är ett annat, specialiserat verktyg.

Är AES-128 fortfarande säkert, eller behövs 256? Båda är säkra mot realistiska angripare; de bästa kända attackerna minskar marginalen bara obetydligt. AES-256 är främst viktigt för långsiktiga hemligheter och för framtida kvantdatorer (Grovers algoritm halverar nyckelstyrkan, vilket lämnar AES-256 på ungefär 128-bitars motsvarighet).

Varför kan inte openssl enc göra GCM? Kommandot enc är äldre än AEAD och saknar sätt att bära en tagg; OpenSSL 3.3 lade i stället till ett särskilt kommando, aesgcm. GCM-utdata på den här sidan håller taggen på en egen rad, så att båda kan flyttas explicit.

Vad är nyckelinpackning (AES-KW)? Ett specialiserat läge för att kryptera andra nycklar i fasta 64-bitarsblock med en egen integritetskontroll. Det erbjuds inte här, eftersom indata och utdata är nyckelformade, inte meddelandeformade — felanvändning är normen.

Varför är min CTR-chiffertext lika lång som klartexten, men CBC:s längre? CTR och GCM är strömliknande (ingen utfyllnad); CBC/ECB fyller ut till ett helt 16-byteblock med PKCS#7. Längdskillnaden är avsiktlig och inget fel.

Kan jag dekryptera något som krypterats någon annanstans? Ja, om läget, nyckeln och IV:n (och för GCM även taggen) är exakt kända. Utdatarader på den här sidan registrerar alla dessa precis, så att parametrar kan flyttas mellan verktyg — OpenSSL-rutan ovan visar motsvarande kommandoraderna.