In short

Do not use RC4 anywhere. Its keystream is biased, so a secret repeated across many encryptions, such as a cookie, can be recovered statistically even though every connection uses a fresh key. RFC 7465 has prohibited RC4 in TLS since 2015. Offer only TLS 1.3 and TLS 1.2 AEAD suites, replace RC4 in custom formats with an AEAD, and move Active Directory Kerberos accounts from RC4 to AES.

  • RC4 output is not uniform: some bytes and byte pairs appear more often than they should.
  • Bias attacks need many encryptions of the same secret, not a reused key.
  • Fresh keys, dropped initial bytes and shuffled padding do not make RC4 safe.
  • RFC 7465 prohibits RC4 cipher suites in TLS; current configuration profiles contain none.
  • Kerberos RC4 tickets enable offline password cracking (Kerberoasting); Microsoft is moving domain controllers to AES-only defaults.

Verify it

  1. Run testssl.sh --rc4 host:443 against every TLS endpoint, including mail, VPN and management interfaces.
  2. Offer only RC4 from a test client and confirm the handshake fails.
  3. In Active Directory, run Microsoft’s Get-KerbEncryptionUsage.ps1 -Encryption RC4 and confirm no tickets use RC4.
  4. Search the codebase and dependencies for RC4, ARC4 and ARCFOUR.
Applies to

Historical stream-cipher weaknesses and retirement of legacy protocols. RC4 is not a current implementation choice.

Fix it in your stack

Tested fixes: the vulnerable code, the fix, a plausible fix that still fails, and the regression tests that tell them apart.

Learning goals and prerequisitesAbout 17 minutes: 4 to read and 13 for the exercise

What you will learn

  • Explain statistical plaintext inference from a biased keystream.
  • Distinguish independent keys from keystream reuse.
  • Verify removal through negotiated behavior.

Before you start

Engineers who retire legacy protocols and cipher suites, and reviewers who need to explain why RC4 is not allowed.

  • Understand a keystream and XOR; distinguish repeated keys from statistical bias.
Go to the guided practice

XOR hides a message only as well as the keystream does

A stream cipher encrypts each byte as C=P XOR Z, where Z is a keystream byte. If Z is independently uniform over all 256 byte values, observing C reveals no preference among candidate values of P. RC4’s key scheduling and output generation produce distributions that deviate from this ideal. Some individual bytes and byte pairs occur with detectable biases.

Suppose, purely for a four-value teaching model, a keystream value 0 occurs 50% of the time and 1, 2, 3 each occur one sixth of the time. If the same secret P=2 is repeatedly encrypted at that position with fresh keys, ciphertext 2 occurs about half the time because 2 XOR 0=2. Repetition reveals the likely secret statistically. No two sessions need to use the same key.

Real RC4 biases are much smaller and more complicated than that toy distribution. Research attacks combine observations over many encryptions, align repeated secret bytes at useful positions, and score candidate plaintexts. This is different from two-time-pad reuse: with an exactly reused keystream, C₁ XOR C₂=P₁ XOR P₂ immediately; bias attacks aggregate many noisy samples even when keystreams differ. WEP’s repeated keystreams (/domains/identity-crypto/encryption/wep-rc4-key-reuse/) are the reuse case.

Repetition, alignment, and observations determine the attack

A practical TLS scenario can repeatedly send a secret cookie alongside predictable request fields. An attacker who can induce traffic and observe encrypted connections may accumulate useful samples. The published RC4-in-TLS research describes concrete assumptions and sample requirements; supporting RC4 does not imply that every captured connection can be decrypted instantly.

Changing request padding can move the secret relative to biased positions, but does not rehabilitate the cipher. Dropping initial keystream bytes addresses only certain early biases and is not a general repair for RC4’s full set of biases. Reconnecting or using fresh random keys does not erase a population-level deviation that is present across independently keyed streams.

Retire the primitive and confirm actual negotiation

RFC 7465 prohibits RC4 cipher suites in TLS. The durable engineering action is to remove RC4 from accepted configurations and use a maintained modern protocol profile. Disabling only a server preference is incomplete if a client can still negotiate the prohibited suite. Apply the policy to alternate listeners, internal services, and old client compatibility paths.

