RC4 (Rivest Cipher 4) is a symmetric-key stream cipher designed by Ron Rivest in 1987. It encrypts data one byte at a time and was once widely used in SSL/TLS, WEP, and other protocols for its speed and simplicity. RC4 is no longer secure: serious flaws led to it being prohibited in TLS in 2015.
RC4 (Rivest Cipher 4) is a symmetric-key stream cipher created by Ron Rivest in 1987 that encrypts data one byte at a time. Once popular in SSL/TLS, WEP, and wireless standards for its speed and simplicity, RC4 is now considered insecure. Multiple attacks exploit biases in its keystream, and it was formally prohibited in TLS in 2015. It should not be used.
Key Takeaways
- RC4 (Rivest Cipher 4) is a symmetric stream cipher designed by Ron Rivest in 1987, encrypting data one byte at a time.
- It was widely used in SSL/TLS, the WEP Wi-Fi protocol, and IEEE 802.11 because it was fast and simple.
- RC4 is not secure: keystream biases, weak initial bytes, the FMS attack, and the Bar Mitzvah attack all undermine it.
- RFC 7465 (2015) formally prohibited RC4 in TLS; NIST and every major standard discourage or forbid it.
- RC4’s weakness is classical, not quantum, so post-quantum computing is not the issue; it should already be disabled everywhere.
What Is RC4?
RC4, also known as Rivest Cipher 4, is a symmetric-key stream cipher designed by Ron Rivest in 1987. A stream cipher encrypts data one byte at a time, rather than in fixed blocks. RC4 was one of the most widely used stream ciphers, appearing in SSL/TLS, the IEEE 802.11 wireless LAN standard, and the WEP (Wired Equivalent Privacy) Wi-Fi security protocol. Its popularity came from its ease of implementation and fast performance. Today, serious flaws mean RC4 has been almost entirely retired.
Is RC4 Secure? The Vulnerabilities
No. RC4 is not recommended for any modern use because of several well-established weaknesses:
- Key scheduling biases: RC4’s key scheduling algorithm produces statistical biases in the keystream. An attacker can exploit these to deduce information about the key and recover parts of the plaintext.
- Weak initial keystream bytes: The first bytes RC4 generates are especially biased, and those biases can be used to predict or guess portions of the plaintext.
- Fluhrer, Mantin, and Shamir (FMS) attack: A landmark attack that targets the biases in the initial keystream to recover parts of the key. It famously broke the WEP Wi-Fi protocol, which relied on RC4.
- Bar Mitzvah attack: Disclosed in 2015, this attack exploits keystream biases (the ‘invariance weakness’) to recover portions of plaintext when RC4 is used in certain protocols and configurations.
- Ongoing cryptanalysis: RC4’s security has only degraded over time as more attacks have been found. Once weaknesses like these are known, they do not go away, they get easier to exploit.
RC4 Was Formally Banned in TLS
The decisive milestone came in February 2015, when the IETF published RFC 7465, which formally prohibits the use of RC4 cipher suites in TLS. Browsers and servers followed by disabling RC4 entirely. NIST and standards like PCI DSS also discourage or forbid it. In practical terms, RC4 has been off the table for secure communication for a decade, and any system still offering it is exposing a known, exploitable weakness.
Advantages and Disadvantages of RC4
| Advantages (historical) | Disadvantages (why it is retired) |
| Simple to implement | Biased initial output bytes leak information |
| Fast and efficient | Key can be recovered from enough keystream |
| Handles large data streams quickly | No built-in authentication (vulnerable to MITM and tampering) |
The advantages are why RC4 was popular in the 1990s and 2000s. The disadvantages are why it has been abandoned: speed is no substitute for security, and modern ciphers like AES-GCM and ChaCha20-Poly1305 are both fast and secure.
How Do I Disable RC4 on My Server?
If any of your systems still offer RC4, disable it. On Windows, RC4 is turned off through the SCHANNEL registry: for each RC4 cipher width (RC4 128/128, RC4 56/128, and RC4 40/128), set the cipher’s Enabled value to 0 under the SCHANNEL Ciphers key, then reboot. With those set, the system will no longer negotiate an RC4 cipher suite for either inbound or outbound connections. (Microsoft documents the exact SCHANNEL registry paths for disabling weak ciphers.)
On Linux and other platforms, remove RC4 from the cipher configuration of your web server or TLS library (for example, excluding RC4 from the OpenSSL cipher string). More broadly, use only modern, strong cipher suites, which keeps you aligned with standards like NIST and PCI DSS and closes off RC4’s known weaknesses.
Is RC4 Still Secure in 2026? And What About Quantum?
No. As of 2026, RC4 is considered broken and should not be used anywhere. Unlike algorithms such as AES, RSA, and ECC, whose security is being reassessed for the quantum era, RC4’s problem is not quantum computing at all, it is already defeated by ordinary, classical attacks and has been prohibited in TLS since 2015. Quantum computers are irrelevant to RC4 because it does not need one to be broken.
The post-quantum transition concerns the algorithms that are secure today but vulnerable to future quantum attacks, principally RSA and ECC for key exchange and signatures. For those, NIST finalized post-quantum standards in August 2024 (ML-KEM, ML-DSA, and SLH-DSA) and its draft guidance points to retiring RSA and ECC around 2030 to 2035. AES-256 remains quantum-resistant. RC4 simply belongs to an earlier problem: it should have been removed long before quantum ever became a concern.
How Encryption Consulting Helps
Finding and removing weak algorithms like RC4, and moving to strong, compliant cryptography, is core to Encryption Consulting’s Encryption Advisory Services. Through our Encryption Assessment, we identify where high-risk data and outdated algorithms live, verify encryption against standards like NIST and FIPS 140-3, and provide a clear remediation plan, including retiring ciphers like RC4 and planning for the post-quantum transition of RSA and ECC. Backed by ISO/IEC 27001:2022 and SOC 2 certified practices.
Frequently Asked Questions
What is RC4?
RC4 (Rivest Cipher 4) is a symmetric-key stream cipher designed by Ron Rivest in 1987. It encrypts data one byte at a time, which made it fast and simple to implement. RC4 was once widely used in SSL/TLS, the WEP Wi-Fi protocol, and the IEEE 802.11 wireless standard. Because of serious cryptographic weaknesses discovered over the years, RC4 is now considered insecure and has been retired from modern use.
Is RC4 secure?
No. RC4 is not secure and should not be used. It suffers from statistical biases in its keystream, particularly in the initial bytes, that allow attacks such as the Fluhrer, Mantin, and Shamir (FMS) attack and the Bar Mitzvah attack to recover parts of the key or plaintext. It also lacks built-in authentication. RFC 7465 formally prohibited RC4 in TLS in 2015, and NIST and other standards discourage or forbid it.
Why is RC4 considered insecure?
RC4 is insecure because its key scheduling algorithm produces biases in the keystream, and its first output bytes are especially weak. Attackers can exploit these biases to deduce key information and recover plaintext. Well-known attacks include the FMS attack, which broke the WEP Wi-Fi protocol, and the 2015 Bar Mitzvah attack. RC4 also provides no message authentication, leaving it open to tampering. These flaws are practical, not just theoretical, which is why RC4 was banned.
When was RC4 banned or deprecated?
The decisive step was February 2015, when the IETF published RFC 7465, formally prohibiting RC4 cipher suites in TLS. Around the same time, major browsers and servers disabled RC4 by default. NIST had already discouraged its use, and standards such as PCI DSS require strong cipher suites that exclude it. In short, RC4 has been off-limits for secure communication since roughly 2015.
How do I disable RC4 on my server?
On Windows, disable RC4 through the SCHANNEL registry by setting the ‘Enabled’ value to 0 for each RC4 cipher width (RC4 128/128, 56/128, and 40/128), then rebooting, so the system will not negotiate an RC4 cipher suite. On Linux or other platforms, remove RC4 from your web server or TLS library’s cipher configuration (for example, excluding it from the OpenSSL cipher string). The broader goal is to offer only modern, strong cipher suites.
Does quantum computing affect RC4?
Not in any meaningful way. RC4 is already broken by ordinary classical attacks and has been prohibited in TLS since 2015, so quantum computing is not the concern for RC4. The post-quantum transition focuses on algorithms that are secure today but vulnerable to future quantum computers, mainly RSA and ECC. For those, NIST finalized post-quantum standards in 2024. RC4 simply belongs to an earlier generation of broken cryptography that should already be gone.
Retire Weak Ciphers Like RC4
If RC4 is still offered anywhere in your environment, it is a known, exploitable weakness. Explore Encryption Consulting’s Encryption Advisory Services to discover outdated algorithms, retire them, and move to strong, standards-aligned, quantum-ready cryptography.