DES / 3DES / RC4 / Blowfish Encrypt & Decrypt

Encrypt or decrypt with the four classic ciphers that still live in old files, backups and protocols — DES and 3DES in ECB or CBC, RC4 (ARCFOUR) as a stream, and Blowfish with keys up to 56 bytes. Verified against FIPS 46-3, Schneier's published Blowfish vectors and RFC 6229. Everything runs locally in your browser — nothing is uploaded. For modern work use AES-GCM.
These ciphers are here for compatibility, not for new work. DES was withdrawn in 2005, 3DES in 2023, RC4 has been forbidden in TLS since 2015 (RFC 7465), and Blowfish's 64-bit block hits its birthday bound after roughly 32 GiB of data under one key. Use AES-GCM for anything new.
Direction: Cipher: Mode: Output:
DES = the 1977 Data Encryption Standard: 64-bit blocks, 56-bit effective key. Withdrawn but still found in old backups, PIN blocks (banking) and Kerberos v4. Key must be exactly 8 bytes.
Key (8 bytes, hex or text)
Hex tolerates spaces, colons and 0x prefixes. DES ignores the parity bit of each key byte.
Plaintext text (the data to encrypt, UTF-8 encoded)
Block ciphers pad with PKCS#7; RC4 never pads.
Ciphertext (one line: cipher, mode, value; parameters on the lines below)
Key lengths this page accepts
CipherKeyBlockStatus
DESexactly 8 bytes (56 effective bits)64 bitswithdrawn 2005 (NIST SP 800-131A)
3DES-EDE3exactly 24 bytes (112 effective bits)64 bitsdisallowed after 2023 (SP 800-131A r2)
3DES-EDE2exactly 16 bytes (112 effective bits)64 bitssame as EDE3, weaker legacy option
RC4 / ARCFOUR1..256 bytesstreamprohibited in TLS since 2015 (RFC 7465)
Blowfish4..56 bytes64 bitsunbroken but 64-bit-block-bound; use Twofish/AES
Effective key size is smaller than the raw size because DES uses one bit of each byte as parity: a 64-bit raw key carries only 56 key bits, and 3DES with three independent keys carries 112 (meet-in-the-middle).
OpenSSL interop — OpenSSL 3 moved these ciphers to the legacy provider; add -provider legacy if yours refuses. Command-line equivalents of this page:
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 for Blowfish-CBC.
Decrypt with -d. -K takes a raw hex key, -k a password (avoid — the KDF differs from anything on this page).
Self-test
Re-runs the page engine against published and independently generated vectors: the FIPS 46-3 worked DES example, OpenSSL-generated 3DES EDE2/EDE3 ciphertexts, the Schneier Blowfish vectors, RC4 test vectors from RFC 6229 and the classic "Key/Plaintext" example, roundtrips in every mode, and negative tests (wrong key size, non-block-multiple ciphertext must fail). Nothing is sent anywhere.
DES, 3DES, RC4 and Blowfish explained from scratch
In one sentence: these four ciphers were the workhorses of the 1990s — DES and its triple-encryption workaround 3DES, the stream cipher RC4, and Blowfish — and every one of them is now retired or deprecated, kept alive only by old files, old hardware and old protocols that must still be read.
DES: the 1977 standard that started it all

What it is. The Data Encryption Standard (FIPS 46, 1977) is a 16-round Feistel cipher on 64-bit blocks with a 56-bit key (stored in 8 bytes because one bit of each byte is a parity check). It was designed by IBM with NSA input, became the US standard for two decades, and was broken by policy in 1998 when the EFF's Deep Crack machine brute-forced a key in 56 hours for $250,000 of hardware. NIST withdrew it for encryption in 2005.

Why the parity bit confuses key lengths. Every 8th bit of a DES key is computed from the other seven, so an 8-byte key holds only 56 independent bits — that is why you will see both "64-bit key" and "56-bit key" for the same cipher. 3DES inherits this: 24 raw bytes = 168 bits raw = 112 effective (meet-in-the-middle removes the rest).

Where you still meet it. Banking PIN blocks (ISO 9564), some Kerberos v4 realms, old backup archives, and smart cards. If a system demands DES today, it is either interoperating with 1990s hardware or it is simply insecure.

3DES: encrypt, decrypt, encrypt

The trick. Triple-DES runs DES three times over each block: EDE3 uses three different keys (C = Ek3(Dk2(Ek1(P)))); the decrypt step in the middle exists so a 3DES implementation can emulate single DES by setting k1=k2. EDE2 uses only two keys (k1=k3), giving 112 effective bits. The construction was a quick fix that tripled the security of an already-attacked cipher without inventing a new one.