Migration can reveal obsolete consumers. Identify those clients through safe telemetry and move them to supported stacks; do not preserve an unbounded fallback for a vaguely defined compatibility requirement. For application formats outside TLS, design a versioned authenticated replacement with the appropriate nonce rule. Changing cipher names without changing framing, authentication, or key management may leave a different vulnerability.

The lesson generalizes to statistical evidence: a large key space does not guarantee an unbiased output distribution. Algorithm approval, implementation behavior, and the surrounding protocol are distinct properties. The fact that a primitive was once selected to avoid a different CBC problem never established its own security.

What should you do today?

  • Use a current TLS profile, such as Mozilla’s intermediate profile, which offers no RC4 suite, and confirm with testssl.sh --rc4 host:443; the TLS guide at /domains/identity-crypto/key-management-pki/tls-pki-operations/ covers the rest of the profile.
  • Search custom protocols, file formats and embedded firmware for RC4 or ARC4 and replace them with an AEAD and a versioned format.
  • In Active Directory, find Kerberos tickets issued with RC4 (event IDs 4768 and 4769 with ticket encryption type 0x17) and move those accounts to AES.
  • Since Microsoft’s April 2026 updates (CVE-2026-20833), domain controllers assume AES only (DefaultDomainSupportedEncTypes 0x18) for accounts without explicit encryption types, and the July 2026 updates remove the rollback setting; check that legacy services still authenticate.

Use counts honestly

The exercise computes the maximum-likelihood intuition for an intentionally exaggerated bias. It gives a most likely candidate, not a proof that a particular plaintext must be correct. With a uniform distribution, the counts carry no such preference in the model.

For a deployment, verify that ordinary supported clients negotiate the intended replacement, an RC4-only offer is rejected, and a connection retry does not downgrade to RC4. Record the negotiated suite and protocol, not only configuration text. A scanner’s RC4 finding demonstrates offered capability; reproducing a statistical plaintext-recovery attack requires substantially different evidence.

Guided practice

A four-value stream cipher has a known exaggerated zero bias. Infer one repeated secret from a supplied histogram.

Supplied scenario material
Plain text
Toy keystream probabilities: Pr(Z=0)=1/2; Pr(Z=1)=Pr(Z=2)=Pr(Z=3)=1/6.
C=P XOR Z for two-bit values.
60 observed ciphertexts: C=0:9, C=1:11, C=2:31, C=3:9.
Each observation uses a fresh independently chosen key.

  1. 1. Rank candidates

    For each P, identify which ciphertext value should have the highest probability.

    Expected result and reasoning

    The biased ciphertext is C=P because P XOR 0=P. Candidate P=2 best fits the large count of 31 at C=2.

  2. 2. Calculate the expected counts

    For P=2, calculate the expected histogram over 60 samples.

    Expected result and reasoning

    Expected counts are [10,10,30,10]. The supplied [9,11,31,9] is close; sampling variation means the inference is probabilistic.

  3. 3. Test a misconception

    Decide whether fresh keys remove this model’s leak, or whether equal counts would establish a secret.

    Expected result and reasoning

    Fresh keys are already assumed and do not remove the bias. A uniform histogram offers no preferred candidate under a uniform-keystream model. It does not prove any particular secret.

Your deliverable: Expected and observed histograms plus a short explanation distinguishing reuse from bias.

The four-value distribution is invented for teaching. No RC4 cipher or real attack sample complexity is implemented.

Save a draft on this device to resume later. Automatic saving begins after you choose Save. Drafts are never sent by this application; use synthetic data.

No draft saved on this device yet.

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

  1. RFC 7465: Prohibiting RC4 Cipher Suites. February 2015.
  2. All Your Biases Belong To Us: Breaking RC4 in WPA-TKIP and TLS. USENIX Security 2015.
  3. RFC 9325: Recommendations for Secure Use of TLS and DTLS. November 2022 (BCP 195); updated by RFC 9852 and RFC 10015.
  4. Mozilla Server Side TLS configuration generator (guidelines 6.0)
  5. Microsoft Learn: detect and remediate RC4 usage in Kerberos
  6. Microsoft Support KB5073381: Kerberos KDC usage of RC4 (CVE-2026-20833). Published 13 January 2026.

Reference information

ASVS 5.0.0 requirements
v5.0.0-11.3.2 · v5.0.0-12.1.2

Download this guide as Markdown