RC4 was the most used cipher on the internet in 2013. By 2015 it was banned in TLS. By 2026 Microsoft is removing it from Kerberos. Here is how RC4 worked and why it fell.
In 2013, RC4 was the most used cipher on the internet. By 2015, it was banned in TLS. By 2026, Microsoft is removing it from Kerberos authentication. The fall took less time than the rise.
Ron Rivest designed RC4 in 1987 at RSA Data Security. The algorithm was kept as a trade secret until 1994, when someone posted the source code anonymously to the Cypherpunks mailing list. From that point, RC4 spread everywhere: WEP Wi-Fi encryption, TLS, Microsoft Kerberos, Adobe PDF. You can still experiment with it using the RC4 cipher tool for educational purposes.
RC4 has two phases: the Key Scheduling Algorithm (KSA) and the Pseudo-Random Generation Algorithm (PRGA).
Key Scheduling Algorithm (KSA): Initialize a 256-byte array S with values 0 to 255. Then permute the array using the key:
``
for i = 0 to 255:
S[i] = i
j = 0
for i = 0 to 255:
j = (j + S[i] + key[i mod keylength]) mod 256
swap(S[i], S[j])
``
Pseudo-Random Generation Algorithm (PRGA): Generate one keystream byte at a time by continuously permuting S and reading from it:
``
i = 0, j = 0
while bytes needed:
i = (i + 1) mod 256
j = (j + S[i]) mod 256
swap(S[i], S[j])
output S[(S[i] + S[j]) mod 256]
``
Each keystream byte is XORed with one plaintext byte. The cipher is simple, fast, and requires no padding. It processes data one byte at a time, making it a textbook stream cipher. The entire algorithm fits in under 30 lines of code.
The simplicity is what made RC4 attractive. It was fast on 1990s hardware, easy to implement in software, and required no hardware acceleration. RSA Security licensed it widely, and after the 1994 leak, open-source implementations appeared in every cryptographic library.
RC4's problem is that its keystream is not uniformly random. The KSA produces statistical biases that leak information about the plaintext.
First-byte bias: The second output byte of RC4 is biased toward zero with probability approximately 2/256 instead of 1/256. This was first described by Itsik Mantin and Adi Shamir in 2001. The bias occurs because the KSA leaves certain array positions correlated with the key in a predictable way.
Fluhrer-Mantin-Shamir (FMS) attack (2001): The FMS paper showed that the first bytes of the RC4 keystream are biased in a way that depends on the key. This allowed attackers to recover WEP keys by collecting enough encrypted packets. WEP used RC4 with a 24-bit initialization vector prepended to the key, and the FMS attack exploited the fact that different IVs produced predictable biases in the first keystream bytes. The attack required about 4 million packets to recover a 104-bit WEP key.
Royal Holloway attack (2013): Daniel J. Bernstein and colleagues at Royal Holloway, University of London, demonstrated that RC4 biases in TLS could recover session cookies in about 72 hours of sustained connection. The attack exploited the fact that the first 256 bytes of the RC4 keystream have measurable biases. By causing a browser to make many TLS connections to the same server (using JavaScript), the attacker could collect enough ciphertext samples to statistically recover the cookie value byte by byte.
The RFC 7465 specification, published in February 2015, cited these results and prohibited all RC4 cipher suites in TLS. The RFC states: "RC4 can no longer be seen as providing a sufficient level of security for TLS sessions."
RC4's removal took years and happened in stages across the industry.
2015: RFC 7465 prohibited RC4 in TLS. The IETF required that TLS clients and servers never negotiate RC4 cipher suites. All four major browser families (Chrome, Firefox, Safari, Edge) had already disabled RC4 by default before the RFC was published. Firefox removed the ability to re-enable RC4 entirely in version 50 (November 2016). Chrome removed the group policy override in version 53.
2016: Microsoft removed RC4 support from Internet Explorer 11 and Edge via a Windows security update. The update aligned Microsoft browsers with Chrome and Firefox.
2022-2026: Microsoft began deprecating RC4 in Kerberos. In November 2022, CVE-2022-37966 changed the default Kerberos encryption type from RC4 to AES-SHA1. In December 2025, Microsoft announced a phased rollout to fully remove RC4 from Kerberos defaults. The January 2026 Windows Update introduced audit mode. The April 2026 update moved to enforcement mode, blocking RC4 for accounts without explicit configuration. The July 2026 update removes the rollback option entirely. This is tracked under CVE-2026-20833.
The Kerberoasting attack, which targets service tickets encrypted with RC4, was a primary motivation for the Kerberos deprecation. Attackers capture RC4-encrypted service tickets and crack them offline. AES-encrypted tickets are resistant to this attack because AES does not have the same key-dependent biases.
You can still experiment with RC4 using the RC4 cipher tool, but it is provided strictly for education and legacy analysis. No production system should use RC4.
Two AEAD constructions replaced RC4 in TLS: AES-GCM and ChaCha20-Poly1305.
AES-GCM: AES in Galois/Counter Mode turns the AES block cipher into a stream cipher using CTR mode and adds authenticated encryption via GMAC. It is the default choice for TLS on devices with AES-NI hardware acceleration. You can test it with the block cipher tool.
ChaCha20-Poly1305: Defined in RFC 8439, ChaCha20 is a dedicated stream cipher designed by Daniel J. Bernstein. It avoids the bias problems of RC4 by using a more complex quarter-round function based on add-rotate-XOR operations. Poly1305 provides authentication. ChaCha20-Poly1305 is preferred on mobile devices and other hardware without AES acceleration.
TLS 1.3 (now specified in RFC 9846, published July 2026) offers only these two families across five AEAD cipher suites. RC4, CBC mode, and non-AEAD constructions are all removed from the protocol. There is no way to configure TLS 1.3 to use a weak cipher, which is the deeper design improvement over TLS 1.2.
RC4's weaknesses are inherent to the algorithm, not to any particular implementation. The KSA produces a biased permutation regardless of the key. No amount of key strengthening or IV management can fix the fundamental statistical biases in the keystream.
The WEP protocol tried to work around RC4's biases by prepending an IV to the key, but this made the FMS attack possible. The TLS implementation tried discarding the first 1024 bytes of keystream (the RSA Security recommendation), but the Royal Holloway attack showed that biases persist beyond the first 256 bytes and are exploitable even with discard.
RC4 is a cautionary tale about simplicity without security analysis. The algorithm was used for 26 years before the cryptographic community fully characterized its biases. Modern stream ciphers like ChaCha20 were designed with bias resistance from the start and have withstood years of analysis without comparable weaknesses being found.
RC4 is still found in legacy systems. Microsoft is phasing it out of Kerberos through 2026, with full enforcement by July 2026. Some old WEP Wi-Fi networks still use it. No modern TLS implementation supports it. The RC4 cipher tool on this site is provided for education only.
RC4 was fast, simple, and required no hardware acceleration. The algorithm fit in under 30 lines of code. It was a trade secret until 1994, which gave it an air of exclusivity, and after the source code leaked, free implementations appeared everywhere. For 1990s hardware, it was the fastest stream cipher available.
The Fluhrer-Mantin-Shamir attack (2001) exploits biases in the first bytes of the RC4 keystream when the key is prepended with a known IV, as in WEP. By collecting enough packets with different IVs, an attacker can recover the secret key. The attack requires about 4 million WEP packets to recover a 104-bit key.
AES-GCM and ChaCha20-Poly1305 replaced RC4 in TLS. Both provide authenticated encryption (confidentiality and integrity in one operation). TLS 1.3 offers only these two families across five AEAD cipher suites, with no option to negotiate weaker algorithms.
No. Discarding the first 1024 bytes of keystream was recommended by RSA Security to reduce early-byte biases, but the Royal Holloway attack (2013) showed that biases persist beyond the first 256 bytes and remain exploitable. The fundamental weakness is in the KSA permutation, not just the early output.
RC4 Stream Cipher
Encrypt and decrypt data with the RC4 stream cipher using a variable-length key. For education and legacy analysis only.
Block Cipher (AES / DES)
Encrypt and decrypt with AES-128, AES-256, DES, and Triple DES using GCM, CBC, and ECB modes. AES uses the Web Crypto API.
Vernam Cipher (One-Time Pad)
Encrypt and decrypt text using the Vernam cipher, the XOR-based one-time pad that Shannon proved is perfectly secure.
The Difference Between Encoding, Encryption, and Hashing
Base64 is not encryption. This guide defines encoding, encryption, and hashing precisely, runs the same input through each, and explains when to use which in production systems.
Stream Ciphers vs. Block Ciphers: What's the Difference?
A block cipher encrypts in fixed-size chunks. A stream cipher encrypts one byte at a time. The difference changes everything from padding to nonce reuse. Here is how they compare.
