Enkripsi & Dekripsi DES / 3DES / RC4 / Blowfish

Enkripsi atau dekripsi dengan empat cipher klasik yang masih ada dalam berkas lama, cadangan, dan protokol — DES dan 3DES dalam ECB atau CBC, RC4 (ARCFOUR) sebagai stream, dan Blowfish dengan kunci hingga 56 byte. Diverifikasi terhadap FIPS 46-3, vektor Blowfish yang dipublikasikan Schneier, dan RFC 6229. Semuanya berjalan secara lokal di browser Anda — tidak ada yang diunggah. Untuk pekerjaan modern gunakan AES-GCM.
Cipher ini disediakan untuk kompatibilitas, bukan untuk pekerjaan baru. DES dicabut pada 2005, 3DES pada 2023, RC4 dilarang dalam TLS sejak 2015 (RFC 7465), dan blok 64-bit Blowfish mencapai batas ulang tahunnya setelah sekitar 32 GiB data di bawah satu kunci. Gunakan AES-GCM untuk apa pun yang baru.
Arah: Cipher: Mode: Output:
DES = Data Encryption Standard 1977: blok 64-bit, kunci efektif 56-bit. Telah dicabut tetapi masih ditemukan di cadangan lama, blok PIN (perbankan), dan Kerberos v4. Kunci harus tepat 8 byte.
Kunci (8 bytes, hex or text)
Hex menerima spasi, titik dua, dan awalan 0x. DES mengabaikan bit paritas dari setiap byte kunci.
Plaintext text (the data to encrypt, UTF-8 encoded)
Cipher blok menggunakan padding PKCS#7; RC4 tidak pernah menggunakan padding.
Ciphertext (satu baris: cipher, mode, nilai; parameter di baris di bawah)
Panjang kunci yang diterima halaman ini
CipherKunciBlokStatus
DEStepat 8 byte (56 bit efektif)64 bitdicabut 2005 (NIST SP 800-131A)
3DES-EDE3tepat 24 byte (112 bit efektif)64 bittidak diizinkan setelah 2023 (SP 800-131A r2)
3DES-EDE2tepat 16 byte (112 bit efektif)64 bitsama dengan EDE3, opsi lama yang lebih lemah
RC4 / ARCFOUR1..256 bytestreamdilarang dalam TLS sejak 2015 (RFC 7465)
Blowfish4..56 byte64 bitbelum dipecahkan tetapi terbatas oleh blok 64-bit; gunakan Twofish/AES
Ukuran kunci efektif lebih kecil daripada ukuran mentahnya karena DES menggunakan satu bit dari setiap byte sebagai paritas: kunci mentah 64-bit hanya membawa 56 bit kunci, dan 3DES dengan tiga kunci independen membawa 112 (meet-in-the-middle).
Interoperabilitas OpenSSL — OpenSSL 3 memindahkan cipher ini ke legacy provider; tambahkan -provider legacy jika milik Anda menolak. Padanan baris perintah dari halaman ini:
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 untuk Blowfish-CBC.
Untuk dekripsi gunakan -d. -K menerima kunci hex mentah, -k menerima kata sandi (hindari — KDF-nya berbeda dari apa pun di halaman ini).
Uji mandiri
Menjalankan ulang mesin halaman terhadap vektor yang dipublikasikan dan yang dibuat secara independen: contoh kerja DES dari FIPS 46-3, ciphertext 3DES EDE2/EDE3 yang dihasilkan OpenSSL, vektor Blowfish Schneier, vektor uji RC4 dari RFC 6229 dan contoh klasik "Key/Plaintext", roundtrip di setiap mode, serta uji negatif (ukuran kunci salah, ciphertext yang bukan kelipatan blok harus gagal). Tidak ada yang dikirim ke mana pun.
DES, 3DES, RC4 dan Blowfish dijelaskan dari nol
Dalam satu kalimat: keempat cipher ini adalah kuda pekerja tahun 1990-an — DES dan pengakalannya enkripsi tiga kali, 3DES, cipher stream RC4, dan Blowfish — dan semuanya kini dipensiunkan atau tidak disarankan, hanya bertahan oleh berkas lama, perangkat keras lama, dan protokol lama yang masih harus dibaca.
DES: standar 1977 yang memulai semuanya

