--- key: "crypto-rc4" title: "RC4 keystream bias" url: "https://softwaresecurity.com/domains/identity-crypto/encryption/rc4-keystream-bias/" api: "https://softwaresecurity.com/api/v1/articles/crypto-rc4.json" domain: "identity-crypto" topic: "Identity \u0026 cryptography" type: "Reference" identifiers: ["CWE-327","A04:2025","V11.3.2","V12.1.2"] tags: ["Encryption","TLS","Historical cryptographic attacks"] stages: ["design","build"] roles: ["developer"] license: "CC-BY-4.0" license_url: "https://creativecommons.org/licenses/by/4.0/" code_license: "MIT" --- # RC4 keystream bias Understand why fresh RC4 keys do not remove keystream bias and how repeated secret positions turn a small statistical effect into evidence. Canonical URL: https://softwaresecurity.com/domains/identity-crypto/encryption/rc4-keystream-bias/ ## 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`. ## What you will learn - Explain statistical plaintext inference from a biased keystream. - Distinguish independent keys from keystream reuse. - Verify removal through negotiated behavior. Audience: Engineers who retire legacy protocols and cipher suites, and reviewers who need to explain why RC4 is not allowed. Before you start: - Understand a keystream and XOR; distinguish repeated keys from statistical bias. Time: About 17 minutes: 4 to read and 13 for the exercise ## 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 material ```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. Rank candidates For each P, identify which ciphertext value should have the highest probability. Worked answer: 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. Calculate the expected counts For P=2, calculate the expected histogram over 60 samples. Worked answer: Expected counts are [10,10,30,10]. The supplied [9,11,31,9] is close; sampling variation means the inference is probabilistic. ### 3. Test a misconception Decide whether fresh keys remove this model’s leak, or whether equal counts would establish a secret. Worked answer: 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. Deliverable: Expected and observed histograms plus a short explanation distinguishing reuse from bias. Scope: The four-value distribution is invented for teaching. No RC4 cipher or real attack sample complexity is implemented. Articles and teaching material: CC BY 4.0. Original executable code: MIT. Attribution: Software Security. ## Sources - [RFC 7465: Prohibiting RC4 Cipher Suites](https://www.rfc-editor.org/info/rfc7465/). February 2015. - [All Your Biases Belong To Us: Breaking RC4 in WPA-TKIP and TLS](https://www.rc4nomore.com/vanhoef-usenix2015.pdf). USENIX Security 2015. - [RFC 9325: Recommendations for Secure Use of TLS and DTLS](https://www.rfc-editor.org/rfc/rfc9325.html). November 2022 (BCP 195); updated by RFC 9852 and RFC 10015. - [Mozilla Server Side TLS configuration generator (guidelines 6.0)](https://ssl-config.mozilla.org/) - [Microsoft Learn: detect and remediate RC4 usage in Kerberos](https://learn.microsoft.com/en-us/windows-server/security/kerberos/detect-remediate-rc4-kerberos) - [Microsoft Support KB5073381: Kerberos KDC usage of RC4 (CVE-2026-20833)](https://support.microsoft.com/en-us/servicing/os/windows/2025/11/how-to-manage-kerberos-kdc-usage-of-rc4-for-service-account-ticket-issuance-changes-related-to-cve-2). Published 13 January 2026.