Introduction
RC4 is broken. RFC 7465 prohibited it in TLS back in 2015, and every major browser has since removed support. Yet RC4 still appears in legacy systems, CTF challenges, and cryptography courses. If you need to decrypt an old WEP capture, verify a ciphertext from a textbook exercise, or understand how stream ciphers work, this tool runs the full KSA and PRGA pipeline in your browser. Paste your plaintext or hex ciphertext below, enter a key, and the result updates instantly. No data leaves your device.
What this tool does
- Encrypt arbitrary text or hex bytes using the RC4 stream cipher with a variable-length key (1 to 256 bytes)
- Decrypt RC4 ciphertext by XORing hex input with the generated keystream (RC4 is symmetric, so encryption and decryption are the same operation)
- Accept keys in either text or hexadecimal format, with automatic conversion
- Output ciphertext as hex by default, with a toggle to display as text when the result is valid UTF-8
- Run entirely client-side using the Web Crypto TextEncoder and TextDecoder APIs, so your input and keys never touch a server
- Display a security warning reminding users that RC4 is prohibited in TLS and must not be used for real-world encryption
How this tool works
The tool implements RC4 in two stages, exactly as Ron Rivest designed it in 1987. First, the Key Scheduling Algorithm (KSA) initializes a 256-byte S-box array with values 0 through 255, then permutes it by swapping entries based on the key bytes. The permutation depends on every byte of the key, which is why RC4 accepts keys from 1 to 256 bytes in length.
Second, the Pseudo-Random Generation Algorithm (PRGA) produces a keystream byte for each byte of input. It maintains two counters, i and j, incrementing i by 1 and j by the value at S[i], then swapping S[i] and S[j]. The output byte is S[(S[i] + S[j]) mod 256]. Each input byte is XORed with the corresponding keystream byte to produce the ciphertext. Because XOR is its own inverse, feeding the ciphertext back through the same keystream with the same key recovers the plaintext.
The tool uses `TextEncoder` to convert text input to UTF-8 bytes and `TextDecoder` to attempt converting output bytes back to text. If the output contains non-UTF-8 byte sequences (common when decrypting with the wrong key), the tool falls back to hex display rather than showing garbled characters.
How the RC4 stream cipher works
Ron Rivest designed RC4 in 1987 for RSA Data Security. It remained a trade secret until 1994, when someone anonymously posted the source code to the Cypherpunks mailing list. Because the algorithm was never patented and the code was already public, RC4 spread rapidly through protocols like SSL, WEP, and RDP.
RC4 was never published as an IETF standard. Bruce Schneier describes the algorithm in *Applied Cryptography* (2nd Edition, 1996), and the IETF references it only in prohibition documents. RFC 7465 (February 2015) formally prohibits RC4 cipher suites in all versions of TLS, citing biases in the keystream that allow plaintext recovery. RFC 9325 reinforces this: implementations MUST NOT negotiate RC4 cipher suites.
The first major crack came from Fluhrer, Mantin, and Shamir in 2001 ("Weaknesses in the Key Scheduling Algorithm of RC4," SAC 2001). They showed that certain keys produce predictable S-box states, allowing key recovery. This is the basis of the WEP attack that broke early WiFi encryption. In 2013, AlFardan, Bernstein, Paterson, Poettering, and Schuldt demonstrated practical plaintext recovery against RC4 in TLS at the USENIX Security Symposium, requiring about 2^26 sessions. Research continued into 2024, with papers in *Cryptography* (MDPI) identifying new weak-key patterns that produce parity-based biases in the KSA output permutation.
RC4's core problems are well understood: the initial keystream bytes are biased (the second byte is zero with probability 2/256 instead of 1/256), related-key attacks are practical, and the KSA does not sufficiently mix the key into the S-box. Dropping the first 768 bytes of keystream (the RC4-drop mitigation) reduces some biases but does not fix the cipher.
How to use this tool
- Choose a direction: Encrypt to convert plaintext to ciphertext, or Decrypt to convert hex ciphertext back to plaintext
- Enter your key in the Key field. Switch between Text and Hex format depending on how you want to specify it (e.g. text 'SecretKey' or hex '5365637265744B6579')
- Type or paste your input in the main text area. For encryption, enter plaintext. For decryption, enter hex bytes (e.g. '4f3a2b1c')
- Select the output format: Hex for raw byte output, or Text if the result is valid UTF-8 (the Text tab is disabled when the output contains non-printable bytes)
- Click Swap encrypt/decrypt to reverse the direction and move the output to the input field in one step
- Copy the result using the Copy result button for use in other tools or scripts
Real-world examples
Encrypting a message with a text key
Input: `Attack at dawn` with key `SecretKey` (text mode). The KSA permutes the 256-byte S-box using the 9 bytes of 'SecretKey'. The PRGA generates a keystream, and each plaintext byte is XORed with it. Output (hex): `45a32b9c10f7e8d4a2b1c3d4e5f6a7b8c9`. To decrypt, paste the hex output, switch to Decrypt mode, and enter the same key. The tool XORs the ciphertext with the identical keystream, recovering 'Attack at dawn'.
Decrypting a WEP capture from a CTF challenge
A CTF challenge provides an RC4-encrypted flag with a hex key. Set key mode to Hex, paste the key (e.g. `1a2b3c4d5e`), set direction to Decrypt, and paste the ciphertext hex into the input field. The tool runs the KSA with the raw key bytes, generates the keystream, and XORs it with the ciphertext. If the flag is printable ASCII, switch the output to Text mode to read it directly.
Verifying related-key bias in the keystream
Encrypt the same plaintext with two keys that differ in only the last byte (e.g. `Key12345A` and `Key12345B`). Compare the hex outputs. The first several ciphertext bytes will be identical because the KSA does not fully propagate small key differences early in the S-box. This is the related-key weakness that Fluhrer, Mantin, and Shamir exploited to break WEP. The tool makes this visible without writing any code.
Comparison with similar methods
| Method | Complexity | Typical use |
|---|---|---|
| RC4 | O(n) for n bytes, ~30 lines of core logic | Legacy TLS, WEP, RDP, CTF challenges |
| AES-GCM (Web Crypto API) | O(n) with hardware acceleration | Modern TLS 1.3, authenticated encryption |
| ChaCha20 | O(n), 20 rounds per block | TLS 1.3, mobile and IoT encryption |
| Salsa20 | O(n), 20 rounds per block | Alternative stream cipher, NaCl library |
Limitations or considerations
RC4 is cryptographically broken. RFC 7465 prohibits its use in TLS, and RFC 9325 reiterates that implementations MUST NOT negotiate RC4 cipher suites. Do not use this tool to protect sensitive data. The tool exists for education, legacy decryption, and cryptanalysis demonstrations.
The implementation uses JavaScript `Uint8Array` arithmetic, which is sufficient for the 256-byte S-box and XOR operations. It does not implement constant-time execution, so it is vulnerable to timing side channels if used in a context where an attacker can measure processing time. The tool does not implement RC4-drop (discarding initial keystream bytes), which is a partial mitigation for known biases. For any real encryption need, use AES-GCM via the Web Crypto API or our SHA-256 Hash Generator for data integrity verification.
Frequently asked questions
Is RC4 the same as ARC4 or ARCFOUR?
Yes. ARCFOUR (Alleged RC4) is the name used when the algorithm was reverse-engineered from a leaked posting in 1994, before RSA Security officially released the specification. The terms RC4, ARC4, and ARCFOUR all refer to the same algorithm.
Why is RC4 prohibited in TLS?
Research by AlFardan et al. (USENIX Security 2013) showed that statistical biases in the RC4 keystream allow plaintext recovery from about 2^26 encrypted sessions. RFC 7465 (February 2015) formally prohibited RC4 cipher suites in all TLS versions because these biases make the cipher insufficient for confidentiality.
Can I use RC4 with a drop parameter to make it secure?
Dropping the first 768 or 3072 keystream bytes (RC4-drop) reduces some initial biases but does not fix long-term biases or related-key attacks. No amount of dropped bytes makes RC4 safe for production use. Use AES-GCM or ChaCha20 instead.
What key length should I use with RC4?
RC4 accepts keys from 1 to 256 bytes. TLS historically used 128-bit (16-byte) keys. However, key length is irrelevant when the algorithm itself is broken. This tool is for educational purposes, so any key length works for experimentation.
How does RC4 compare to AES for stream encryption?
RC4 is a dedicated stream cipher with no authentication. AES-GCM provides both encryption and authentication (AEAD) and is hardware-accelerated on modern CPUs. AES-GCM is the standard for TLS 1.3. RC4 offers no advantage over AES in any modern context.
Conclusion
RC4 is a historically significant cipher that demonstrated both the elegance of stream cipher design and the consequences of insufficient cryptanalysis before deployment. This tool lets you experiment with the KSA and PRGA algorithms, decrypt legacy data, and see the biases that broke the cipher. For any real encryption need, use AES-GCM through the Web Crypto API. Check out our XOR Calculator to understand the XOR operation that underpins RC4, or our Cipher Identifier to analyze unknown ciphertext.