AES-kryptering / -dekryptering — GCM, CBC, CTR og ECB i nettleseren
AES-kryptering / -dekryptering
Krypter eller dekrypter med AES-128, AES-192 eller AES-256 (FIPS 197) i GCM (autentisert kryptering), CBC, CTR eller ECB-modus. Nøkler er rå heks- eller Base64-byte, eller utledet fra et passord med PBKDF2-HMAC-SHA256. GCM støtter AAD og viser autentiseringstaggen separat; CBC-, CTR- og ECB-utdata er kompatible med OpenSSL enc. For hasher, se Hash-generatoren, for nøklede MAC-er HMAC-generatoren, og for eldre chiffer siden for eldre chiffer i denne familien. Kjører helt lokalt — nøkler og klartekst forlater aldri fanen. Filer opptil 200 MB.
Alt som skrives inn her blir i denne fanen — men det betyr ikke det samme som «trygt for produksjonshemmeligheter». Nettleserminnet, utvidelser og folk som titter over skulderen ser det man limer inn. Bruk denne siden til å lære, verifisere og teste interoperabilitet, ikke til å håndtere ekte kundedata.
Retning:Modus:Utdata:
GCM = AES-GCM med 12-byte nonce og 128-bit autentiseringstagg (AEAD: konfidensialitet + integritet). Standard når sikkerhet er målet.
Nøkkel(rå byte: 16, 24 eller 32 byte = AES-128/192/256; lengden på det man limer inn avgjør)
Heks tåler mellomrom, kolon og 0x-prefikser.
Salt (heks, 8–16 byte):
Iterasjoner:Nøkkelstørrelse:
Saltet følger med chifferteksten — den som dekrypterer trenger samme passord, salt, iterasjonsantall og nøkkelstørrelse. OWASP anbefaler minst 600 000 PBKDF2-HMAC-SHA256-iterasjoner.
IV / nonce(GCM: 12 byte; CBC/CTR: 16 byte — heks)
Gjenbruk aldri en nonce under samme nøkkel i GCM eller CTR.
AAD(tilleggsdata med autentisering — autentisert, men ikke kryptert; valgfritt)
Taglengde:
Autentiseringstagg(heks, slik denne siden skriver den ut ved kryptering — nødvendig for dekryptering)
Plaintext text (the data to encrypt, UTF-8 encoded)
Velg en fil eller dra og slipp den her Filen leses lokalt i biter på 8 MB; ingenting lastes opp. Opptil 200 MB.
Ciphertext (én linje: modus, nøkkelstørrelse, verdi; parametere på linjene under)
Parameterlinjene registrerer den eksakte tolkningen av nøkkelen, IV-en, AAD-størrelsen og taggen, slik at et kopiert resultat alltid kan reproduseres på en annen maskin.
Hvilken modus bør man velge? GCM er standardsvaret: den krypterer og autentiserer — taggeringen gjør manipulering synlig (prøv å dekryptere med en snudd tagg-byte, så avviser siden det). CBC skjuler blokkmønstre, men gir ingen integritet; kombiner den med en HMAC (se HMAC-generatoren) hvis man må bruke den. CTR gjør AES om til en strømchiffer — ingen utfylling, men en gjenbrukt nonce under samme nøkkel er katastrofal i både CTR og GCM. ECB finnes her kun for kompatibilitet og undervisning: identiske klartekstblokker krypteres til identiske chifferblokker (den berømte ECB-pingvinen).
OpenSSL-interoperabilitet — CBC- og CTR-utdata fra denne siden (PKCS#7-utfylling, rå nøkkel) fungerer toveis med kommandolinjen openssl enc: openssl enc -aes-256-cbc -K <64-hex-nøkkel> -iv <32-hex-iv> -in msg.txt -out msg.enc openssl enc -d -aes-256-cbc -K <nøkkel> -iv <iv> -in msg.enc -out msg.txt Det samme gjelder -aes-128-cbc, -aes-192-cbc og -aes-256-ctr (16-byte IV = startblokken for telleren). Merk at openssl encikke støtter GCM — bruk denne siden, eller openssl aesgcm fra OpenSSL 3.3+, for autentisert kryptering.
Trenger man i stedet den kinesiske nasjonale chifferen? SM4 (GB/T 32907-2016) — blokkchifferet som er påbudt i kinesisk kommersiell kryptografi, med samme 128-bit blokk- og nøkkelstørrelse som AES, men med egen nøkkelplan og egen S-boks — kjører på sin egen side i ECB- og CBC-modus: SM4-kryptering / -dekryptering. Resten av SM-familien ligger der også: SM3 (hash), SM2 (offentlig nøkkel) og SM9 (identitetsbasert kryptografi).
Selvtest Kjører sidens motorer mot uavhengige ankerverdier: kjente svarvektorer for alle fire modi (generert av en uavhengig native implementasjon), GCM-taggvektorer med og uten AAD, krysskontroll av WebCrypto-motoren mot den rene JS-AES-motoren, GCM-rundtur og negative tester (manipulert tagg og feil nøkkel må feile). Ingenting sendes noen vei.
AES-kryptering forklart fra grunnen
Kort sagt: AES er den verdensomspennende standarden for blokkchiffer — den blander 16-byte-blokker under en nøkkel på 128, 192 eller 256 bit — og modusen man kjører den i (GCM, CBC, CTR, ECB) avgjør hvordan blokkene kjedes sammen, hva IV-en er til for, og om manipulering kan oppdages. Velg GCM med mindre det finnes en grunn til å la være.
Hva AES selv er (FIPS 197)
Blokkchifferet. AES (Rijndael-designet, standardisert av NIST i 2001 som FIPS 197) krypterer nøyaktig 16 byte om gangen. Nøkkellengden — 16, 24 eller 32 byte — velger AES-128, -192 eller -256 og antall interne runder (10, 12, 14). Hver runde blander blokken med rundenøkler avledet fra nøkkelen, gjennom substitusjonstabeller, radforskyvninger og kolonneblandinger. Ingen praktisk angrep bryter selve chifferet: de reelle feilene er nesten alltid feil i modus, IV eller nøkkelhåndtering, og det er det resten av denne siden handler om.
Hvorfor en modus i det hele tatt? Fordi meldinger sjelden er 16 byte. Modusen binder blokkkrypteringene sammen: ECB krypterer blokker uavhengig av hverandre; CBC XOR-er hver blokk med forrige chiffertekst; CTR krypterer en teller og XOR-er den med dataene som en strømchiffer; GCM bygger på CTR og legger til en autentiseringstagg. AES er den samme — modusen endrer alt om garantiene man får.
Nøkler og passord. En AES-nøkkel er 16, 24 eller 32 tilfeldige byte. Et menneskelig passord er ikke det: denne sidens passordalternativ utleder en skikkelig nøkkel med PBKDF2-HMAC-SHA256 (600 000 iterasjoner som standard, OWASPs grunnlinje fra 2023 — se HMAC-generatoren for detaljer om KDF). Bruk aldri en passordstreng direkte som AES-nøkkel: entropien er en liten brøkdel av lengden.
De fire modusene sammenlignet
Modus
IV / nonce
Integritet
Merknader
GCM
12 byte, unik per melding
Ja — 96..128-bit tagg
AEAD: standardvalget overalt (TLS 1.3, SSH, filformater). Godtar også AAD.
CBC
16 byte, uforutsigbar
Nei
PKCS#7-utfylling; klassisk, men trenger en MAC ved siden av. Utfyllingsorakel-feil er den klassiske CBC-fellen.
CTR
16-byte startteller
Nei
Ingen utfylling, strømliknende, tilfeldig tilgang; gjenbruk av nonce under én nøkkel lekker klartekst XOR klartekst.
ECB
ingen
Nei
Identiske blokker → identisk chiffertekst. ECB-pingvin-demonstrasjonen. Kun for kompatibilitet.
IV-regler i ett avsnitt. IV-en er ikke hemmelig — send den sammen med chifferteksten — men kravene til unikhet er forskjellige: CBC krever en uforutsigbar IV; GCM og CTR krever bare at samme nonce aldri gjenbrukes med samme nøkkel (gjenbruk av nonce i GCM er verre: den lekker autentiseringsnøkkelen). Denne sidens knapp for tilfeldig IV bruker nettleserens sikre tilfeldighetsgenerator; knappen for bare nuller finnes for å reprodusere testvektorer, ikke for ekte meldinger.
Utfylling. CBC og ECB trenger hele blokker, så PKCS#7-utfylling legger til 1..16 byte, og hver av dem er lik utfyllingens lengde. Derfor vokser CBC-chiffertekster med opptil 16 byte, og derfor feiler dekryptering med feil nøkkel vanligvis med en utfyllingsfeil. CTR og GCM er strømliknende og trenger ingen utfylling — chifferteksten har nøyaktig samme lengde som klarteksten (prøv eksempelet i CTR-modus: 43 byte inn, 43 byte ut).
CFB og OFB (de to gjenværende klassiske modusene) er ikke implementert på denne siden: de er strømliknende som CTR, men uten fordel fremfor den, og lever mest videre i gamle protokoller.
Hva GCM legger til (AEAD, tagger, AAD)
Autentisert kryptering. GCM = CTR-kryptering + en GHASH-autentikator over chifferteksten, IV-en og AAD. Utdatataggen er et fingeravtrykk av alt: endres én bit i chifferteksten, IV-en eller AAD, stemmer ikke taggen lenger, slik at mottakeren kan bevise at meldingen er intakt og fra en nøkkelholder. CBC+HMAC oppnår det samme bare dersom man setter det sammen riktig (kryptere-så-MAC) — GCM gjør det riktig ved konstruksjon.
AAD. Tilleggsdata med autentisering sendes i klartekst, men dekkes av taggen: protokollheadere, filnavn, algoritmeidentifikatorer. Mottakeren må oppgi nøyaktig de samme AAD-bytene, ellers feiler taggsjekken — det er poenget.
Taglengde. Den vanlige 128-bit-taggen er anbefalingen; kortere tagger (96..120 bit) bytter forfalskningsmotstand mot størrelse. Under 96 bit svekkes sikkerhetsbevisene for GCM raskt, og derfor stopper denne siden der.
Nonce-katastrofen. Gjenbruk av en 12-byte GCM-nonce under samme nøkkel lekker XOR av klarteksten til de to meldingene og autentiseringsundernøkkelen — deretter er forfalskninger mulig for alle fremtidige meldinger under den nøkkelen. Systemer som ikke kan garantere unikhet bruker nonce-misbruk-motstandsdyktige varianter (AES-GCM-SIV, RFC 8452).
Ankerverdier — reproduser dem på denne siden
Den første raden er det kjente FIPS 197-eksempelet med én blokk; resten er generert av en uavhengig native implementasjon (OpenSSL via Node.js) og verifisert på nytt i denne sidens motorer. Lim inn nøkkel, IV og inndata på siden for å reprodusere hver linje.
Store/små bokstaver
Inndata
Forventet utdata
AES-128 enkeltblokk (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
Å bruke ECB fordi den ikke krever IV. Bekvemmeligheten er fellen: blokkmønstre lekker rett inn i chifferteksten (krypterer man et bitmap, ser man fortsatt bildet). ECB er bare akseptabel for enkeltblokker eller nøyaktig 16-byte tilfeldige nøkler — i praksis aldri et bevisst valg.
Gjenbruk av nonce/IV. Med GCM eller CTR under én nøkkel er dette den ene feilen som ødelegger alt på en gang. Tellerbaserte systemer (denne sidens knapp for tilfeldig IV) finnes for å gjøre det umulig.
Å behandle IV-en som hemmelig. Det er den ikke. Lagre eller send den sammen med chifferteksten. Å skjule den gir ingenting og frister til gjenbruk.
Å bruke et passord som nøkkel."hunter2hunter2hunter2hunter2" er 32 byte, men ikke 256 bit entropi — det er et ordboksord med utfylling. Utled med PBKDF2 (innebygd på denne siden) eller generer en tilfeldig nøkkel.
Å anta at CBC oppdager manipulering. Snu en bit i CBC-chifferteksten, og dekrypteringen «lykkes» med stille ødelagt klartekst. Bare GCM-taggen (eller en eksplisitt HMAC) gjør manipulering synlig.
Å sammenligne GCM-chiffertekster for likhet. Med tilfeldige nonces krypteres samme klartekst annerledes hver gang — det er en egenskap. Deterministisk kryptering er et annet, spesialisert verktøy.
Ofte stilte spørsmål
Er AES-128 fortsatt trygt, eller må man bruke 256? Begge er sikre mot realistiske angripere; de kjente angrepene reduserer bare en liten del av marginen. AES-256 er først og fremst viktig for langtidshemmeligheter og post-kvantekomfort (Grovers algoritme halverer nøkkelstyrken, slik at AES-256 blir på ca. 128-bit ekvivalent).
Hvorfor gjør ikke openssl enc GCM? Kommandoen enc er eldre enn AEAD og har ingen måte å bære en tagg på; OpenSSL 3.3 la i stedet til en egen kommando, aesgcm. GCM-utdataene på denne siden har taggen på en egen linje, slik at begge kan flyttes eksplisitt.
Hva er nøkkelinnpakning (AES-KW)? En spesialisert modus for kryptering av andre nøkler i faste 64-bit-biter med en egen integritetssjekk. Den tilbys ikke her, fordi inn- og utdata er nøkkelformet, ikke meldingsformet — feilbruk er normen.
Hvorfor har CTR-chifferteksten samme lengde som klarteksten, mens CBC-chifferteksten er lengre? CTR og GCM er strømliknende (ingen utfylling); CBC/ECB fyller opp til en hel 16-byte-blokk med PKCS#7. Lengdeforskjellen er bevisst, ikke en feil.
Kan man dekryptere noe som er kryptert et annet sted? Ja, dersom man kjenner nøyaktig modus, nøkkel og IV (og for GCM taggen). Utdatalinjene på denne siden registrerer alt dette presist, slik at parametrene kan overføres mellom verktøy — OpenSSL-boksen over viser de tilsvarende kommandolinjene.