Apa itu. Data Encryption Standard (FIPS 46, 1977) adalah cipher Feistel 16 putaran pada blok 64-bit dengan kunci 56-bit (disimpan dalam 8 byte karena satu bit dari setiap byte adalah bit paritas). Dirancang oleh IBM dengan masukan dari NSA, menjadi standar AS selama dua dekade, dan dipecahkan oleh kebijakan pada 1998 ketika mesin Deep Crack dari EFF memaksa brute-force sebuah kunci dalam 56 jam dengan perangkat keras seharga $250.000. NIST mencabutnya untuk enkripsi pada 2005.

Mengapa bit paritas membingungkan panjang kunci. Setiap bit ke-8 dari kunci DES dihitung dari tujuh bit lainnya, sehingga kunci 8-byte hanya memuat 56 bit independen — itulah sebabnya Anda akan melihat "kunci 64-bit" dan "kunci 56-bit" untuk cipher yang sama. 3DES mewarisi hal ini: 24 byte mentah = 168 bit mentah = 112 bit efektif (meet-in-the-middle menghilangkan sisanya).

Di mana Anda masih menemuinya. Blok PIN perbankan (ISO 9564), beberapa realm Kerberos v4, arsip cadangan lama, dan kartu pintar. Jika suatu sistem masih mewajibkan DES hari ini, ia sedang berinteroperasi dengan perangkat keras tahun 1990-an atau memang tidak aman.

3DES: enkripsi, dekripsi, enkripsi

Triknya. Triple-DES menjalankan DES tiga kali pada setiap blok: EDE3 menggunakan tiga kunci berbeda (C = Ek3(Dk2(Ek1(P)))); langkah dekripsi di tengah ada agar implementasi 3DES dapat meniru DES tunggal dengan mengatur k1=k2. EDE2 hanya menggunakan dua kunci (k1=k3), menghasilkan 112 bit efektif. Konstruksi ini adalah perbaikan cepat yang melipatgandakan keamanan cipher yang sudah diserang tanpa menciptakan cipher baru.

Mengapa tetap mati. Dua masalah: lambat (tiga lintasan DES penuh per blok, ~1/20 kecepatan AES) dan tetap menggunakan blok 64-bit. Dengan 32 GiB data di bawah satu kunci (batas ulang tahun 232 blok), tabrakan blok menjadi cukup mungkin untuk membocorkan struktur plaintext — serangan Sweet32 (2016) mendemonstrasikannya terhadap sesi TLS 3DES. NIST melarang enkripsi 3DES setelah 2023 (SP 800-131A r2); PCI DSS mewajibkan pensiunnya dalam sistem pembayaran.

RC4 / ARCFOUR: cipher stream dari web awal

