DES / 3DES / RC4 / Blowfish kryptera & dekryptera

Kryptera eller dekryptera med de fyra klassiska chiffren som fortfarande finns i gamla filer, säkerhetskopior och protokoll — DES och 3DES i ECB eller CBC, RC4 (ARCFOUR) som strömchiffer och Blowfish med nycklar på upp till 56 byte. Verifierade mot FIPS 46-3, Schneiers publicerade Blowfish-vektorer och RFC 6229. Allt körs lokalt i webbläsaren — inget laddas upp. För modernt arbete används AES-GCM.
Dessa chiffer finns här för kompatibilitet, inte för nytt arbete. DES drogs tillbaka 2005, 3DES 2023, RC4 har varit förbjuden i TLS sedan 2015 (RFC 7465), och Blowfishs 64-bitarsblock når sin födelsedagsgräns efter cirka 32 GiB data under en nyckel. Använd AES-GCM för allt nytt.
Riktning: Chiffer: Läge: Utdata:
DES = Data Encryption Standard från 1977: 64-bitarsblock, 56 effektiva nyckelbitar. Tillbakadragen men fortfarande vanlig i gamla säkerhetskopior, PIN-block (bank) och Kerberos v4. Nyckeln måste vara exakt 8 byte.
Hex tolererar mellanslag, kolon och 0x-prefix. DES ignorerar paritetsbiten i varje nyckelbyte.
Blockchiffer paddar med PKCS#7; RC4 paddar aldrig.
Nyckellängder som den här sidan accepterar
ChifferNyckelBlockStatus
DESexakt 8 byte (56 effektiva bitar)64 bitartillbakadragen 2005 (NIST SP 800-131A)
3DES-EDE3exakt 24 byte (112 effektiva bitar)64 bitarinte tillåten efter 2023 (SP 800-131A r2)
3DES-EDE2exakt 16 byte (112 effektiva bitar)64 bitarsamma som EDE3, svagare äldre alternativ
RC4 / ARCFOUR1..256 byteströmförbjuden i TLS sedan 2015 (RFC 7465)
Blowfish4..56 byte64 bitarobruten men bunden av 64-bitarsblocket; använd Twofish/AES
Den effektiva nyckelstorleken är mindre än den råa storleken eftersom DES använder en bit av varje byte som paritet: en 64-bitars rå nyckel bär bara 56 nyckelbitar, och 3DES med tre oberoende nycklar bär 112 (mötet-i-mitten).
OpenSSL-interoperabilitet — OpenSSL 3 flyttade dessa chiffer till den äldre providern; lägg till -provider legacy om den vägrar. Kommandoradsmotsvarigheter till den här sidan:
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 för Blowfish-CBC.
Dekryptera med -d. -K tar en rå hexnyckel, -k ett lösenord (undvik — KDF:en skiljer sig från allt på den här sidan).
Självtest
Kör sidans motor igen mot publicerade och oberoende genererade vektorer: det arbetade DES-exemplet från FIPS 46-3, OpenSSL-genererade 3DES EDE2/EDE3-chiffertexter, Schneiers Blowfish-vektorer, RC4-testvektorer från RFC 6229 och det klassiska exemplet ”Key/Plaintext”, rundresor i varje läge och negativa tester (fel nyckelstorlek och chiffertext som inte är en blockmultipel måste misslyckas). Inget skickas någonstans.
DES, 3DES, RC4 och Blowfish förklarade från grunden
På en mening: dessa fyra chiffer var arbetshästarna under 1990-talet — DES och dess trippelkrypteringslösning 3DES, strömchiffret RC4 och Blowfish — och vart och ett av dem är nu pensionerat eller utfasat, och lever bara kvar i gamla filer, gammal hårdvara och gamla protokoll som måste kunna läsas.
DES: 1977-standarden som startade allt

Vad det är. Data Encryption Standard (FIPS 46, 1977) är ett 16-omgångars Feistel-chiffer på 64-bitarsblock med en 56-bitars nyckel (lagrad i 8 byte eftersom en bit i varje byte är en paritetskontroll). Det konstruerades av IBM med NSA:s medverkan, blev USA:s standard i två decennier och bröts genom beslut 1998 när EFF:s Deep Crack-maskin bruteforce-knäckte en nyckel på 56 timmar för 250 000 dollar i hårdvara. NIST drog tillbaka den för kryptering 2005.

