DES / 3DES / RC4 / Blowfish titkosítása és visszafejtése

Titkosítás vagy visszafejtés a négy klasszikus titkosítóval, amelyek régi fájlokban, biztonsági mentésekben és protokollokban még élnek — DES és 3DES ECB vagy CBC módban, RC4 (ARCFOUR) folyamként, és Blowfish 56 bájtig terjedő kulccsal. Ellenőrizve a FIPS 46-3, Schneier közzétett Blowfish-vektorai és az RFC 6229 szerint. Minden helyben fut — nincs feltöltés. Modern munkához az AES-GCM javasolt.
Ezek a titkosítók a kompatibilitást szolgálják, nem az új munkát. A DES-t 2005-ben vonták vissza, a 3DES-t 2023-ban, az RC4-et 2015 óta tiltja a TLS (RFC 7465), a Blowfish 64 bites blokkja pedig kb. 32 GiB adat után éri el a születésnapi határát egy kulcs alatt. Új munkához az AES-GCM használata javasolt.
Irány: Titkosító: Mód: Kimenet:
DES = az 1977-es Data Encryption Standard: 64 bites blokkok, 56 bites hatékony kulcs. Visszavonták, de régi biztonsági mentésekben, (banki) PIN-blokkokban és Kerberos v4-ben még előfordul. A kulcsnak pontosan 8 bájtosnak kell lennie.
Kulcs (8 bytes, hex or text)
A hex elfogadja a szóközöket, kettőspontokat és a 0x előtagot. A DES figyelmen kívül hagyja minden kulcsbájt paritásbitjét.
Plaintext text (the data to encrypt, UTF-8 encoded)
A blokk-titkosítók PKCS#7 szerint töltenek ki; az RC4 soha nem tölt ki.
Titkos szöveg (egy sor: titkosító, mód, érték; a paraméterek alább)
Az oldal által elfogadott kulcshosszak
TitkosítóKulcsBlokkÁllapot
DESpontosan 8 bájt (56 hatékony bit)64 bit2005-ben visszavonva (NIST SP 800-131A)
3DES-EDE3pontosan 24 bájt (112 hatékony bit)64 bit2023 után tiltott (SP 800-131A r2)
3DES-EDE2pontosan 16 bájt (112 hatékony bit)64 bitugyanaz, mint az EDE3, gyengébb örökölt lehetőség
RC4 / ARCFOUR1..256 bájtfolyam2015 óta tiltott a TLS-ben (RFC 7465)
Blowfish4..56 bájt64 bitnem törték meg, de 64 bites blokkhoz kötött; Twofish/AES javasolt
A hatékony kulcsméret kisebb a nyers méretnél, mert a DES minden bájt egy bitjét paritásként használja: egy 64 bites nyers kulcs csak 56 kulcsbitet hordoz, a 3DES három független kulccsal 112-t (találkozz-a-közepen).
OpenSSL-együttműködés — az OpenSSL 3 ezeket a titkosítókat a legacy szolgáltatóba helyezte; ha a parancs visszautasítja, a -provider legacy kapcsoló hozzáadandó. Az oldal parancssori megfelelői:
openssl enc -des-ecb -K 133457799BBCDFF1 -in msg.bin -out msg.enc
openssl enc -des3 -K <48 hex> -iv <16 hex> -in msg.bin -out msg.enc (3DES-CBC)
openssl enc -rc4 -K 4b6579 -in msg.bin -out msg.enc  /  -bf-cbc a Blowfish-CBC-hez.
Visszafejtéshez -d. A -K nyers hex-kulcsot, a -k jelszót vesz (kerülendő — a KDF eltér az oldal bármely funkciójától).
Önteszt
Újrafuttatja az oldal motorját közzétett és függetlenül generált vektorokon: a FIPS 46-3 kidolgozott DES-példáján, OpenSSL-lel generált 3DES EDE2/EDE3 titkos szövegeken, a Schneier-féle Blowfish-vektorokon, az RFC 6229 RC4-tesztvektorain és a klasszikus „Key/Plaintext” példán, minden módban körutazásokon, valamint negatív teszteken (rossz kulcsméret, nem blokkméret-többszörös titkos szöveg elutasítása). Semmi nem kerül elküldésre.
A DES, 3DES, RC4 és Blowfish nulláról, magyarázattal
Egy mondatban: ez a négy titkosító volt az 1990-es évek munkalovai — a DES és a hármas titkosítású kiegészítése, a 3DES, az RC4 folyamtitkosító és a Blowfish — és mindegyik ma már nyugdíjas vagy elavult, csak régi fájlok, régi hardver és olyan régi protokollok tartják életben, amelyeket még olvasni kell.
DES: az 1977-es szabvány, amely mindent elindított

