AES titkosítás / visszafejtés

Titkosítás vagy visszafejtés AES-128, AES-192 vagy AES-256 módszerrel (FIPS 197) GCM (hitelesített titkosítás), CBC, CTR vagy ECB módban. A kulcsok nyers hex vagy Base64 bájtok, vagy jelszóból származtatottak PBKDF2-HMAC-SHA256-tal. A GCM támogatja az AAD-t, és a hitelesítőcímkét külön mutatja; a CBC/CTR/ECB kimenetei az OpenSSL enc-kompatibilisek. Kivonatokhoz a következő oldal ad részletet: Hash-generátort, kulcsos MAC-ekhez a HMAC-generátort, régi titkosítókhoz ebben a családban a Régi titkosítók oldalt.
Teljes egészében helyben fut — a kulcsok és a nyílt szöveg soha nem hagyják el a lapot. Fájlok legfeljebb 200 MB.
Minden, ami ide kerül, ebben a lapban marad — de ez nem azonos azzal, hogy „biztonságos éles titkokhoz”. A böngésző memóriája, a bővítmények és a válla fölött leső szemek látják, amit beilleszt. Ez az oldal tanuláshoz, ellenőrzéshez és együttműködéshez használható, nem élő ügyféladatok kezeléséhez.
Irány: Mód: Kimenet:
A GCM = AES-GCM 12 bájtos nonce-szal és 128 bites hitelesítőcímkével (AEAD: bizalmasság + integritás). Alapértelmezés, ha a biztonság a cél.
Kulcs (nyers bájtok: 16, 24 vagy 32 bájt = AES-128/192/256; a beillesztett hossz dönt)
A hex tolerálja a szóközöket, kettőspontokat és a 0x előtagokat.
IV / nonce (GCM: 12 bájt; CBC/CTR: 16 bájt — hex)
GCM-ben vagy CTR-ben nonce nem használható újra ugyanazon kulccsal.
AAD (kiegészítő hitelesített adat — hitelesített, de nem titkosított, opcionális)
Címkehossz:
Plaintext text (the data to encrypt, UTF-8 encoded)
Ciphertext (egy sor: mód, kulcsméret, érték; a paraméterek alább)
A paramétersorok rögzítik a pontos kulcsértelmezést, az IV-t, az AAD-méretet és a címkét, így a bemásolt eredmény bármely másik gépen reprodukálható.
Melyik mód a megfelelő?
A GCM az alapértelmezett válasz: titkosít és hitelesít — a címkesor teszi láthatóvá a manipulációt (megfordított címkebájttal próbált visszafejtésnél az oldal visszautasítja). A CBC elrejti a blokkmintázatokat, de nem nyújt integritást; ha mindenképp szükséges, HMAC-kel párosítva (részletek: a HMAC-generátort). A CTR az AES-t folyam-titkosítóvá alakítja — nincs kitöltés, de egy kulcs alatt újrafelhasznált nonce mind a CTR-ben, mind a GCM-ben katasztrofális. Az ECB csak kompatibilitásra és oktatásra való: az azonos nyílt szöveg-blokkok azonos titkosszöveg-blokkokká titkosulnak (a híres ECB-pingvin).
OpenSSL-együttműködés — az ezen oldalról származó CBC- és CTR-kimenetek (PKCS#7 kitöltés, nyers kulcs) az openssl enc parancssorral körbeutazhatók:
openssl enc -aes-256-cbc -K <64-hex-kulcs> -iv <32-hex-iv> -in msg.txt -out msg.enc
openssl enc -d -aes-256-cbc -K <kulcs> -iv <iv> -in msg.enc -out msg.txt
Ugyanez működik a -aes-128-cbc, -aes-192-cbc, -aes-256-ctr (16 bájtos IV = kezdeti számlálóblokk) változatokkal is. Az openssl enc nem támogatja a GCM-et — hitelesített titkosításhoz ez az oldal, vagy az OpenSSL 3.3+ openssl aesgcm parancsát.
Kínai nemzeti titkosító a cél?
Az SM4 (GB/T 32907-2016) — a kínai kereskedelmi kriptográfiában előírt blokk-titkosító, amely az AES-szel azonos 128 bites blokk- és kulcsmérettel rendelkezik, de saját kulcsütemezéssel és S-dobozzal — külön oldalon fut ECB- és CBC-módban: SM4 Titkosítás / visszafejtés. Az SM-csomag többi része is ott van: SM3 (kivonat), SM2 (nyilvános kulcs) és SM9 (identitásalapú kriptográfia).
Önteszt
Az oldal motorjait független horgonyértékekkel futtatja: ismert válaszú vektorok mind a négy módra (független natív megvalósítás generálta), GCM-címkevektorok AAD-vel és AAD nélkül, a WebCrypto-motor keresztellenőrzése a tiszta JS AES-motorral, GCM-körút, és negatív tesztek (megváltoztatott címke, rossz kulcs kell hogy elbukjon). Semmi sem küldődik sehová.
Az AES-titkosítás a nulláról elmagyarázva
Egy mondatban: az AES a világszerte szabványos blokk-titkosító — 128, 192 vagy 256 bites kulccsal keveri a 16 bájtos blokkokat — a mód, amelyben futtatja (GCM, CBC, CTR, ECB), dönti el, hogyan láncolódnak ezek a blokkok, mire való az IV, és észlelhető-e a manipuláció; a GCM-et érdemes választani, hacsak nincs rá ok, hogy ne.
Mi az AES (FIPS 197)

A blokk-titkosító. Az AES (a Rijndael-tervezés, amelyet a NIST 2001-ben szabványosított FIPS 197 néven) pontosan 16 bájtot titkosít egyszerre. A kulcshossz — 16, 24 vagy 32 bájt — választja ki az AES-128, -192 vagy -256 változatot és a belső körök számát (10, 12, 14). Minden kör a blokkot a kulcsból származtatott körkulcsokkal keveri helyettesítő táblázatokon, sorelforgatásokon és oszlopkeverésen át. Nincs gyakorlati támadás, amely önmagában törné meg a titkosítót: a valós hibák szinte mindig mód-, IV- vagy kulcskezelési hibák, és erről szól az oldal többi része.

Miért kell egyáltalán mód? Mert az üzenetek ritkán 16 bájtosak. A mód összeragasztja a blokk-titkosításokat: az ECB csak független blokkokat titkosít; a CBC minden blokkot az előző titkosszöveggel XOR-ol; a CTR számlálót titkosít, és folyam-titkosítóként XOR-olja az adatokkal; a GCM a CTR-re épül, és hitelesítőcímkét ad hozzá. Az AES ugyanaz marad — a mód mindent megváltoztat abban, milyen garanciákat kap.

Kulcsok és jelszavak. Az AES-kulcs 16, 24 vagy 32 véletlen bájt. Az emberi jelszó nem ilyen: ennek az oldalnak a Jelszó opciója PBKDF2-HMAC-SHA256-tal származtat megfelelő kulcsot (alapértelmezés szerint 600 000 iteráció, az OWASP 2023-as alapértéke — a KDF részleteiért: a HMAC-generátort). Jelszósztring közvetlenül nem használható AES-kulcsként: entrópiája hosszának csak kis töredéke.

A négy mód összehasonlítása
MódIV / nonceIntegritásMegjegyzések
GCM12 bájt, üzenetenként egyediIgen — 96..128 bites címkeAEAD: mindenhol ajánlott alapértelmezés (TLS 1.3, SSH, fájlformátumok). AAD-t is elfogad.
CBC16 bájt, kiszámíthatatlanNemPKCS#7 kitöltés; klasszikus, de mellé MAC kell. A kitöltés-orákulum hibák a klasszikus CBC-csapdák.
CTR16 bájtos kezdeti számlálóNemNincs kitöltés, folyamszerű, véletlen hozzáférés; egy kulcs alatt a nonce újrafelhasználása nyílt szöveget szivárogtat.
ECBnincsNemAzonos blokkok → azonos titkosszöveg. Az ECB-pingvin bemutató. Csak kompatibilitás.

Az IV szabályai egy bekezdésben. Az IV nem titok — a titkosszöveg mellett kell küldeni —, de egyediségének szabályai eltérnek: a CBC kiszámíthatatlan IV-t kíván; a GCM és a CTR csak azt követeli meg, hogy soha ne használják újra ugyanazt a nonce-ot ugyanazzal a kulccsal (a GCM nonce-újrafelhasználás rosszabb: kiszivárogtatja a hitelesítő alkulcsot). Ennek az oldalnak a Véletlenszerű IV gombja a böngésző biztonságos RNG-jét használja; a Csupa nulla gomb tesztvektorok reprodukálására való, nem valódi üzenetekhez.

Kitöltés. A CBC és az ECB egész blokkokat igényel, ezért a PKCS#7 kitöltés 1..16 bájtot fűz hozzá, mindegyik a kitöltés hosszával egyenlő. Ezért nő a CBC-titkosszöveg legfeljebb 16 bájttal, és ezért szokott a rossz kulccsal való visszafejtés kitöltési hibával elbukni. A CTR és a GCM folyamszerűek, nincs kitöltésük — a titkosszöveg hossza pontosan megegyezik a nyílt szöveg hosszával (a minta CTR-módban kipróbálható: 43 bájt be, 43 bájt ki).

A CFB és az OFB (a két maradék klasszikus mód) nincs megvalósítva ezen az oldalon: folyamszerűek, mint a CTR, de annál nincs előnyük, és főként régi protokollokban élnek tovább.

Mit ad hozzá a GCM (AEAD, címkék, AAD)

Hitelesített titkosítás. A GCM = CTR-titkosítás + GHASH-hitelesítő a titkosszövegen, az IV-n és az AAD-n. A kimeneti címke mindennek ujjlenyomata: a titkosszöveg, az IV vagy az AAD egyetlen bitjének megváltoztatása után a címke nem egyezik, így a fogadó bizonyíthatja, hogy az üzenet sértetlen és kulcstartótól származik. A CBC+HMAC ugyanezt csak akkor éri el, ha helyesen komponálják (encrypt-then-MAC) — a GCM ezt konstrukcióval helyesen adja.

AAD. A további hitelesített adat nyíltan utazik, de a címke lefedi: protokollfejlécek, fájlnevek, algoritmusazonosítók. A fogadónak pontosan ugyanazokat az AAD-bájtokat kell megadnia, különben a címkeellenőrzés elbukik — ez a lényeg.

Címkehossz. Az alapértelmezett 128 bites címke az ajánlás; a rövidebb címkék (96..120 bit) a hamisítással szembeni ellenállást a méretre cserélik. 96 bit alatt a GCM biztonsági bizonyításai gyorsan romlanak, ezért áll meg itt ez az oldal.

A nonce-katasztrófa. Egy 12 bájtos GCM-nonce újrafelhasználása ugyanazzal a kulccsal kiszivárogtatja a két üzenet nyílt szövegének XOR-ját és a hitelesítő alkulcsot — ezután az adott kulccsal készült jövőbeli üzenetekre hamisítás lehetséges. Azok a rendszerek, amelyek nem tudják garantálni az egyediséget, nonce-újrafelhasználásnak ellenálló változatokat használnak (AES-GCM-SIV, RFC 8452).

Ellenőrző értékek — ezen az oldalon állíthatók elő

Az első sor a híres, egyetlen blokkos FIPS 197 példa; a többit független natív megvalósítás (OpenSSL Node.js-en keresztül) generálta, és az oldal motorjaival újra ellenőrizték. A kulcs, az IV és a bemenet az oldalra illeszthető be, hogy minden sor újra előállítható legyen.

EsetBemenetekVárt kimenet
AES-128 egyetlen blokk (FIPS 197 szerint)key 000102..0f, plaintext 00112233..ff69c4e0d86a7b0430d8cdb78070b4c55a
AES-128-GCMkey 000102..0f, IV 606162..6b, plaintext 0011..ef ×2ct 275f095bedfda377063fee326128892188377b410698ed03a022b9971bb4bdbe, tag 87ea7770714048977de2fd8dac645ecf
AES-256-GCM, ugyanaz, AAD deadbeefkey 000102..1fct eacab966ff15e518f48f5390be502fbc2756ccee0dcfff36a282c50bf5593ae7, tag aead900e895c88252d0388d7aefce5c8
AES-256-CBCkey 000102..1f, IV 101112..1f, plaintext 0011..ef ×20e2392dd6f690b44a5a1b4fdff3b7f83cb9ab59d9900119cc5f83e062d95fb643b1a94b514ea2f3b95f84c900b5c98a8
AES-256-CTR (ugyanaz a bemenet, mint a fenti CBC)43-byte plaintext → 43-byte ciphertexte9d2cdb9f661359178ed366dfa3a4671f8e20efd723f090eb7d1d524d480fd3c
Gyakori hibák
  • ECB használata, mert nem kell IV. A kényelem a csapda: a blokkmintázatok egyenesen a titkosszövegbe szivárognak (bitképet titkosítva még látható a kép). Az ECB csak egyetlen blokkra vagy pontosan 16 bájtos véletlen kulcsokra elfogadható — a gyakorlatban soha nem szándékosan.
  • Nonce/IV újrafelhasználása. GCM- vagy CTR-módban, egy kulcs alatt ez az egyetlen hiba, amely egyszerre mindent tönkretesz. A számlálóalapú rendszerek (ennek az oldalnak a Véletlenszerű IV gombja) azért léteznek, hogy ez lehetetlen legyen.
  • Az IV titokként kezelése. Nem az. A titkosszöveg mellett tárolja vagy továbbítsa. Elrejtése semmit nem ér, és az újrafelhasználásra csábít.
  • Jelszó használata kulcsként. A "hunter2hunter2hunter2hunter2" 32 bájt, de nem 256 bit entrópia — ez egy szótári szó kitöltéssel. PBKDF2-vel származtatható (ebben az oldalban beépítve), vagy véletlen kulcs generálható.
  • Feltételezés, hogy a CBC észleli a manipulációt. Egy bitet megfordítva a CBC-titkosszövegben a visszafejtés „sikeres” lesz, csendesen sérült nyílt szöveggel. Csak a GCM-címke (vagy egy explicit HMAC) teszi láthatóvá a manipulációt.
  • GCM-titkosszövegek egyenlőségének összehasonlítása. Véletlen nonce-okkal ugyanaz a nyílt szöveg minden alkalommal másként titkosul — ez funkció. A determinisztikus titkosítás egy másik, speciális eszköz.
GYIK

Biztonságos még az AES-128, vagy 256 kell? Mindkettő biztonságos a reális támadókkal szemben; a legismertebb támadások csak a ráhagyás töredékét faragják le. Az AES-256 elsősorban hosszú távú titkok és a kvantumszámítógépek elleni tartalék miatt számít (Grover algoritmusa felezi a kulcs erősségét, így az AES-256 ~128 bites egyenértékű marad).

Miért nem tud az openssl enc GCM-et? Az enc parancs az AEAD előtt készült, és nincs módja címke hordozására; az OpenSSL 3.3 ehelyett külön aesgcm parancsot adott hozzá. Ennek az oldalnak a GCM-kimenete a címkét külön sorban tartja, hogy mindkettő explicit módon mozgatható legyen.

Mi az a kulcscsomagolás (AES-KW)? Speciális mód más kulcsok titkosítására fix, 64 bites darabokkal és saját integritásellenőrzéssel. Itt nem érhető el, mert bemenetei és kimenetei kulcsformájúak, nem üzenetformájúak — a helytelen használat a szabály.

Miért ugyanolyan hosszú a CTR-titkosszöveg, mint a nyílt szöveg, a CBC-é viszont hosszabb? A CTR és a GCM folyamszerűek (nincs kitöltés); a CBC/ECB PKCS#7-tel egész, 16 bájtos blokkra tölt ki. A hosszkülönbség tervezett, nem hiba.

Visszafejthetek valamit, amit máshol titkosítottak? Igen, ha ismeri a pontos módot, a kulcsot, az IV-t (és GCM-nél a címkét). Ennek az oldalnak a kimeneti sorai mindet pontosan rögzítik, így a paraméterek eszközök között átvihetők — a fenti OpenSSL-doboz a megfelelő parancssorokat mutatja.