Cara kerjanya. RC4 (Ron's Code 4, dirancang 1987, bocor 1994) adalah cipher stream: kunci menjadwalkan permutasi 256-byte (KSA), lalu permutasi itu menghasilkan aliran byte pseudoacak (PRGA) yang di-XOR dengan pesan. Tanpa padding, tanpa ukuran blok, panjang pesan apa pun, sangat cepat di perangkat lunak — itulah sebabnya ia mendominasi SSL/TLS dan WEP pada 1990-an. "ARCFOUR" adalah nama bebas merek yang dipakai sebagian besar proyek open-source.

Cara ia rusak. Fluhrer-Mantin-Shamir (2001) menunjukkan bahwa byte pertama keystream bias — fatal bagi WEP, yang konstruksi kunci per paketnya menyuapi byte tersebut kepada penyerang. Serangan bias berikutnya (2013, AlFardan dkk.) memulihkan plaintext dari sesi TLS yang dilindungi RC4 dengan jutaan koneksi. RFC 7465 (2015) melarang RC4 dalam TLS sepenuhnya.

Vektor klasik. Kunci "Key" (3 byte), pesan "Plaintext" menghasilkan ciphertext bbf316e8d940af0ad3 — coba Contoh RC4 dan bandingkan. Uji mandiri halaman ini juga memeriksa keystream RFC 6229 untuk kunci 40-bit 01 02 03 04 05: b2396305f03dc027ccc3524a0a1118a8.

Blowfish: belum pernah dipecahkan, tetapi terbatas oleh ukuran blok

Apa itu. Cipher Feistel 1993 karya Bruce Schneier: blok 64-bit, kunci dari 32 hingga 448 bit (4..56 byte), 16 putaran, dan jadwal kunci yang terkenal yang menjalankan Blowfish itu sendiri 521 kali untuk membangun subkuncinya — yang membuat penyiapan kunci lambat tetapi percobaan brute-force juga mahal. Tidak ada kriptanalisis praktis yang memecahkan Blowfish putaran penuh.

Mengapa tetap ada di halaman ini. Blok 64-bit adalah masalahnya, bukan algoritmanya: setelah ~32 GiB di bawah satu kunci, tabrakan ulang tahun (birthday) membocorkan data (batas yang sama dengan 3DES, gaya Sweet32). Schneier sendiri merekomendasikan penerusnya Twofish (finalis AES) atau AES untuk segala yang baru. Blowfish tetap hidup di dalam bcrypt — jadwal kunci hash kata sandi adalah Blowfish — dan itu tidak masalah, karena hashing menggunakan masukan yang kecil, bukan gigabyte.

Vektor klasik. Kunci seluruhnya nol dan plaintext seluruhnya nol dienkripsi menjadi 4ef997456198dd78 (blok pertama keluaran Contoh); kunci "abcdefghijklmnopqrstuvwxyz" pada "BLOWFISH" menghasilkan 324ed0fef413a203. Keduanya berasal dari berkas vektor Schneier yang dipublikasikan dan diperiksa oleh uji mandiri.

Kesalahan umum
  • Menggunakan ini untuk data baru. Setiap cipher di halaman ini tidak disarankan kecuali Blowfish (yang terbatas ukuran bloknya). Pilihan modern yang tepat adalah AES-GCM — lihat Enkripsi / Dekripsi AES.
  • Kunci DES dari kata sandi. Kata sandi 8 karakter bukan 56 bit acak; ia hanya memiliki beberapa bit entropi per karakter. Sistem lama melakukan persis ini, dan itulah alasan paling umum mengapa arsip "terenkripsi DES" jatuh ke serangan kamus dalam hitungan menit.
  • Menggunakan ulang IV di CBC. Blok pertama kemudian membocorkan kesamaan plaintext antar pesan di bawah kunci yang sama. Tombol IV Acak ada karena alasan ini.
  • Menggunakan ulang keystream RC4. RC4 melakukan XOR dengan keystream yang sama untuk kunci yang sama: mengenkripsi dua pesan dengan satu kunci adalah two-time pad — XOR kedua ciphertext dan kedua plaintext akan keluar. Kelemahan fatal WEP tepatnya adalah konstruksi penggunaan ulang keystream.
  • Mengira "berhasil didekripsi, jadi pasti benar". ECB/CBC di sini hanya memvalidasi padding saat dekripsi — kunci yang salah biasanya menghasilkan sampah yang mungkin masih lolos unpad. Tidak ada pemeriksaan integritas di mode lama mana pun; jika Anda memerlukannya, Anda membutuhkan AES-GCM, bukan ini.
  • Menganggap 3DES sebagai "168-bit". Kunci mentahnya 168 bit tetapi kekuatan efektifnya 112 — meet-in-the-middle mengurangi enkripsi tiga kali menjadi dua kali ditambah sedikit, persis seperti yang terjadi pada konstruksi leluhur 3DES.
FAQ

Mengapa tetap menyimpan alat cipher yang rusak? Kompatibilitas. Cadangan terenkripsi, berkas format lama yang diekspor, jejak protokol yang ditangkap, tantangan CTF, dan perangkat keras yang tidak dapat ditingkatkan semuanya masih menggunakan cipher ini. Membaca data lama itu sah; menulis data baru dengannya tidak.

Bagaimana jika kunci DES memiliki paritas ganjil / byte non-ASCII? DES mengabaikan bit paritas setiap byte kunci, sehingga kunci efektifnya adalah 56 bit lainnya terlepas dari itu. Halaman ini menerima 8 byte apa pun dan tidak memaksakan paritas genap.

Mengapa teks hasil dekripsi kadang tampak seperti sampah? Kunci salah, mode salah, IV salah, atau data tidak dienkripsi seperti yang Anda asumsikan. Tanpa tag autentikasi tidak ada galat "kunci salah" yang bersih — pemeriksaan padding adalah satu-satunya petunjuk, dan ia bisa lolos secara kebetulan (1/256 kali).

Apakah Blowfish aman untuk berkas biasa? Untuk berkas kecil, secara kriptografis ya (tidak ada pemecahan praktis). Untuk apa pun berskala gigabyte di bawah satu kunci, tidak — batas ulang tahun blok 64-bit berkaitan dengan volume data, bukan kekuatan kunci. Twofish atau AES menghindari masalah ini.

Bagaimana dengan kunci Blowfish 72-byte yang kadang terlihat? Beberapa implementasi menerima hingga 72 byte, tetapi referensi Schneier menggunakan 56 dan byte di atasnya tidak memberikan difusi tambahan dalam jadwal standar. Halaman ini mengikuti referensi: 4..56 byte.