Mi ez. A Data Encryption Standard (FIPS 46, 1977) 16 köres Feistel-titkosító 64 bites blokkokon, 56 bites kulccsal (8 bájtban tárolva, mert minden bájt egyik bitje paritásellenőrzés). Az IBM tervezte az NSA bevonásával, két évtizedig az USA szabványa volt, és 1998-ban a szakpolitika törte meg, amikor az EFF Deep Crack gépe 56 óra alatt, 250 000 dollárnyi hardverrel kényszerített ki egy kulcsot. A NIST 2005-ben visszavonta a titkosításra való használatát.

Miért zavarja össze a paritásbit a kulcshosszakat. Minden 8. bitje egy DES-kulcsnak a másik hétből számítódik, ezért egy 8 bájtos kulcs csak 56 független bitet hordoz — ezért látni „64 bites kulcs” és „56 bites kulcs” megnevezést is ugyanarra a titkosítóra. A 3DES ezt örökli: 24 nyers bájt = 168 nyers bit = 112 hatékony (a találkozz-a-közepen támadás a többit eltünteti).

Hol találkozhat vele még. Banki PIN-blokkoknál (ISO 9564), néhány Kerberos v4 tartományban, régi biztonsági mentési archívumokban és chipkártyákon. Ha egy rendszer ma DES-t követel meg, vagy 1990-es évek hardverével működik együtt, vagy egyszerűen nem biztonságos.

3DES: titkosítás, visszafejtés, titkosítás

A trükk. A hármas DES minden blokkon háromszor futtatja a DES-t: az EDE3 három különböző kulccsal dolgozik (C = Ek3(Dk2(Ek1(P)))); a középső visszafejtő lépés azért van, hogy a 3DES-implementáció a k1=k2 beállítással az egyszeres DES-t is utánozhassa. Az EDE2 csak két kulcsot használ (k1=k3), ami 112 hatékony bitet ad. A konstrukció gyors javítás volt, amely megháromszorozta egy már támadott titkosító biztonságát, anélkül hogy újat tervezett volna.

Miért halt meg mégis. Két probléma: lassú (blokkonként három teljes DES-menet, kb. 1/20-a az AES sebességének), és megtartotta a 64 bites blokkot. Egy kulcs alatt 32 GiB adattal (a 232 blokk születésnapi határa) a blokkütközések elég valószínűvé válnak ahhoz, hogy szivárogtassák a nyílt szöveg szerkezetét — a Sweet32-támadás (2016) ezt 3DES-es TLS-munkamenetekkel mutatta be. A NIST 2023 után tiltotta a 3DES titkosítását (SP 800-131A r2); a PCI DSS a fizetési rendszerekben a kivonását írja elő.

RC4 / ARCFOUR: a korai web folyamtitkosítója

