The RC4 Stream Cipher

Introduction

RC4 (“Rivest Cipher 4”) was designed by Ron Rivest in 1987 for RSA Security. Unlike the block ciphers covered elsewhere on this site, RC4 is a stream cipher — instead of processing data in fixed-size blocks, it generates a continuous pseudorandom byte stream that’s simply XORed with the plaintext, byte by byte. Its extreme simplicity made it enormously fast in software and, for over a decade, RC4 was the default cipher behind SSL/TLS, WEP, and WPA. It’s also now considered broken, and understanding exactly why is a great lesson in why “simple and fast” isn’t the same as “secure.”

Table of Contents

• How RC4 Works
• The Key-Scheduling Algorithm (KSA)
• The Pseudo-Random Generation Algorithm (PRGA)
• A Worked Example
• Why RC4 Is Broken
• RC4’s Legacy
• FAQ
• References

How RC4 Works

RC4 operates in two phases:

1. Key-Scheduling Algorithm (KSA): uses the secret key to scramble a 256-byte internal state array into a key-dependent permutation.
2. Pseudo-Random Generation Algorithm (PRGA): repeatedly shuffles that state array to spit out one keystream byte at a time, which the sender XORs with plaintext to encrypt (and the receiver XORs with ciphertext to decrypt — XOR is its own inverse, so encryption and decryption are literally the same operation).

The Key-Scheduling Algorithm (KSA)

for i = 0 to 255:
    S[i] = i

j = 0
for i = 0 to 255:
    j = (j + S[i] + key[i mod key_length]) mod 256
    swap(S[i], S[j])

This initializes S as the identity permutation, then uses the key to shuffle it — every key produces a different, unpredictable-looking permutation of the 256 possible byte values.

The Pseudo-Random Generation Algorithm (PRGA)

i = 0
j = 0
for each byte of plaintext:
    i = (i + 1) mod 256
    j = (j + S[i]) mod 256
    swap(S[i], S[j])
    keystream_byte = S[(S[i] + S[j]) mod 256]
    ciphertext_byte = plaintext_byte XOR keystream_byte

Each iteration continues shuffling the state array and emits one keystream byte, for as many bytes as the message requires — RC4 can encrypt a stream of any length, with no padding, no block boundaries, and almost no computational overhead.

Interactive Visualizer

The visualizer above runs genuine RC4 — real KSA, real PRGA — and matches the classic published RC4 test vectors exactly (try the default key “Key” and plaintext “Plaintext”: you should see ciphertext bbf316e8d940af0ad3, the standard reference value used to validate RC4 implementations).

A Worked Example

Using one of RC4’s most commonly cited reference test vectors:

• Key: “Key”
• Plaintext: “Plaintext”
• Ciphertext: bb f3 16 e8 d9 40 af 0a d3

Why RC4 Is Broken

RC4’s downfall wasn’t a single catastrophic flaw — it was a slow accumulation of statistical biases discovered over roughly two decades:

• Biased keystream bytes: Early bytes of RC4’s keystream are measurably non-random — the very first byte, for instance, is 0 far more often than the 1-in-256 chance a truly random byte would be. Given enough ciphertexts encrypted under related keys, these biases leak information about the plaintext.
• The FMS attack (2001): Fluhrer, Mantin, and Shamir showed that RC4’s KSA leaks information about the key itself when keys are related in the way WEP generated them (a short fixed secret combined with a public, changing initialization vector), enabling full key recovery from a modest number of captured packets — this attack alone made WEP practically breakable within minutes.
• Broadcast and bias attacks (2013-2015): Researchers demonstrated increasingly practical attacks recovering plaintext (including session cookies) from RC4-protected TLS traffic given enough repeated encryptions of the same data, exploiting the same class of keystream biases at internet scale.

By 2015, RFC 7465 formally prohibited RC4 in TLS entirely, and every major browser and server has since removed support.

RC4’s Legacy

RC4’s story is a case study in why cryptographic transitions take so painfully long: it was known to have theoretical weaknesses years before it was actually removed from real-world protocols, because ripping out a cipher used everywhere is slow, risky, compatibility-sensitive work. Its replacement in modern TLS is almost always ChaCha20, which was specifically designed to offer RC4’s core appeal — fast, simple, efficient in pure software without special hardware — while being built from the start to resist exactly the kind of statistical attacks that eventually killed RC4.

FAQ

Is RC4 still used anywhere?

It’s been formally prohibited in TLS since 2015 (RFC 7465) and removed from virtually all modern browsers, servers, and libraries. Any system still using it should migrate to AES-GCM or ChaCha20-Poly1305 immediately — RC4 offers no meaningful security today.

Why was RC4 so popular before it was broken?

It’s extraordinarily simple to implement, extremely fast in software (especially compared to block ciphers on 1990s and 2000s hardware), and requires no padding since it’s a pure stream cipher — a very attractive combination before its statistical weaknesses were fully understood.

What exactly made WEP so vulnerable?

WEP combined a short static key with a small, frequently repeating public initialization vector (IV) in a way that fed RC4 related keys across many packets, which the FMS attack could exploit to recover the static key directly from captured traffic — a flaw in how WEP used RC4, compounded by weaknesses in RC4’s KSA itself.

What replaced RC4?

In TLS, RC4 was replaced primarily by AES-GCM and later ChaCha20-Poly1305 — both authenticated encryption schemes that provide integrity protection RC4 never had, on top of much stronger confidentiality guarantees.

Is RC4 a block cipher or a stream cipher?

Stream cipher — it generates a continuous keystream and XORs it with plaintext one byte at a time, with no fixed block size, unlike AES, DES, or the other ciphers covered elsewhere on this site.

References

1. Rivest, R. RC4 was originally a trade secret; details became public in 1994 when source code was leaked to the Cypherpunks mailing list.

2. Fluhrer, S., Mantin, I., and Shamir, A. “Weaknesses in the Key Scheduling Algorithm of RC4.” SAC 2001 (the original FMS attack paper).

3. RFC 7465. “Prohibiting RC4 Cipher Suites.” IETF, 2015. Available at: https://datatracker.ietf.org/doc/html/rfc7465

4. Wikipedia. “RC4.” Available at: https://en.wikipedia.org/wiki/RC4