Varför paritetsbiten förvirrar nyckellängderna. Var åttonde bit i en DES-nyckel beräknas från de övriga sju, så en 8-byte-nyckel bär bara 56 oberoende bitar — det är därför man ser både "64-bitars nyckel" och "56-bitars nyckel" för samma chiffer. 3DES ärver detta: 24 råa byte = 168 råa bitar = 112 effektiva (mötet-i-mitten tar bort resten).

Var man fortfarande stöter på den. Bankers PIN-block (ISO 9564), vissa Kerberos v4-realms, gamla säkerhetskopieringsarkiv och chipkort. Om ett system kräver DES idag interoperabiliserar det antingen med hårdvara från 1990-talet eller är helt enkelt osäkert.

3DES: kryptera, dekryptera, kryptera

Tricket. Triple-DES kör DES tre gånger över varje block: EDE3 använder tre olika nycklar (C = Ek3(Dk2(Ek1(P)))); dekrypteringssteget i mitten finns så att en 3DES-implementation kan emulera enkel DES genom att sätta k1=k2. EDE2 använder bara två nycklar (k1=k3), vilket ger 112 effektiva bitar. Konstruktionen var en snabb lösning som tredubblade säkerheten hos ett redan attackerat chiffer utan att uppfinna ett nytt.

Varför det dog ändå. Två problem: den är långsam (tre fulla DES-körningar per block, cirka 1/20 av AES:s hastighet) och den behöll blocket på 64 bitar. Med 32 GiB data under en nyckel (födelsedagsgränsen 232 block) blir blockkollisioner tillräckligt sannolika för att läcka klartextstruktur — Sweet32-attacken (2016) visade detta mot 3DES-sessioner i TLS. NIST förbjöd 3DES-kryptering efter 2023 (SP 800-131A r2); PCI DSS kräver att den avvecklas i betalningssystem.

RC4 / ARCFOUR: strömchiffret från den tidiga webben