Hogyan működik. Az RC4 (Ron's Code 4, 1987-ben tervezték, 1994-ben szivárgott ki) folyamtitkosító: a kulcs egy 256 bájtos permutációt állít elő (KSA), majd a permutáció pszeudovéletlen bájtfolyamot ad (PRGA), amelyet XOR-ral kapcsolnak az üzenethez. Nincs kitöltés, nincs blokkméret, bármilyen üzenethossz, szoftverben triviálisan gyors — ezért uralta az SSL/TLS-t és a WEP-et az 1990-es években. Az „ARCFOUR” a védjegymentes név, amelyet a legtöbb nyílt forráskódú projekt használ.

Hogyan tört meg. Fluhrer, Mantin és Shamir (2001) megmutatta, hogy a kulcsfolyam első bájtjai torzítottak — végzetes a WEP-ben, ahol a csomagonkénti kulcskonstrukció ezeket a bájtokat a támadóknak adta. A későbbi torzítási támadások (2013, AlFardan és társai) millió kapcsolatból álló RC4-védett TLS-munkamenetekből nyertek vissza nyílt szöveget. Az RFC 7465 (2015) teljes egészében tiltja az RC4-et a TLS-ben.

A klasszikus vektor. A „Key” kulcs (3 bájt), a „Plaintext” üzenet a bbf316e8d940af0ad3 titkos szöveget adja — az RC4 mintával érdemes kipróbálni és összevetni. Az oldal önellenőrzése az RFC 6229 kulcsfolyamát is ellenőrzi a 40 bites 01 02 03 04 05 kulcsra: b2396305f03dc027ccc3524a0a1118a8.

Blowfish: nem törték meg, de blokkmérettel korlátozott

Mi ez. Bruce Schneier 1993-as Feistel-titkosítója: 64 bites blokkok, 32–448 bites (4–56 bájtos) kulcsok, 16 kör, és egy híres kulcsütemezés, amely a Blowfish 521-szer fut le az alkulcsok felépítéséhez — ez lassúvá teszi a kulcsbeállítást, de a brute-force próbálkozásokat is drágává. Gyakorlati kriptoanalízis a teljes körös Blowfish-t nem töri meg.

Miért van mégis az oldalon. A 64 bites blokk a probléma, nem az algoritmus: egy kulcs alatt kb. 32 GiB fölött születésnapi ütközések szivárogtatják az adatot (ugyanaz a határ, mint a 3DES-nél, Sweet32-jellegű). Schneier az utódját, a Twofish-t (AES-döntős) vagy az AES-t ajánlja minden újhoz. A Blowfish a bcrypt-ben tovább él — a jelszóhash kulcsütemezése Blowfish —, ami rendben van, mert a hashelés apró bemeneteket használ, nem gigabájtokat.

A klasszikus vektorok. A csupa nulla kulcs és a csupa nulla nyílt szöveg a 4ef997456198dd78-at adja titkosításkor (a Minta kimenetének első blokkja); a „abcdefghijklmnopqrstuvwxyz” kulcs a „BLOWFISH” szövegen 324ed0fef413a203-at ad. Mindkettő Schneier közzétett vektorfájljából származik, és az önellenőrzés ellenőrzi őket.

Gyakori hibák
  • Ezek használata új adatokhoz. Az oldal minden titkosítója elavult, kivéve a Blowfish-t (amely blokkméretben korlátozott). A megfelelő modern választás az AES-GCM — részletek: az AES titkosítás / visszafejtés oldalt.
  • DES-kulcs jelszóból. Egy 8 karakteres jelszó nem 56 véletlen bit; karakterenként néhány bit entrópia. A régi rendszerek pontosan ezt tették, és ez a leggyakoribb oka annak, hogy a „DES-szel titkosított” archívumok percek alatt szótártámadás áldozatai lesznek.
  • IV újrafelhasználása CBC-ben. Ekkor az első blokk megmutatja, hogy az üzenetek azonos nyílt szövegűek-e ugyanazon kulccsal. A Véletlen IV gomb erre létezik.
  • RC4 kulcsfolyam újrafelhasználása. Az RC4 ugyanazt a kulcsfolyamot XOR-olja ugyanarra a kulcsra: két üzenet titkosítása egy kulccsal két-idős pad — a titkos szövegek XOR-olásából mindkét nyílt szöveg kiesik. A WEP végzetes hibája pontosan egy kulcsfolyam-újrafelhasználó konstrukció volt.
  • Azt feltételezni, hogy „visszafejtődik, tehát helyes”. Az ECB/CBC itt visszafejtéskor csak a kitöltést ellenőrzi — egy rossz kulcs általában olyan szemetet ad, amely még lehet, hogy kitöltés-ellenőrzésen is átmegy. Egyik örökölt módban sincs integritásellenőrzés; ha kell, AES-GCM szükséges, nem ezek.
  • A 3DES „168 bitesnek” számítása. A nyers kulcs 168 bites, de a hatékony erő 112 — a találkozz-a-közepen támadás a hármas titkosítást gyakorlatilag kettősre és egy kicsit többre csökkenti, pontosan úgy, ahogy a 3DES elődkonstrukcióinál is.
GYIK

Miért kell egyáltalán egy törött titkosító-eszköz. Kompatibilitás. A titkosított mentések, az exportált régi formátumú fájlok, a rögzített protokollnyomok, a CTF-feladatok és a nem frissíthető hardverek mind ezeket a titkosítókat beszélik. A régi adatok olvasása jogos; új adatok írása ezekkel nem az.

A DES-kulcsom páratlan paritású / nem ASCII bájtokat tartalmaz. A DES figyelmen kívül hagyja minden kulcsbájt paritásbitjét, ezért a hatékony kulcs mindenképp a másik 56 bit. Ez az oldal bármely 8 bájtot elfogad, és nem kényszeríti ki a páros paritást.

Miért néz ki néha szemétnek a visszafejtett szöveg. Rossz kulcs, rossz mód, rossz IV, vagy az adat nem úgy lett titkosítva, ahogy feltételezi. Hitelesítési címke nélkül nincs tiszta „rossz kulcs” hibaüzenet — csak a kitöltés-ellenőrzés nyújt támpontot, amely szerencsével is átmehet (az esetek 1/256-ában).

A Blowfish biztonságos a fájljaimhoz? Kis fájloknál kriptográfiai értelemben igen (nincs gyakorlati törés). Gigabájtos nagyságrendnél egyetlen kulcs alatt nem — a 64 bites blokk születésnapi határa az adatmennyiségtől függ, nem a kulcs erejétől. A Twofish vagy az AES elkerüli a problémát.

Mi a helyzet a 72 bájtos Blowfish-kulcsokkal, amelyeket láttam valahol? Egyes megvalósítások 72 bájtig fogadnak el, de Schneier referencia-implementációja 56-ot használ, és a 56 bájton túli bájtok a szabványos ütemezésben nem adnak további diffúziót. Az oldal a referenciát követi: 4–56 bájt.