View source for RC4

{{short description|Stream cipher}}
{{About|the stream cipher}}
{{Use dmy dates|date=December 2015}}
{{Infobox encryption method
|name           = RC4
|image          =
|caption        =
|designers      = [[Ron Rivest]] ([[RSA Security]])
|publish date   = Leaked in 1994<br/>(designed in 1987)
|series         =
|derived from   =
|related to     =
|certification  =
|key size       = 40–{{val|2048}} bits
|security claim =
|state size     = {{val|2064}} bits ({{val|1684}} effective)
|structure      =
|rounds         = 1
|speed          = 7 cycles per byte on [[Intel P5 (microarchitecture)|original Pentium]]<ref>{{cite conference |author1=P. Prasithsangaree |author2=P. Krishnamurthy |conference=GLOBECOM '03 |publisher=IEEE |year=2003 |title=Analysis of Energy Consumption of RC4 and AES Algorithms in Wireless LANs |url=http://www.sis.pitt.edu/~is3966/group5_paper2.pdf |archive-url=https://web.archive.org/web/20131203082918/http://www.sis.pitt.edu/~is3966/group5_paper2.pdf |archive-date=3 December 2013 |url-status=dead }}</ref><br>Modified Alleged RC4 on Intel Core 2: 13.9 cycles per byte<ref>{{cite web |title=Crypto++ 5.6.0 Benchmarks |url=http://www.cryptopp.com/benchmarks.html |access-date=22 September 2015}}</ref>
|cryptanalysis  =
}}

In [[cryptography]], '''RC4''' (also known as '''ARC4''' or '''ARCFOUR''', meaning Alleged RC4, see below) is a [[stream cipher]]. While it is remarkable for its simplicity and speed in software, multiple vulnerabilities have been discovered in RC4, rendering it insecure.<ref name=rfc7465>{{cite IETF |rfc=7465 |author=Andrei Popov |date=February 2015 |title=Prohibiting RC4 Cipher Suites }}</ref><ref>{{cite news |url=http://www.computerworld.com/article/2489395/encryption/microsoft-continues-rc4-encryption-phase-out-plan-with--net-security-updates.html |author=Lucian Constantin |date=14 May 2014 |title=Microsoft continues RC4 encryption phase-out plan with .NET security updates |work=ComputerWorld }}</ref> It is especially vulnerable when the beginning of the output [[keystream]] is not discarded, or when nonrandom or related keys are used. Particularly problematic uses of RC4 have led to very insecure [[Cryptographic protocol|protocol]]s such as [[Wired Equivalent Privacy|WEP]].<ref>{{citation |page=77 |year=2014 |author1=J. Katz |author2=Y. Lindell |title=Introduction to Modern Cryptography |publisher=Chapman and Hall/CRC}}.</ref>

{{As of|2015}}, there is speculation that some state cryptologic agencies may possess the capability to break RC4 when used in the [[Transport Layer Security|TLS protocol]].<ref name=Leyden20130906/> [[IETF]] has published RFC 7465 to prohibit the use of RC4 in TLS;<ref name=rfc7465 /> [[Mozilla]] and [[Microsoft]] have issued similar recommendations.<ref>{{cite web|url=https://wiki.mozilla.org/Security/Server_Side_TLS|title=Mozilla Security Server Side TLS Recommended Configurations|publisher=Mozilla|access-date=2015-01-03}}</ref><ref>{{cite web|url=http://blogs.technet.com/b/srd/archive/2013/11/12/security-advisory-2868725-recommendation-to-disable-rc4.aspx|title=Security Advisory 2868725: Recommendation to disable RC4|date=12 November 2013|publisher=Microsoft|access-date=2013-12-04}}</ref>

A number of attempts have been made to strengthen RC4, notably Spritz, RC4A, [[Variably Modified Permutation Composition|VMPC]], and RC4<sup>+</sup>.

==History==
RC4 is a stream cipher designed by Ronald Rivest of RSA Security in 1987. According to Rivest, the letters RC stand for “Ron's Code”,<ref>{{cite web| url = http://people.csail.mit.edu/rivest/faq.html#Ron| title = Rivest FAQ at csail.mit.edu}}</ref> though in general it is simply referred to as RC4. The same naming convention applies to RC2, RC5, and RC6.

RC4 was initially a [[trade secret]], but in September 1994, a description of it was anonymously posted to the [[Cypherpunk]]s mailing list.<ref>{{cite mailing list|url=http://cypherpunks.venona.com/date/1994/09/msg00304.html |title=Thank you Bob Anderson |date=9 September 1994 |access-date=2007-05-28 |mailing-list=[[Cypherpunk]]s |url-status=dead |archive-url=https://web.archive.org/web/20010722163902/http://cypherpunks.venona.com/date/1994/09/msg00304.html |archive-date=22 July 2001 }}</ref> It was soon posted on the [[sci.crypt]] [[newsgroup]], where it was [[Distinguishing attack|broken]] within days by [[Robert John Jenkins Junior|Bob Jenkins]].<ref>{{cite newsgroup
| author = Bob Jenkins
| title = Re: RC4 ?
| date = 1994-09-15
| newsgroup = sci.crypt
| message-id = 359qjg$55v$1@mhadg.production.compuserve.com
| url = https://groups.google.com/d/msg/sci.crypt/JsO3xEATGFA/-wO4ttv7BCYJ
}}</ref> From there, it spread to many sites on the Internet. The leaked code was confirmed to be genuine, as its output was found to match that of proprietary software using licensed RC4. Because the algorithm is known, it is no longer a trade secret. The name ''RC4'' is trademarked, so RC4 is often referred to as ''ARCFOUR'' or ''ARC4'' (meaning ''alleged RC4'')<ref>{{cite web|title=Manual Pages: arc4random|url=https://man.openbsd.org/OpenBSD-5.4/arc4random.3|access-date=2 February 2018|date=5 June 2013}}</ref> to avoid trademark problems. [[RSA Security]] has never officially released the algorithm; Rivest has, however, linked to the [[English Wikipedia]] article on RC4 in his own course notes in 2008<ref>{{cite web| url = http://courses.csail.mit.edu/6.857/2008/lecture.html| title = 6.857 Computer and Network Security Spring 2008: Lectures and Handouts}}</ref> and confirmed the history of RC4 and its code in a 2014 paper by him.<ref name="Rivest2014"/>

RC4 became part of some commonly used encryption protocols and standards, such as [[Wired Equivalent Privacy|WEP]] in 1997 and [[Wi-Fi Protected Access|WPA]] in 2003/2004 for wireless cards; and [[Secure Sockets Layer|SSL]] in 1995 and its successor [[Transport Layer Security|TLS]] in 1999, until it was prohibited for all versions of TLS by RFC 7465 in 2015, due to the [[Transport Layer Security#RC4 attacks|RC4 attacks]] weakening or breaking RC4 used in SSL/TLS. The main factors in RC4's success over such a wide range of applications have been its speed and simplicity: efficient implementations in both software and hardware were very easy to develop.

==Description==
RC4 generates a [[pseudo-random number generator|pseudorandom stream of bits]] (a [[keystream]]). As with any stream cipher, these can be used for encryption by combining it with the plaintext using bitwise [[exclusive or]]; decryption is performed the same way (since exclusive or with given data is an [[involution (mathematics)|involution]]). This is similar to the [[one-time pad]], except that generated ''pseudorandom bits'', rather than a prepared stream, are used.

To generate the keystream, the cipher makes use of a secret internal state which consists of two parts:
# A [[permutation]] of all 256 possible [[bytes]] (denoted "S" below).
# Two 8-bit index-pointers (denoted "i" and "j").
The permutation is initialized with a variable-length [[key (cryptography)|key]], typically between 40 and 2048&nbsp;bits, using the ''[[key schedule|key-scheduling]]'' algorithm (KSA). Once this has been completed, the stream of bits is generated using the ''pseudo-random generation algorithm'' (PRGA).

===Key-scheduling algorithm (KSA)===
The [[Key schedule|key-scheduling]] algorithm is used to initialize the permutation in the array "S". "keylength" is defined as the number of bytes in the key and can be in the range 1 ≤ keylength ≤ 256, typically between 5 and 16, corresponding to a [[key length]] of 40–128&nbsp;bits. First, the array "S" is initialized to the [[identity permutation]]. S is then processed for 256 iterations in a similar way to the main PRGA, but also mixes in bytes of the key at the same time.

 '''for''' i '''from''' 0 '''to''' 255
     S[i] := i
 '''endfor'''
 j := 0
 '''for''' i '''from''' 0 '''to''' 255
     j := (j + S[i] + key[i [[modulo operation|mod]] keylength]) mod 256
     swap values of S[i] and S[j]
 '''endfor'''

===Pseudo-random generation algorithm (PRGA)===
[[Image:RC4.svg|right|thumbnail|320px|The lookup stage of RC4. The output byte is selected by looking up the values of {{mono|S[i]}} and {{mono|S[j]}}, adding them together modulo 256, and then using the sum as an index into {{mono|S}}; {{mono|S(S[i] + S[j])}} is used as a byte of the key stream K.]]

For as many iterations as are needed, the PRGA modifies the state and outputs a byte of the keystream. In each iteration, the PRGA: 
* increments {{mono|''i''}};
* looks up the {{mono|''i''}}th element of {{mono|S}}, {{mono|S[''i'']}}, and adds that to {{mono|''j''}};
* exchanges the values of {{mono|S[''i'']}} and {{mono|S[''j'']}}, then uses the sum {{mono|S[''i''] + S[''j''] (modulo 256)}} as an index to fetch a third element of {{mono|S}} (the keystream value {{mono|K}} below);
* then bitwise exclusive ORed ([[Exclusive or|XOR]]ed) with the next byte of the message to produce the next byte of either ciphertext or plaintext.

Each element of S is swapped with another element at least once every 256 iterations.

 i := 0
 j := 0
 '''while''' GeneratingOutput:
     i := (i + 1) mod 256
     j := (j + S[i]) mod 256
     [[Swap (computer science)|swap values]] of S[i] and S[j]
     t := (S[i] + S[j]) mod 256
     K := S[t]
     output K
 '''endwhile'''

Thus, this produces a stream of {{mono|K[0], K[1], ...}} which are [[Exclusive or|XOR]]ed with the {{mono|''plaintext''}} to obtain the {{mono|''ciphertext''}}. So {{mono|ciphertext[''l''] {{=}} plaintext[''l''] ⊕ K[''l'']}}.

===RC4-based random number generators===
Several [[operating system]]s include {{code|arc4random}}, an API originating in [[OpenBSD security features|OpenBSD]] providing access to a random number generator originally based on RC4. The API allows no seeding, as the function initializes itself using [[/dev/random]]. The use of RC4 has been phased out in most systems implementing this API. [[Man page]]s for the new arc4random include the [[backronym]] "A Replacement Call for Random" for ARC4 as a mnemonic, as it provides better random data than [[rand()]] does.<ref name=arc4random-obsd>{{cite web |url=http://man.openbsd.org/arc4random.3 |title=arc4random(3) |publisher=OpenBSD}}</ref>

* In OpenBSD 5.5, released in May 2014, {{code|arc4random}} was modified to use [[ChaCha20]].<ref>{{cite web |title=OpenBSD 5.5 |url=http://www.openbsd.org/55.html |access-date=21 September 2014}}</ref><ref>{{cite web |url=http://bxr.su/OpenBSD/lib/libc/crypt/arc4random.c |title=libc/crypt/arc4random.c |website=BSD Cross Reference, OpenBSD src/lib/ |editor=deraadt |editor-link=Theo de Raadt |date=21 July 2014 |access-date=2015-01-13 |quote=ChaCha based random number generator for OpenBSD.}}</ref> The implementations of arc4random in [[FreeBSD]], [[NetBSD]]<ref>{{cite web |url=http://bxr.su/NetBSD/lib/libc/gen/arc4random.c |title=libc/gen/arc4random.c |website=BSD Cross Reference, NetBSD src/lib/ |editor=riastradh |date=16 November 2014 |access-date=2015-01-13 |quote=Legacy arc4random(3) API from OpenBSD reimplemented using the ChaCha20 PRF, with per-thread state.}}</ref><ref>{{cite web |title=arc4random – NetBSD Manual Pages |url=http://netbsd.gw.com/cgi-bin/man-cgi?arc4random++NetBSD-current |access-date=6 January 2015 |archive-date=6 July 2020 |archive-url=https://web.archive.org/web/20200706210612/https://netbsd.gw.com/cgi-bin/man-cgi?arc4random++NetBSD-current |url-status=dead}}</ref> also use ChaCha20.
** Linux typically uses [[glibc]], which did not offer ''arc4random'' until 2022. Instead, a separate library, libbsd, offers the function; it was updated to use ChaCha20 in 2016.<ref>{{cite web |title=Update arc4random module from OpenBSD and LibreSSL |url=https://cgit.freedesktop.org/libbsd/commit/?id=874a0e5 |access-date=6 January 2016}}</ref> In 2022, [[glibc]] added its own version of ''arc4random'', also based on ChaCha20.<ref>{{cite web |title=GNU C Library Finally Adds arc4random Functions For Linux |url=https://www.phoronix.com/news/GNU-Glibc-arc4random-Functions |website=www.phoronix.com |language=en}}</ref>
* According to manual pages shipped with the operating system, in the 2017 release of [[macOS]] and [[iOS]] operating systems, Apple replaced RC4 with AES in its implementation of arc4random.

Proposed new random number generators are often compared to the RC4 random number generator.<ref>
Bartosz Zoltak.
[//eprint.iacr.org/2013/768.pdf "VMPC-R: Cryptographically Secure Pseudo-Random Number Generator, Alternative to RC4"].
2010?
</ref><ref>
Chefranov, A. G.
[https://ieeexplore.ieee.org/document/4022919/ "Pseudo-Random Number Generator RC4 Period Improvement"].
2006.
</ref>

Several attacks on RC4 are able to [[ciphertext indistinguishability#Indistinguishable from random noise|distinguish its output from a random sequence]].<ref name="mantin" />

===Implementation===
Many stream ciphers are based on [[linear-feedback shift register]]s (LFSRs), which, while efficient in hardware, are less so in software. The design of RC4 avoids the use of LFSRs and is ideal for software implementation, as it requires only byte manipulations. It uses 256 bytes of memory for the state array, S[0] through S[255], k bytes of memory for the key, key[0] through key[k−1], and integer variables, i, j, and K. Performing a modular reduction of some value modulo 256 can be done with a [[bitwise AND]] with 255 (which is equivalent to taking the low-order byte of the value in question).

===Test vectors===
These test vectors are not official, but convenient for anyone testing their own RC4 program. The keys and plaintext are [[ASCII]], the keystream and ciphertext are in [[hexadecimal]].

{| class="wikitable"
! Key !! Keystream !! Plaintext !! Ciphertext
|-
| {{mono|Key}} || {{mono|EB9F7781B734CA72A719}}... || {{mono|Plaintext}} || {{mono|BBF316E8D940AF0AD3}}
|-
| {{mono|Wiki}} || {{mono|6044DB6D41B7}}... || {{mono|pedia}} || {{mono|1021BF0420}}
|-
| {{mono|Secret}} || {{mono|04D46B053CA87B59}}... || {{mono|Attack at dawn}} || {{mono|45A01F645FC35B383552544B9BF5}}
|}

==Security==
Unlike a modern stream cipher (such as those in [[eSTREAM]]), RC4 does not take a separate [[cryptographic nonce|nonce]] alongside the key.  This means that if a single long-term key is to be used to securely encrypt multiple streams, the protocol must specify how to combine the nonce and the long-term key to generate the stream key for RC4.  One approach to addressing this is to generate a "fresh" RC4 key by [[cryptographic hash function|hashing]] a long-term key with a [[cryptographic nonce|nonce]]. However, many applications that use RC4 simply concatenate key and nonce; RC4's weak [[key schedule]] then gives rise to [[related-key attack]]s, like the [[Fluhrer, Mantin and Shamir attack]] (which is famous for breaking the [[Wired Equivalent Privacy|WEP]] standard).<ref>{{cite web |date=1 September 2001 |title=RSA Security Response to Weaknesses in Key Scheduling Algorithm of RC4 |publisher=RSA Laboratories |url=http://www.emc.com/emc-plus/rsa-labs/historical/rsa-security-response-weaknesses-algorithm-rc4.htm }}</ref>
<!-- Should this be merged into the "Fluhrer, Mantin and Shamir attack" section below? -->

Because RC4 is a [[stream cipher]], it is more [[malleability (cryptography)|malleable]] than common [[block cipher]]s. If not used together with a strong [[message authentication code]] (MAC), then encryption is vulnerable to a [[bit-flipping attack]]. The cipher is also vulnerable to a [[stream cipher attack]] if not implemented correctly.<ref>{{cite book |url=https://books.google.com/books?id=dQE6LGep6wEC |pages=92–93 |title=Hidden Keys to Software Break-Ins and Unauthorized Entry |first=Dmitry |last=Sklyarov |publisher=A-List Publishing |year=2004 |isbn=978-1931769303}}</ref>

It is noteworthy, however, that RC4, being a stream cipher, was for a period of time the only common cipher that was immune<ref>[http://serverfault.com/questions/315042/ "ssl - Safest ciphers to use with the BEAST? (TLS 1.0 exploit) I've read that RC4 is immune"]. ''serverfault.com''.</ref> to the 2011 [[BEAST attack]] on [[Transport Layer Security#TLS 1.0|TLS&nbsp;1.0]]. The attack exploits a known weakness in the way [[Block cipher modes of operation#Cipher-block chaining .28CBC.29|cipher-block chaining mode]] is used with all of the other ciphers supported by TLS&nbsp;1.0, which are all block ciphers.

In March 2013, there were new attack scenarios proposed by Isobe, Ohigashi, Watanabe and Morii,<ref>{{cite web |url=http://home.hiroshima-u.ac.jp/ohigashi/rc4/ |title=Security of RC4 Stream Cipher |last1=Isobe |first1=Takanori |last2=Ohigashi |first2=Toshihiro |date=10–13 Mar 2013 |publisher=Hiroshima University |access-date=2014-10-27 |archive-date=1 November 2014 |archive-url=https://web.archive.org/web/20141101231026/http://home.hiroshima-u.ac.jp/ohigashi/rc4/ |url-status=dead }}</ref> as well as AlFardan, Bernstein, Paterson, Poettering and Schuldt that use new statistical biases in RC4 key table<ref>{{cite book |author1=Pouyan Sepehrdad |author2=Serge Vaudenay |author3=Martin Vuagnoux |title=Selected Areas in Cryptography |chapter=Discovery and Exploitation of New Biases in RC4 |series=Lecture Notes in Computer Science | year=2011 | volume=6544 | pages=74–91 | doi=10.1007/978-3-642-19574-7_5|isbn = 978-3-642-19573-0}}</ref> to recover plaintext with large number of TLS encryptions.<ref>{{cite web | url=http://blog.cryptographyengineering.com/2013/03/attack-of-week-rc4-is-kind-of-broken-in.html | title=Attack of the week: RC4 is kind of broken in TLS | work=Cryptography Engineering | access-date=12 March 2013 | author=Green, Matthew | date=2013-03-12 }}</ref><ref>{{cite web |title=On the Security of RC4 in TLS |url=http://www.isg.rhul.ac.uk/tls/ |publisher=Royal Holloway University of London |access-date=13 March 2013 |author1=Nadhem AlFardan |author2=Dan Bernstein |author3=Kenny Paterson |author4=Bertram Poettering |author5=Jacob Schuldt |archive-date=15 March 2013 |archive-url=https://web.archive.org/web/20130315084623/http://www.isg.rhul.ac.uk/tls/ |url-status=dead }}</ref>

The use of RC4 in TLS is prohibited by RFC 7465 published in February 2015.

===Roos' biases and key reconstruction from permutation===
In 1995, Andrew Roos experimentally observed that the first byte of the keystream is correlated with the first three bytes of the key, and the first few bytes of the permutation after the KSA are correlated with some linear combination of the key bytes.<ref>Andrew Roos. A Class of Weak Keys in the RC4 Stream Cipher. Two posts in sci.crypt, message-id 43u1eh$1j3@hermes.is.co.za and 44ebge$llf@hermes.is.co.za, 1995.</ref> These biases remained unexplained until 2007, when Goutam Paul, Siddheshwar Rathi and Subhamoy Maitra<ref>Goutam Paul, Siddheshwar Rathi and Subhamoy Maitra. On Non-negligible Bias of the First Output Byte of RC4 towards the First Three Bytes of the Secret Key. Proceedings of the International Workshop on Coding and Cryptography (WCC) 2007, pages 285–294 and Designs, Codes and Cryptography Journal, pages 123–134, vol. 49, no. 1-3, December 2008.</ref> proved the keystream–key correlation and, in another work, Goutam Paul and Subhamoy Maitra<ref>Goutam Paul and Subhamoy Maitra. Permutation after RC4 Key Scheduling Reveals the Secret Key. SAC 2007, pages 360–377, vol. 4876, [[Lecture Notes in Computer Science]], Springer.</ref> proved the permutation–key correlations. The latter work also used the permutation–key correlations to design the first algorithm for complete key reconstruction from the final permutation after the KSA, without any assumption on the key or [[initialization vector]]. This algorithm has a constant probability of success in a time, which is the square root of the exhaustive key search complexity. Subsequently, many other works have been performed on key reconstruction from RC4 internal states.<ref>Eli Biham and Yaniv Carmeli. Efficient Reconstruction of RC4 Keys from Internal States. FSE 2008, pages 270–288, vol. 5086, Lecture Notes in Computer Science, Springer.</ref><ref>Mete Akgun, Pinar Kavak, Huseyin Demirci. New Results on the Key Scheduling Algorithm of RC4. INDOCRYPT 2008, pages 40–52, vol. 5365, Lecture Notes in Computer Science, Springer.</ref><ref>Riddhipratim Basu, Subhamoy Maitra, Goutam Paul and Tanmoy Talukdar. On Some Sequences of the Secret Pseudo-random Index j in RC4 Key Scheduling. Proceedings of the 18th International Symposium on Applied Algebra, Algebraic Algorithms and Error Correcting Codes (AAECC), 8–12 June 2009, Tarragona, Spain, pages 137–148, vol. 5527, Lecture Notes in Computer Science, Springer.</ref> Subhamoy Maitra and Goutam Paul<ref>Subhamoy Maitra and Goutam Paul. New Form of Permutation Bias and Secret Key Leakage in Keystream Bytes of RC4. Proceedings of the 15th Fast Software Encryption (FSE) Workshop, 10–13 February 2008, Lausanne, Switzerland, pages 253–269, vol. 5086, Lecture Notes in Computer Science, Springer.</ref> also showed that the Roos-type biases still persist even when one considers nested permutation indices, like {{mono|S[S[i]]}} or {{mono|S[S[S[i]]]}}. These types of biases are used in some of the later key reconstruction methods for increasing the success probability.

===Biased outputs of the RC4===
The keystream generated by the RC4 is biased to varying degrees towards certain sequences, making it vulnerable to [[distinguishing attack]]s. The best such attack is due to Itsik Mantin and [[Adi Shamir]], who showed that the second output byte of the cipher was biased toward zero with probability 1/128 (instead of 1/256). This is due to the fact that if the third byte of the original state is zero, and the second byte is not equal to 2, then the second output byte is always zero. Such bias can be detected by observing only 256&nbsp;bytes.<ref name="mantin">{{cite conference |author1=Itsik Mantin |author2=[[Adi Shamir]] |date=2001 |title=A Practical Attack on Broadcast RC4 |conference=FSE 2001 |pages=152–164 |url=https://link.springer.com/content/pdf/10.1007%2F3-540-45473-X_13.pdf |doi=10.1007/3-540-45473-X_13}}</ref>

[[Souradyuti Paul]] and [[Bart Preneel]] of [[COSIC]] showed that the first and the second bytes of the RC4 were also biased. The number of required samples to detect this bias is 2<sup>25</sup>&nbsp;bytes.<ref>{{cite conference |author1=[[Souradyuti Paul]] |author2=[[Bart Preneel]] |title=Analysis of Non-fortuitous Predictive States of the RC4 Keystream Generator |conference=[[Indocrypt]] 2003 |pages=52–67 |url=http://www.cosic.esat.kuleuven.be/publications/article-86.pdf }}</ref>

[[Scott Fluhrer]] and David McGrew also showed attacks that distinguished the keystream of the RC4 from a random stream given a gigabyte of output.<ref>{{cite conference |author1=Scott R. Fluhrer |author2=David A. McGrew |title=Statistical Analysis of the Alleged RC4 Keystream Generator |conference=FSE 2000 |pages=19–30 |url=http://www.wisdom.weizmann.ac.il/~itsik/RC4/Papers/FluhrerMcgrew.pdf |url-status=dead |archive-url=https://web.archive.org/web/20140502020708/http://www.wisdom.weizmann.ac.il/~itsik/RC4/Papers/FluhrerMcgrew.pdf |archive-date=2 May 2014 |df=dmy-all }}</ref>

The complete characterization of a single step of RC4 PRGA was performed by Riddhipratim Basu, Shirshendu Ganguly, Subhamoy Maitra, and Goutam Paul.<ref>{{cite journal |first1=Riddhipratim |last1=Basu |first2=Shirshendu |last2=Ganguly |first3=Subhamoy |last3=Maitra |first4=Goutam |last4=Paul |title=A Complete Characterization of the Evolution of RC4 Pseudo Random Generation Algorithm |journal=Journal of Mathematical Cryptology |pages=257–289 |volume=2 |issue=3 |year=2008 |doi=10.1515/JMC.2008.012 |s2cid=9613837 |doi-access=free }}</ref> Considering all the permutations, they proved that the distribution of the output is not uniform given i and j, and as a consequence, information about j is always leaked into the output.

===Fluhrer, Mantin and Shamir attack===
{{Main|Fluhrer, Mantin and Shamir attack}}

In 2001, a new and surprising discovery was made by [[Scott Fluhrer|Fluhrer]], [[Itsik Mantin|Mantin]] and [[Adi Shamir|Shamir]]: over all the possible RC4 keys, the statistics for the first few bytes of output keystream are strongly non-random, leaking information about the key. If the nonce and long-term key are simply concatenated to generate the RC4 key, this long-term key can be discovered by analysing a large number of messages encrypted with this key.<ref>{{cite journal |first1=Scott R. |last1=Fluhrer |first2=Itsik |last2=Mantin |first3=Adi |last3=Shamir |title=Weaknesses in the Key Scheduling Algorithm of RC4 |journal=[[Selected Areas in Cryptography]] |year=2001 |pages=1–24 |url=http://www.wisdom.weizmann.ac.il/~itsik/RC4/Papers/Rc4_ksa.ps |archive-url=https://web.archive.org/web/20040602051734/http://www.wisdom.weizmann.ac.il/~itsik/RC4/Papers/Rc4_ksa.ps |archive-date=2 June 2004}}</ref> This and related effects were then used to break the [[Wired Equivalent Privacy|WEP]] ("wired equivalent privacy") encryption used with [[802.11]] [[wireless network]]s. This caused a scramble for a standards-based replacement for WEP in the 802.11 market and led to the [[IEEE&nbsp;802.11i]] effort and [[Wi-Fi Protected Access|WPA]].<ref>{{cite web |url=http://findarticles.com/p/articles/mi_m0DIS/is_2003_Jan/ai_n27590035/ |archive-url=https://archive.today/20120709120158/http://findarticles.com/p/articles/mi_m0DIS/is_2003_Jan/ai_n27590035/ |url-status=dead |archive-date=2012-07-09 |title=Interim technology for wireless LAN security: WPA to replace WEP while industry develops new security standard}}</ref>

Protocols can defend against this attack by discarding the initial portion of the keystream. Such a modified algorithm is traditionally called "RC4-drop[{{mvar|n}}]", where {{mvar|n}} is the number of initial keystream bytes that are dropped. The SCAN default is {{mvar|n}} = 768&nbsp;bytes, but a conservative value would be {{mvar|n}} = 3072&nbsp;bytes.<ref>{{cite web |url=http://www.users.zetnet.co.uk/hopwood/crypto/scan/cs.html#RC4-drop |title=RC4-drop(nbytes) in the ''Standard Cryptographic Algorithm Naming'' database}}</ref>

The Fluhrer, Mantin and Shamir attack does not apply to RC4-based SSL, since SSL generates the encryption keys it uses for RC4 by hashing, meaning that different SSL sessions have unrelated keys.<ref>{{cite web |first=Ron |last=Rivest |url=https://www.rsa.com/rsalabs/node.asp?id=2009 |title=RSA Security Response to Weaknesses in Key Scheduling Algorithm of RC4}}</ref>

===Klein's attack===
In 2005, Andreas Klein presented an analysis of the RC4 stream cipher, showing more correlations between the RC4 keystream and the key.<ref>A. Klein, Attacks on the RC4 stream cipher, Designs, Codes and Cryptography (2008) 48:269–286.</ref> [[Erik Tews]], [[Ralf-Philipp Weinmann]], and [[Andrei Pychkine]] used this analysis to create aircrack-ptw, a tool that cracks 104-bit RC4 used in 128-bit WEP in under a minute.<ref>Erik Tews, Ralf-Philipp Weinmann, Andrei Pyshkin. [//eprint.iacr.org/2007/120 Breaking 104-bit WEP in under a minute].</ref> Whereas the Fluhrer, Mantin, and Shamir attack used around 10&nbsp;million messages, aircrack-ptw can break 104-bit keys in 40,000 frames with 50% probability, or in 85,000 frames with 95% probability.

===Combinatorial problem===
A combinatorial problem related to the number of inputs and outputs of the RC4 cipher was first posed by [[Itsik Mantin]] and [[Adi Shamir]] in 2001, whereby, of the total 256 elements in the typical state of RC4, if ''x'' number of elements (''x'' ≤ 256) are ''only'' known (all other elements can be assumed empty), then the maximum number of elements that can be produced deterministically is also {{mvar|x}} in the next 256 rounds. This conjecture was put to rest in 2004 with a formal proof given by [[Souradyuti Paul]] and [[Bart Preneel]].<ref>[[Souradyuti Paul]] and [[Bart Preneel]], [http://www.cosic.esat.kuleuven.be/publications/article-40.pdf A New Weakness in the RC4 Keystream Generator and an Approach to Improve the Security of the Cipher]. [[Fast Software Encryption]] – FSE 2004, pp.&nbsp;245–259.</ref>

===Royal Holloway attack===
In 2013, a group of security researchers at the Information Security Group at Royal Holloway, University of London reported an attack that can become effective using only 2<sup>34</sup> encrypted messages.<ref>{{cite news |url=https://www.theregister.co.uk/2013/03/15/tls_broken/ |title=HTTPS cookie crypto CRUMBLES AGAIN in hands of stats boffins |author=John Leyden |website=The Register |date=15 March 2013}}</ref><ref>{{cite web |url=http://www.isg.rhul.ac.uk/tls/RC4biases.pdf |title=On the Security of RC4 in TLS and WPA |last=AlFardan |publisher=Information Security Group, Royal Holloway, University of London |date=8 July 2013 |display-authors=etal |access-date=6 September 2013 |archive-date=22 September 2013 |archive-url=https://web.archive.org/web/20130922170155/http://www.isg.rhul.ac.uk/tls/RC4biases.pdf |url-status=dead }}</ref><ref>{{cite web |title=On the Security of RC4 in TLS and WPA |url=http://www.isg.rhul.ac.uk/tls/ |publisher=Information Security Group, Royal Holloway, University of London |access-date=2013-09-06 |archive-date=15 March 2013 |archive-url=https://web.archive.org/web/20130315084623/http://www.isg.rhul.ac.uk/tls/ |url-status=dead }}</ref> While yet not a practical attack for most purposes, this result is sufficiently close to one that it has led to speculation that it is plausible that some state cryptologic agencies may already have better attacks that render RC4 insecure.<ref name=Leyden20130906>{{cite web |url=https://www.theregister.co.uk/2013/09/06/nsa_cryptobreaking_bullrun_analysis/ |title=That earth-shattering NSA crypto-cracking: Have spooks smashed RC4? |author=John Leyden |date=6 September 2013 |website=The Register}}</ref> Given that, {{as of|2013|lc=yes}}, a large amount of [[Transport Layer Security|TLS]] traffic uses RC4 to avoid attacks on block ciphers that use [[cipher block chaining]], if these hypothetical better attacks exist, then this would make the TLS-with-RC4 combination insecure against such attackers in a large number of practical scenarios.<ref name=Leyden20130906/>

In March 2015, researcher to Royal Holloway announced improvements to their attack, providing a 2<sup>26</sup> attack against passwords encrypted with RC4, as used in TLS.<ref>{{Cite web |title=RC4 must die |url=http://www.isg.rhul.ac.uk/tls/RC4mustdie.html |access-date=17 March 2015 |archive-date=18 March 2015 |archive-url=https://web.archive.org/web/20150318214241/http://www.isg.rhul.ac.uk/tls/RC4mustdie.html |url-status=dead }}</ref>

===Bar mitzvah attack===
{{main|Bar mitzvah attack}}
At the Black Hat Asia 2015 Conference, Itsik Mantin presented another attack against SSL using RC4 cipher.<ref>{{Cite web| url=https://www.blackhat.com/asia-15/briefings.html#bar-mitzva-attack-breaking-ssl-with-13-year-old-rc4-weakness| title=Briefings – March 26 & 27| access-date=November 19, 2016| date=2015}}</ref><ref>{{Cite web| title=Attacking SSL when using RC4| date=2015| url=https://www.imperva.com/docs/HII_Attacking_SSL_when_using_RC4.pdf| access-date=November 19, 2016}}</ref>

===NOMORE attack===
In 2015, security researchers from [[Katholieke Universiteit Leuven|KU Leuven]] presented new attacks against RC4 in both [[Transport Layer Security|TLS]] and [[Temporal Key Integrity Protocol|WPA-TKIP]].<ref name=rc4nomore>{{cite web |url=https://www.rc4nomore.com/ |title=RC4 NOMORE: Numerous Occurrence MOnitoring & Recovery Exploit |author1=Mathy Vanhoef |author2=Frank Piessens |date=9 August 2015}}</ref> Dubbed the Numerous Occurrence MOnitoring & Recovery Exploit (NOMORE) attack, it is the first attack of its kind that was demonstrated in practice. Their attack against [[Transport Layer Security|TLS]] can decrypt a secure [[HTTP cookie]] within 75&nbsp;hours. The attack against WPA-TKIP can be completed within an hour and allows an attacker to decrypt and inject arbitrary packets.

==RC4 variants==
As mentioned above, the most important weakness of RC4 comes from the insufficient key schedule; the first bytes of output reveal information about the key.  This can be corrected by simply discarding some initial portion of the output stream.<ref>{{Citation |chapter-url=http://eprint.iacr.org/2002/067 |chapter=(Not So) Random Shuffles of RC4 |author=Ilya Mironov |date=1 June 2002 |title=Advances in Cryptology – CRYPTO 2002 |pages=304–319 |series=Lecture Notes in Computer Science |volume=2442 |publisher=Springer-Verlag |isbn=978-3-540-44050-5 |doi=10.1007/3-540-45708-9_20 |id=Cryptology ePrint Archive: Report 2002/067 |access-date=2011-11-04|url=http://www.iacr.org/archive/crypto2002/24420305/24420305.pdf |doi-access=free }}</ref> This is known as RC4-drop''N'', where ''N'' is typically a multiple of 256, such as 768 or 1024.

A number of attempts have been made to strengthen RC4, notably Spritz, RC4A, [[Variably Modified Permutation Composition|VMPC]], and RC4<sup>+</sup>.

===RC4A===
[[Souradyuti Paul]] and [[Bart Preneel]] have proposed an RC4 variant, which they call RC4A.<ref>{{Citation |chapter=A New Weakness in the RC4 Keystream Generator and an Approach to Improve the Security of the Cipher |author1=Souradyuti Paul |author-link1=Souradyuti Paul |author2=Bart Preneel |author-link2=Bart Preneel |chapter-url=http://homes.esat.kuleuven.be/~psourady/publication-info/PP04-bias_rc4.htm |year=2004 |title=Fast Software Encryption, FSE 2004 |series=Lecture Notes in Computer Science |volume=3017 |publisher=Springer-Verlag |isbn=978-3-540-22171-5 |pages=245–259 |doi=10.1007/978-3-540-25937-4_16 |access-date=2011-11-04|doi-access=free }}</ref>

RC4A uses two state arrays {{mono|S1}} and {{mono|S2}}, and two indexes {{mono|<var>j1</var>}} and {{mono|<var>j2</var>}}.  Each time {{mono|<var>i</var>}} is incremented, two bytes are generated:
# First, the basic RC4 algorithm is performed using {{mono|S1}} and {{mono|<var>j1</var>}}, but in the last step, {{mono|S1[<var>i</var>]+S1[<var>j1</var>]}} is looked up in {{mono|S2}}.
# Second, the operation is repeated (without incrementing {{mono|<var>i</var>}} again) on {{mono|S2}} and {{mono|<var>j2</var>}}, and {{mono|S1[S2[<var>i</var>]+S2[<var>j2</var>]<nowiki>]</nowiki>}} is output.

Thus, the algorithm is:

 <span style="color: green;">''All arithmetic is performed modulo 256''</span>
 i := 0
 j1 := 0
 j2 := 0
 '''while''' GeneratingOutput:
     i := i + 1
     j1 := j1 + S1[i]
     [[Swap (computer science)|swap values]] of S1[i] and S1[j1]
     '''output''' S2[S1[i] + S1[j1]<nowiki>]</nowiki>
     j2 := j2 + S2[i]
     swap values of S2[i] and S2[j2]
     '''output''' S1[S2[i] + S2[j2]<nowiki>]</nowiki>
 '''endwhile'''

Although the algorithm required the same number of operations per output byte, there is greater parallelism than RC4, providing a possible speed improvement.

Although stronger than RC4, this algorithm has also been attacked, with Alexander Maximov<ref>{{Citation |title=Two Linear Distinguishing Attacks on VMPC and RC4A and Weakness of RC4 Family of Stream Ciphers |author=Alexander Maximov |url=http://eprint.iacr.org/2007/070 |date=22 February 2007 |id=Cryptology ePrint Archive: Report 2007/070 |access-date=2011-11-04}}</ref> and a team from NEC<ref name="nec">{{Citation |title=The Most Efficient Distinguishing Attack on VMPC and RC4A |url=http://www.ecrypt.eu.org/stream/papersdir/037.pdf |year=2005 |author1=Yukiyasu Tsunoo |author2=Teruo Saito |author3=Hiroyasu Kubo |author4=Maki Shigeri |author5=Tomoyasu Suzaki |author6=Takeshi Kawabata}}</ref> developing ways to distinguish its output from a truly random sequence.

===VMPC===
{{Main|Variably Modified Permutation Composition}}
Variably Modified Permutation Composition (VMPC) is another RC4 variant.<ref>{{Citation |chapter=VMPC One-Way Function and Stream Cipher |chapter-url=http://www.vmpcfunction.com/vmpc.pdf |author=Bartosz Zoltak |year=2004 |title=Fast Software Encryption, FSE 2004 |series=Lecture Notes in Computer Science |volume=3017 |publisher=Springer-Verlag |doi=10.1007/978-3-540-25937-4_14 |isbn=978-3-540-22171-5 |pages=210–225 |access-date=2011-11-04|url=https://www.iacr.org/archive/fse2004/30170209/30170209.pdf |citeseerx=10.1.1.469.8297 }}</ref> It uses similar key schedule as RC4, with
{{mono|1=j := S[(j + S[i] + key[i mod keylength]) mod 256]}} iterating 3 × 256 = 768 times rather than 256, and with an optional additional 768 iterations to incorporate an initial vector. The output generation function operates as follows:

 <span style="color: green;">''All arithmetic is performed modulo 256.''</span>
 i := 0
 '''while''' GeneratingOutput:
     j := S[j + S[i]]
     
     '''output''' S[S[S[j]] + 1]
     Swap S[i] and S[j]          <span style="color: green;">(''b := S[j]; S[j] := S[i]; S[i] := b)'')</span>
     
     i := i + 1
 '''endwhile'''

This was attacked in the same papers as RC4A, and can be distinguished within 2<sup>38</sup> output bytes.<ref name="maximov">{{Cite web |url=http://www.cryptolounge.org/wiki/RC4A |title=CryptoLounge: RC4A |access-date=4 November 2011 |archive-url=https://web.archive.org/web/20111001012601/http://www.cryptolounge.org/wiki/RC4A |archive-date=1 October 2011 |url-status=dead |df=dmy-all }}</ref><ref name="nec"/>

===RC4<sup>+</sup>===
RC4<sup>+</sup> is a modified version of RC4 with a more complex three-phase key schedule (taking about three times as long as RC4, or the same as RC4-drop512), and a more complex output function which performs four additional lookups in the S array for each byte output, taking approximately 1.7 times as long as basic RC4.<ref name ="rc4+">{{Citation |chapter=Analysis of RC4 and Proposal of Additional Layers for Better Security Margin |chapter-url=http://eprint.iacr.org/2008/396 |author1=Subhamoy Maitra |author2=Goutam Paul |title=Progress in Cryptology - INDOCRYPT 2008 |date=19 September 2008 |pages=27–39 |series=Lecture Notes in Computer Science |volume=5365 |publisher=Springer-Verlag |isbn=978-3-540-89753-8 |doi=10.1007/978-3-540-89754-5_3 |id=Cryptology ePrint Archive: Report 2008/396 |access-date=2011-11-04|url=http://eprint.iacr.org/2008/396.pdf |citeseerx=10.1.1.215.7178 }}</ref>

 <span style="color: green;">''All arithmetic modulo 256.  ''<<'' and ''>>'' are left and right shift, ''⊕'' is exclusive OR''</span>
 '''while''' GeneratingOutput:
     i := i + 1
     a := S[i]
     j := j + a
     
     Swap S[i] and S[j]               <span style="color: green;">(''b := S[j]; S[j] := S[i]; S[i] := b;'')</span>
     
     c := S[i<<5 ⊕ j>>3] + S[j<<5 ⊕ i>>3]
     '''output''' (S[a+b] + S[c⊕0xAA]) ⊕ S[j+b]
 '''endwhile'''

This algorithm has not been analyzed significantly.

===Spritz===

In 2014, Ronald Rivest gave a talk and co-wrote a paper<ref name="Rivest2014">{{cite news |last1=Rivest |first1=Ron |last2=Schuldt |first2=Jacob |date=27 October 2014 |title=Spritz – a spongy RC4-like stream cipher and hash function |url=http://people.csail.mit.edu/rivest/pubs/RS14.pdf |access-date=26 October 2014}}</ref> on an updated redesign called Spritz. A hardware accelerator of Spritz was published in Secrypt, 2016<ref>{{cite web | title=Hardware Accelerator for Stream Cipher Spritz | url=https://blogs.ntu.edu.sg/debjyoti001/files/2016/07/paper-1rf0pxd.pdf | publisher=Secrypt 2016 | access-date=29 July 2016 |author1=Debjyoti Bhattacharjee  |author2=Anupam Chattopadhyay}}</ref> and shows that due to multiple nested calls required to produce output bytes, Spritz performs rather slowly compared to other hash functions such as SHA-3 and the best known hardware implementation of RC4.

Like other [[sponge function]]s, Spritz can be used to build a cryptographic hash function, a deterministic random bit generator ([[DRBG]]), an encryption algorithm that supports [[authenticated encryption]] with associated data (AEAD), etc.<ref name="Rivest2014"/>

In 2016, Banik and Isobe proposed an attack that can distinguish Spritz from random noise.<ref>{{Cite book|last1=Banik|first1=Subhadeep|last2=Isobe|first2=Takanori|title=Fast Software Encryption |chapter=Cryptanalysis of the Full Spritz Stream Cipher |date=2016-03-20|publisher=Springer Berlin Heidelberg|isbn=9783662529928|editor-last=Peyrin|editor-first=Thomas|series=Lecture Notes in Computer Science|volume=9783 |pages=63–77|language=en|doi=10.1007/978-3-662-52993-5_4|s2cid=16296315}}</ref> In 2017, Banik, Isobe, and Morii proposed a simple fix that removes the distinguisher in the first two keystream bytes, requiring only one additional memory access without diminishing software performance substantially.<ref>{{Cite journal|last1=Banik|first1=Subhadeep|last2=Isobe|first2=Takanori|last3=Morii|first3=Masakatu|date=2017-06-01|title=Analysis and Improvements of the Full Spritz Stream Cipher|url=https://www.jstage.jst.go.jp/article/transfun/E100.A/6/E100.A_1296/_article|journal=IEICE Transactions on Fundamentals of Electronics, Communications and Computer Sciences|volume=E100.A|issue=6|pages=1296–1305|doi=10.1587/transfun.E100.A.1296|bibcode=2017IEITF.100.1296B |hdl=10356/81487|hdl-access=free}}</ref>

==RC4-based protocols==
* [[Wired Equivalent Privacy|WEP]]
* [[Temporal Key Integrity Protocol|TKIP]] (default algorithm for [[Wi-Fi Protected Access|WPA]], but can be configured to use [[AES-CCMP]] instead of RC4)
* [[BitTorrent protocol encryption]]
* [[Microsoft Office XP]] (insecure implementation since nonce remains unchanged when documents get modified<ref>Hongjun Wu, "The Misuse of RC4 in Microsoft Word and Excel". https://eprint.iacr.org/2005/007</ref>)
* [[Microsoft Point-to-Point Encryption]]
* [[Transport Layer Security]] / [[Secure Sockets Layer]] (was optional and then the use of RC4 was prohibited in RFC 7465)
* [[Secure Shell]] (optionally)
* [[Remote Desktop Protocol]] (optionally)
* [[Kerberos (protocol)|Kerberos]] (optionally)
* [[Simple Authentication and Security Layer|SASL]] Mechanism Digest-MD5 (optionally, ''historic'', obsoleted in RFC 6331)
* [[Portable Document Format|PDF]]
* [[Skype]] (in modified form)<ref>{{cite web
| url=http://www.h-online.com/security/news/item/Skype-s-encryption-procedure-partly-exposed-1034577.html
| archive-url=https://web.archive.org/web/20100711062958/http://www.h-online.com/security/news/item/Skype-s-encryption-procedure-partly-exposed-1034577.html
| archive-date=11 July 2010
| title=Skype's encryption procedure partly exposed
| publisher=www.h-online.com
| access-date=2010-07-08}}</ref>

Where a protocol is marked with "(optionally)", RC4 is one of multiple ciphers the system can be configured to use.

==See also==
* [[Tiny Encryption Algorithm|TEA]], [[XTEA|Block TEA]] also known as [[XTEA|eXtended TEA]] and [[XXTEA|Corrected Block TEA]] – A family of [[block cipher]]s that, like RC4, are designed to be very simple to implement.
* [[Advanced Encryption Standard]]
* [[CipherSaber]]

==References==
{{reflist|30em}}
<!-- ToDo: summarise the cryptanalysis results, and maybe prune a couple which
aren't so important. Wikify the names. -->

==Further reading==
* {{cite book |title=RC4 Stream Cipher and Its Variants |last1=Paul |first1=Goutam |author2=Subhamoy Maitra |year= 2011 |publisher=CRC Press |isbn=9781439831359 |url=http://www.crcpress.com/product/isbn/9781439831359 }}
* {{cite book
 |title=Applied Cryptography: Protocols, Algorithms, and Source Code in C
 |last1=Schneier |first1=Bruce |author-link1=Bruce Schneier
 |year=1995
 |publisher=Wiley
 |isbn=978-0471117094
 |chapter-url=https://www.schneier.com/book-applied.html
 |chapter=Chapter 17 – Other Stream Ciphers and Real Random-Sequence Generators
 |edition=2nd
}}

==External links==
* [http://cypherpunks.venona.com/archive/1994/09/msg00304.html Original posting of RC4 algorithm to Cypherpunks mailing list], [https://web.archive.org/web/20080207125928/http://cypherpunks.venona.com/archive/1994/09/msg00304.html Archived version]
* {{IETF RFC|4345|link=no}} – Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol
* {{IETF RFC|6229|link=no}} – Test Vectors for the Stream Cipher RC4
* {{IETF RFC|7465|link=no}} – Prohibiting RC4 Cipher Suites
* {{cite IETF|draft=draft-kaukonen-cipher-arcfour-03|title=A Stream Cipher Encryption Algorithm "Arcfour"|last1=Kaukonen|last2=Thayer}}
* [http://www.users.zetnet.co.uk/hopwood/crypto/scan/cs.html#RC4 Entry for RC4 on SCAN (Standard Cryptographic Algorithm Naming)]
* {{webarchive|url=https://web.archive.org/web/20150221230645/http://www.wisdom.weizmann.ac.il/~itsik/RC4/rc4.html|title=Attacks on RC4|date=21 February 2015}}
* {{webarchive|url=https://web.archive.org/web/20161118145850/http://www.emc.com/emc-plus/rsa-labs/historical/rsa-security-response-weaknesses-algorithm-rc4.htm|title=RSA Security Response to Weaknesses in Key Scheduling Algorithm of RC4|date=18 November 2016}}

;RC4 in WEP
* {{webarchive|url=https://web.archive.org/web/20200119101604/http://www.isaac.cs.berkeley.edu/isaac/wep-faq.html|title=Security of the WEP algorithm|date=19 January 2020}}
* {{cite journal|url=http://www.wisdom.weizmann.ac.il/~itsik/RC4/Papers/rc4_wep.ps|last1=Fluhrer|last2=Mantin|last3=Shamir|title=Attacks On RC4 and WEP|format=PostScript|journal=CryptoBytes|volume=5|number=2|date=Summer–Fall 2002|archive-url=https://web.archive.org/web/20150102135713/http://www.wisdom.weizmann.ac.il/~itsik/RC4/Papers/rc4_wep.ps|archive-date=2 January 2015}}

{{Cryptography navbox|stream}}

[[Category:Stream ciphers]]
[[Category:Broken stream ciphers]]
[[Category:Pseudorandom number generators]]
[[Category:Free ciphers]]
[[Category:Articles with example C code]]