Hur det fungerar. RC4 (Ron's Code 4, konstruerad 1987, läckte 1994) är ett strömchiffer: nyckeln schemalägger en 256-byte permutation (KSA), och sedan avger permutationen en pseudoslumpmässig byteström (PRGA) som XOR:as med meddelandet. Ingen padding, ingen blockstorlek, valfri meddelandelängd, trivialt snabbt i programvara — vilket är varför det dominerade SSL/TLS och WEP på 1990-talet. "ARCFOUR" är det varumärkesfria namn som de flesta öppenkällkodsprojekt använder.

Hur det bröts. Fluhrer-Mantin-Shamir (2001) visade att de första byten i nyckelströmmen är snedfördelade — fatalt i WEP, där den paketvisa nyckelkonstruktionen matade de byten till angripare. Senare snedfördelningsattacker (2013, AlFardan m.fl.) återskapade klartext från RC4-skyddade TLS-sessioner med miljontals anslutningar. RFC 7465 (2015) förbjuder RC4 i TLS helt.

Den klassiska vektorn. Nyckel "Key" (3 byte), meddelande "Plaintext" ger chiffertexten bbf316e8d940af0ad3 — prova RC4-exemplet och jämför. Den här sidans självtest kontrollerar också RFC 6229-nyckelströmmen för den 40-bitars nyckeln 01 02 03 04 05: b2396305f03dc027ccc3524a0a1118a8.

Blowfish: obruten, men blockbegränsad

Vad det är. Bruce Schneiers Feistel-chiffer från 1993: 64-bitarsblock, nycklar från 32 till 448 bitar (4..56 byte), 16 omgångar och ett känt nyckelschema som kör Blowfish självt 521 gånger för att bygga sina delnycklar — vilket gör nyckeluppsättningen långsam men också brute force-försök dyra. Ingen praktisk kryptoanalys bryter Blowfish med fullt antal omgångar.

Varför den finns med på den här sidan ändå. Blocket på 64 bitar är problemet, inte algoritmen: efter cirka 32 GiB under en nyckel läcker födelsedagskollisioner data (samma gräns som för 3DES, Sweet32-liknande). Schneier själv rekommenderar sin efterträdare Twofish (en AES-finalist) eller AES för allt nytt. Blowfish lever vidare i bcrypt — lösenordshashens nyckelschema är Blowfish — vilket är helt i sin ordning, eftersom hashning använder små indata, inte gigabyte.

De klassiska vektorerna. Nollnyckel och nollklartext krypteras till 4ef997456198dd78 (första blocket i exempelutdata); nyckeln "abcdefghijklmnopqrstuvwxyz" på "BLOWFISH" ger 324ed0fef413a203. Båda kommer från Schneiers publicerade vektorfil och kontrolleras av självtestet.

Vanliga misstag
  • Använda dessa för ny data. Varje chiffer på den här sidan är utfasat utom Blowfish (som är blockstorleksbegränsat). Det rätta moderna valet är AES-GCM — se AES-kryptering / -dekryptering.
  • DES-nyckel från ett lösenord. Ett lösenord med 8 tecken är inte 56 slumpmässiga bitar; det är några bitars entropi per tecken. Gamla system gjorde precis så, och det är den vanligaste anledningen till att "DES-krypterade" arkiv faller för ordlisteattacker på några minuter.
  • Återanvända en IV i CBC. Det första blocket läcker då klartextlikhet mellan meddelanden under samma nyckel. Knappen Slumpmässig IV finns av en anledning.
  • Återanvända en RC4-nyckelström. RC4 XOR:ar samma nyckelström för samma nyckel: att kryptera två meddelanden med en nyckel är en tvåtidsengångsnyckel — XOR:a chiffertexterna så faller båda klartexterna ut. WEP:s fatala brist var exakt en konstruktion med återanvänd nyckelström.
  • Att anta "det dekrypteras, alltså är det rätt". ECB/CBC här validerar bara paddingen vid dekryptering — en fel nyckel ger oftast skräp som ändå kan packas upp. Inget läge med äldre standard har någon integritetskontroll; behöver man en sådan behöver man AES-GCM, inte dessa.
  • Att räkna 3DES som "168-bitars". Den råa nyckeln är 168 bitar men den effektiva styrkan är 112 — mötet-i-mitten reducerar trippelkryptering till dubbel plus lite, precis som för 3DES:s föregångarkonstruktioner.
Vanliga frågor

Varför behålla ett verktyg för brutna chiffer alls? Kompatibilitet. Krypterade säkerhetskopior, exporterade filer i gamla format, insamlade protokollspår, CTF-uppgifter och hårdvara som inte kan uppgraderas talar alla fortfarande dessa chiffer. Att läsa gamla data är legitimt; att skriva ny data med dem är det inte.

Min DES-nyckel har udda paritet / icke-ASCII-byte. DES ignorerar paritetsbiten i varje nyckelbyte, så den effektiva nyckeln är de övriga 56 bitarna oavsett. Den här sidan accepterar valfria 8 byte och kräver inte jämn paritet.

Varför ser dekrypterad text ibland ut som skräp? Fel nyckel, fel läge, fel IV eller att datan inte krypterades på det sätt man antar. Utan autentiseringstagg finns inget rent felmeddelande för "fel nyckel" — paddingkontrollen är den enda ledtråden, och den kan passera av en slump (1/256 av gångerna).

Är Blowfish säkert för mina filer? För små filer, kryptografiskt ja (ingen praktisk knäckning). För allt i gigabyteskala under en enda nyckel, nej — födelsedagsgränsen för 64-bitarsblocket handlar om datamängd, inte nyckelstyrka. Twofish eller AES undviker problemet.

Vad sägs om de 72-byte Blowfish-nycklar jag såg någonstans? Vissa implementationer accepterar upp till 72 byte, men Schneiers referens använder 56 och byte utöver det ger ingen extra diffusion i det standardiserade schemat. Den här sidan följer referensen: 4..56 byte.