Why it died anyway. Two problems: it is slow (three full DES passes per block, ~1/20 the speed of AES) and it kept the 64-bit block. With 32 GiB of data under one key (the birthday bound of 232 blocks), block collisions become likely enough to leak plaintext structure — the Sweet32 attack (2016) demonstrated this against TLS 3DES sessions. NIST disallowed 3DES encryption after 2023 (SP 800-131A r2); PCI DSS requires its retirement in payment systems.

RC4 / ARCFOUR: the stream cipher of the early web

How it works. RC4 (Ron's Code 4, designed 1987, leaked 1994) is a stream cipher: the key schedules a 256-byte permutation (KSA), then the permutation emits a pseudorandom byte stream (PRGA) that is XORed with the message. No padding, no block size, any message length, trivially fast in software — which is why it dominated SSL/TLS and WEP in the 1990s. "ARCFOUR" is the trademark-free name most open-source projects use.

How it broke. Fluhrer-Mantin-Shamir (2001) showed the first bytes of the keystream are biased — fatal in WEP, whose per-packet key construction fed those bytes to attackers. Later bias attacks (2013, AlFardan et al.) recovered plaintext from RC4-protected TLS sessions with millions of connections. RFC 7465 (2015) prohibits RC4 in TLS outright.

The classic vector. Key "Key" (3 bytes), message "Plaintext" gives ciphertext bbf316e8d940af0ad3 — try the RC4 Sample and compare. This page's self-test also checks the RFC 6229 keystream for the 40-bit key 01 02 03 04 05: b2396305f03dc027ccc3524a0a1118a8.

Blowfish: unbroken, but block-limited

What it is. Bruce Schneier's 1993 Feistel cipher: 64-bit blocks, keys from 32 to 448 bits (4..56 bytes), 16 rounds, and a famous key schedule that runs Blowfish itself 521 times to build its subkeys — which makes key setup slow but brute-force attempts expensive too. No practical cryptanalysis breaks full-round Blowfish.

Why it is on this page anyway. The 64-bit block is the problem, not the algorithm: past ~32 GiB under one key, birthday collisions leak data (same bound as 3DES, Sweet32-style). Schneier himself recommends his successor Twofish (an AES finalist) or AES for anything new. Blowfish lives on inside bcrypt — the password hash's key schedule is Blowfish — which is fine, because hashing uses tiny inputs, not gigabytes.

The classic vectors. All-zero key and all-zero plaintext encrypt to 4ef997456198dd78 (first block of the Sample output); key "abcdefghijklmnopqrstuvwxyz" on "BLOWFISH" gives 324ed0fef413a203. Both come from Schneier's published vector file and are checked by the self-test.

Common mistakes
  • Using these for new data. Every cipher on this page is deprecated except Blowfish (which is block-size-limited). The correct modern choice is AES-GCM — see AES Encrypt / Decrypt.
  • DES key from a password. An 8-character password is not 56 random bits; it is a few bits of entropy per character. Old systems did exactly this and it is the most common reason "DES-encrypted" archives fall to dictionary attacks in minutes.
  • Reusing an IV in CBC. The first block then leaks plaintext equality across messages under the same key. The Random IV button exists for a reason.
  • Reusing an RC4 keystream. RC4 XORs the same keystream for the same key: encrypting two messages with one key is a two-time pad — XOR the ciphertexts and both plaintexts fall out. WEP's fatal flaw was exactly a keystream-reuse construction.
  • Assuming "it decrypts, so it's right". ECB/CBC here validate only padding on decrypt — a wrong key usually strips to garbage that may still unpad. There is no integrity check in any legacy mode; if you need one, you need AES-GCM, not these.
  • Counting 3DES as "168-bit". The raw key is 168 bits but the effective strength is 112 — meet-in-the-middle reduces triple encryption to double plus change, exactly as it does for 3DES's ancestor constructions.
FAQ

Why keep a broken-cipher tool at all? Compatibility. Encrypted backups, exported old-format files, captured protocol traces, CTF challenges and hardware that cannot be upgraded all still speak these ciphers. Reading old data is legitimate; writing new data with them is not.

My DES key has odd parity / non-ASCII bytes. DES ignores each key byte's parity bit, so the effective key is the other 56 bits regardless. This page accepts any 8 bytes and does not enforce even parity.

Why does decrypted text sometimes look like garbage? Wrong key, wrong mode, wrong IV, or the data was not encrypted the way you assume. With no authentication tag there is no clean "wrong key" error — the padding check is the only hint, and it can pass by luck (1/256 of the time).

Is Blowfish safe for my files? For small files, cryptographically yes (no practical break). For anything gigabyte-scale under a single key, no — the 64-bit block birthday bound is about data volume, not key strength. Twofish or AES avoid the issue.

What about the 72-byte Blowfish keys I saw somewhere? Some implementations accept up to 72 bytes, but Schneier's reference uses 56 and bytes beyond that give no additional diffusion in the standard schedule. This page follows the reference: 4..56 bytes.