DES, 3DES, RC4 og Blowfish forklaret fra bunden
I én sætning: disse fire chiffer var arbejdsheste i 1990'erne — DES og dens tredobbelte krypteringsløsning 3DES, strømchifferet RC4 og Blowfish — og hver af dem er nu udgået eller forældet, holdt i live kun af gamle filer, gammel hardware og gamle protokoller, som stadig skal kunne læses.
DES: 1977-standarden, der startede det hele
Hvad det er. Data Encryption Standard (FIPS 46, 1977) er en 16-runders Feistel-chiffer på 64-bit blokke med en 56-bit nøgle (lagret i 8 bytes, fordi én bit af hver byte er et paritetstjek). Den blev designet af IBM med NSA-input, blev USA's standard i to årtier og blev brudt ved politisk beslutning i 1998, da EFF's Deep Crack-maskine brute-forcede en nøgle på 56 timer for hardware til 250.000 USD. NIST trak den tilbage til kryptering i 2005.
Hvorfor paritetsbittet forvirrer nøglelængder. Hver 8. bit af en DES-nøgle beregnes ud fra de andre syv, så en 8-byte nøgle kun indeholder 56 uafhængige bit — derfor ser man både "64-bit nøgle" og "56-bit nøgle" for den samme chiffer. 3DES arver dette: 24 rå bytes = 168 bit rå = 112 effektive (meet-in-the-middle fjerner resten).
Hvor man stadig støder på den. Bankers PIN-blokke (ISO 9564), nogle Kerberos v4-områder, gamle backup-arkiver og smartkort. Hvis et system i dag kræver DES, interoperer det enten med hardware fra 1990'erne, eller det er simpelthen usikkert.
3DES: kryptér, dekryptér, kryptér
Tricket. Triple-DES kører DES tre gange over hver blok: EDE3 bruger tre forskellige nøgler (C = Ek3(Dk2(Ek1(P)))); dekrypteringstrinnet i midten findes, så en 3DES-implementering kan efterligne enkelt-DES ved at sætte k1=k2. EDE2 bruger kun to nøgler (k1=k3) og giver 112 effektive bit. Konstruktionen var en hurtig løsning, der tredoblede sikkerheden for en allerede angrebet chiffer uden at opfinde en ny.
Hvorfor den alligevel døde. To problemer: den er langsom (tre fulde DES-kørsler pr. blok, ~1/20 af AES's hastighed), og den beholdt den 64-bit blok. Med 32 GiB data under én nøgle (fødselsdagsgrænsen på 232 blokke) bliver blokkollisioner sandsynlige nok til at lække klartekststruktur — Sweet32-angrebet (2016) demonstrerede dette mod 3DES-sessioner i TLS. NIST forbød 3DES-kryptering efter 2023 (SP 800-131A r2); PCI DSS kræver dens udfasning i betalingssystemer.
RC4 / ARCFOUR: strømchifferet fra den tidlige web
Sådan virker det. RC4 (Ron's Code 4, designet 1987, lækket 1994) er et strømchiffer: nøglen styrer en 256-byte permutation (KSA), og derefter udsender permutationen en pseudotilfældig byte-strøm (PRGA), der XOR'es med beskeden. Ingen padding, ingen blokstørrelse, enhver beskedlængde, trivielt hurtig i software — derfor dominerede det SSL/TLS og WEP i 1990'erne. "ARCFOUR" er det varemærkefri navn, de fleste open source-projekter bruger.
Hvordan det blev brudt. Fluhrer-Mantin-Shamir (2001) viste, at de første bytes i nøglestrømmen er skæve — fatalt i WEP, hvor den pakkevise nøgleopbygning gav angriberne disse bytes. Senere skævhedsangreb (2013, AlFardan et al.) genskabte klartekst fra RC4-beskyttede TLS-sessioner med millioner af forbindelser. RFC 7465 (2015) forbyder RC4 i TLS helt.
Den klassiske vektor. Nøglen "Key" (3 bytes) og beskeden "Plaintext" giver chifreteksten bbf316e8d940af0ad3 — prøv RC4-eksemplet, og sammenlign. Sidens selvtest kontrollerer også RFC 6229-nøglestrømmen for den 40-bit nøgle 01 02 03 04 05: b2396305f03dc027ccc3524a0a1118a8.
Blowfish: ubrudt, men blokbegrænset
Hvad det er. Bruce Schneiers Feistel-chiffer fra 1993: 64-bit blokke, nøgler fra 32 til 448 bit (4..56 bytes), 16 runder og en berømt nøgleplan, der kører Blowfish selv 521 gange for at bygge sine undernøgler — hvilket gør nøgleopsætningen langsom, men brute force-forsøg dyre. Ingen praktisk kryptoanalyse bryder fuld-runde Blowfish.
Hvorfor den alligevel er med her. Det er den 64-bit blok, der er problemet, ikke algoritmen: efter ca. 32 GiB under én nøgle lækker fødselsdagskollisioner data (samme grænse som 3DES, Sweet32-stil). Schneier selv anbefaler sin efterfølger Twofish (en AES-finalist) eller AES til alt nyt. Blowfish lever videre i bcrypt — adgangskode-hashens nøgleplan er Blowfish — hvilket er fint, fordi hashing bruger små input, ikke gigabytes.
De klassiske vektorer. En nøgle med kun nuller og klartekst med kun nuller krypteres til 4ef997456198dd78 (første blok af eksempeloutputtet); nøglen "abcdefghijklmnopqrstuvwxyz" på "BLOWFISH" giver 324ed0fef413a203. Begge kommer fra Schneiers udgivne vektorfil og kontrolleres af selvtesten.
Almindelige fejl
- Brug til nye data. Hver chiffer på denne side er forældet undtagen Blowfish (som er blokstørrelsesbegrænset). Det korrekte moderne valg er AES-GCM — se AES-kryptering / -dekryptering.
- DES-nøgle fra en adgangskode. En adgangskode med 8 tegn er ikke 56 tilfældige bit; den er nogle få bit entropi pr. tegn. Gamle systemer gjorde netop dette, og det er den hyppigste årsag til, at "DES-krypterede" arkiver falder for ordbogsangreb på få minutter.
- Genbrug af IV i CBC. Den første blok lækker så klarteksts-ligheder mellem beskeder under samme nøgle. Knappen Tilfældig IV findes af en grund.
- Genbrug af en RC4-nøglestrøm. RC4 XOR'er den samme nøglestrøm for den samme nøgle: at kryptere to beskeder med én nøgle er en to-gangs-engangsnøgle — XOR de to chifretekster, og begge klartekster falder ud. WEP's fatale fejl var netop en konstruktion med genbrug af nøglestrøm.
- At antage, at "den dekrypterer, så den er rigtig". ECB/CBC her validerer kun padding ved dekryptering — en forkert nøgle giver normalt vrøvl, der stadig kan fjernes fra padding. Ingen legacy-tilstand har en integritetskontrol; hvis man har brug for en, skal man bruge AES-GCM, ikke disse.
- At tælle 3DES som "168-bit". Den rå nøgle er 168 bit, men den effektive styrke er 112 — meet-in-the-middle reducerer tredobbelt kryptering til dobbelt plus lidt, ligesom det gør for 3DES's forfædre-konstruktioner.
Ofte stillede spørgsmål
Hvorfor beholde et værktøj til brudte chiffer overhovedet? Kompatibilitet. Krypterede backups, eksporterede filer i gammelt format, opfangede protokoltrafikker, CTF-opgaver og hardware, der ikke kan opgraderes, taler stadig disse chiffer. At læse gamle data er legitimt; at skrive nye data med dem er ikke.
Min DES-nøgle har ulige paritet / ikke-ASCII-bytes. DES ignorerer hver nøglebytes paritetsbit, så den effektive nøgle er de andre 56 bit uanset. Denne side accepterer enhver 8 bytes og håndhæver ikke lige paritet.
Hvorfor ser dekrypteret tekst nogle gange ud som vrøvl? Forkert nøgle, forkert tilstand, forkert IV, eller data blev ikke krypteret, som man antager. Uden et autentificeringstag er der ingen ren fejl for "forkert nøgle" — padding-tjekket er det eneste hint, og det kan passere ved et tilfælde (1/256 af gangene).
Er Blowfish sikker til mine filer? For små filer, kryptografisk ja (ingen praktisk brud). For alt i gigabyte-størrelse under en enkelt nøgle, nej — fødselsdagsgrænsen for 64-bit blokke handler om datamængde, ikke nøglestyrke. Twofish eller AES undgår problemet.
Hvad med de 72-byte Blowfish-nøgler, jeg så et sted? Nogle implementeringer accepterer op til 72 bytes, men Schneiers referenceimplementering bruger 56, og bytes ud over det giver ingen ekstra diffusion i standard-nøgleplanen. Denne side følger referencen: 4..56 bytes.