Talk:RC4

message: :This is a consolidation of two talk pages, resulting from a move. Neither section is an archive, threads in both sections can continue here, and the page history will make it obvious what has occured if there's any doubt... not that I can think of any reason you'd want to know anyway... Andrewa 19:32, 19 Sep 2004 (UTC)
thread_title: Untitled

message: The second and third paragraphs plus the code fragment look a lot like part of the writeup by Bruce Schneier in Applied_Cryptography 2nd ed. Did Bruce donate this part, or give permission? (anon -- 10:59, 11 May 2003)
:I suspect that even if the code fragments were copied wholesale, they'd be legitimate as "scenes a faire". (See Online service provider law#Sometimes there are only a few ways to do something). As for the rest, I don't have my copy near this machine, but I'll compare them tonight and report back. Securiger 07:05, 30 May 2004 (UTC)
replies: text: Ah, just checked the page history and saw that comment was made a year ago. Presumably been changed since then, but at any rate, there is very little similarity to Schneier. The code fragments are somewhat similar, but - given the essential simplicity of the algorithm - about as different as actually possible. Securiger 00:36, 1 Jun 2004 (UTC)
replies: text:  Yep, I agree. I've also had a look at the page as it was back then  (http://en.wikipedia.org/w/wiki.phtml?title=RC4_%28cipher%29&oldid=1107229) and it seems to be quite different from Applied Cryptography. You might — possibly — be able to make a case that parts of the second paragraph were written based on information in the second paragraph of Schneier's description (Ch 17.1, p 397), but this is (of course) perfectly legitimate. — Matt 11:19, 1 Jun 2004 (UTC)

text: Yep, well spotted! I think the case of WEP is complicated by the fact that "128-bit WEP" is effectively 104 bits, and "64-bit WEP" is effectively 40 bits, so I've removed the mention of WEP as an example. — Matt 15:17, 17 Sep 2004 (UTC)
thread_title: Derivative / copyvio from Schneier?

message: Any objections to moving RC4 (cipher) to RC4 (and including a disambiguation header) since the encryption algorithm is the meaning that most people will be looking for when coming here? Evidence: try a Google test for RC4; note that Route Coloniale 4 is an orphan, but lots of pages reference the cipher. — Matt 21:38, 12 Sep 2004 (UTC)
thread_title: Let's put the encryption article here

message: IMO the redirect at RC4 (cipher) and its talk page are both now redundant, and should be listed on RfD as soon as the links through them are tidied up. I've started this but help welcome. Andrewa 19:40, 19 Sep 2004 (UTC)
thread_title:  Moved, some cleaning up still to do. 

message: Could an admin please move RC4 (cipher) to RC4? "Primary topic" disambiguation is more appropriate here than "equal" disambiguation. — Matt 15:40, 19 Sep 2004 (UTC)
replies: text: Will do. The history of the current RC4 although extensive is all disambiguation page maintenance, and doesn't need preservation. Andrewa 19:11, 19 Sep 2004 (UTC)

text: Done. Discussion on both pages seemed to have reached consensus that this was the best thing, and has been consolidated at talk:RC4. Any problems comment on my talk page for the fastest response from me. Andrewa 19:27, 19 Sep 2004 (UTC)
thread_title:  Page move request 

message: Correct me if I'm wrong, but aren't the problems in RC4 addressed by adding the trivial modification to the KSA (repeated mixing) proposed by CipherSaber-2?  I pointed that out in a revision a long time ago, and I just noticed that ciphergoth removed it (also a while ago).  I think his motivation in removing it was because he thought it was off-topic, but I disagree.  The reason I put that mention of CipherSaber-2 was not just to say, "hey CipherSaber-2 is based on RC4".  It was to counteract the suggestion of the artcile that RC4 was "broken".  It may be "broken" in its original form, but CipherSaber-2 is still basically RC4 and as far as I know, it is still considered secure.  I would like to put some mention of this important point back into the article. &mdash User:Tzadikv, 03:06, December 15, 2005
:Trivial point first - please sign things you put on the talk page.  You can do this simply by writing ~~~~ at the end - Wikipedia will substitute your user  name and the date.  Thanks.
:CipherSaber-2 is not RC4.  It is very closely related, but in cryptography we consider even the smallest tweak to be the  creation of a new, distinct cipher.  I do not believe this new cipher has received very much cryptanalysis, so its security is unknown.
:At the time, I tried to persuade the author to use RC4 directly and discard a portion of the keystream, which is a construction that is widely used and analyzed, but for some reason he opted not to.
:Even this is not considered to meet the high standards of a modern stream cipher, since a practical distinguisher exists (Fluhrer and McGrew, 2000)
:Nonetheless, it's probably worth a very brief mention, something like "CipherSaber-2 uses a cipher very closely related to RC4 with a tweak to defeat the FMS attack" or something. — ciphergoth 08:50, 15 December 2005 (UTC)
replies: text: The CipherSaber-2 tweak is the equivalent of hashing the key + nonce with a fairly weak 256 byte (not bit) hash. Attempting to break CS2 as though it were stock RC4 results in facing the full 2048 bit strength; however knowing it is CS2 results in the attack being the same as attacking an unmodified RC4 except for the FMS attack and similar attacks don't work. 108.246.8.231 (talk) 20:00, 1 January 2013 (UTC)
thread_title:  Put back mention of CipherSaber-2? 

message: Is the term "MARC4" in sufficiently widespread use to warrant a mention?  78 Google hits for "MARC4 RC4", only one Citeseer hit.  Since some papers recommend discarding more than 256 bytes anyway, I'm not sure it's worth putting in.  But maybe it's in more widespread use than I realize.  Does anyone know where this term was coined?  Thanks! — ciphergoth 06:33, 10 April 2006 (UTC)
thread_title:  MARC4 

message: The article states that the second output byte is biased toward zero with "high" probability and that the first byte is "also" biased toward zero. Is there a more precise value for this bias available? Nmesisgeek (talk) 03:34, 1 December 2008 (UTC)
thread_title:  Output biasing 

message: I saw that all implementation links was removed and the reason was that Wikipedia is not a web directory.
I respectfully agree to this, but I think if a sub section was provided in external links with some examples of implementations, it would be very helpful for those that wants to use it at their projects 
and I think that it will not make Wikipedia a web directory, just make it more complete and more useful.
--Ali Farhadi 15:34, 28 June 2006 (UTC)
replies: text: We do have a problem with people spamming implementation links to crypto algorithm pages, and we've started being more strict about it as a result. Probably the best solution would be to either find or create a list of implementations somewhere on the web (Open Directory Project?), and link to that. — Matt Crypto 16:07, 28 June 2006 (UTC)
replies: text: I agree with Mr. Farhadi. I only added my implementations as links because both links to the C implementations were dead (at the time), and I figured it would help. While I understand that Wikipedia is not a web directory, I don't quite think it proper to remove implementation links on only one or two articles citing this reason, and leave the others. Also, would it be OK if I posted the test vectors from the Wikisource page that was deleted (combining them with the current ones)? — Reikon 20:30, 14 September 2006 (UTC)
thread_title:  What is your opinion of implementation links? 

message: What langauge are the examples in, and is that the full code? 75.15.242.0 (talk) 00:55, 2 January 2007 (UTC)
replies: text: The example description is in pseudo code so not written in a specific existing programming language. And yes, the example is almost a full description. The description lacks a surrounding function header that takes the key, keylength, cleartext and cleartextlength as paramaters. And it lacks one line in the end where the output bytes are XORed onto the cleartext to get the ciphertext. --David Göthberg 06:10, 15 January 2007 (UTC)
replies: text:  Would anyone mind if the pseudo code example were to have obvious end-of-loop indicators such as endwhile and endfor? Both external links on the pseudo code page titled "pseudocode standards" specify using endwhile and endfor (except the second one which doesn't mention 'for.' It only specifies endwhile). I, (being a hobbyist real language programmer), I was a a bit confused at first due to the lack of instruction group indicators -- normal (like {}) or otherwise. Thanks! -Jesse. January 23 2007, 6:08PM —The preceding unsigned comment was added by 64.146.180.232 (talk) 02:29, 24 January 2007 (UTC)
replies: text:  Geez. Python?! Can someone create an implementation in a slightly more widely used language, Like Autocoder?  —Preceding unsigned comment added by GuyInCT (talk • contribs) 16:42, 8 September 2007 (UTC)
thread_title:  What language? 

message: I think (but am not sure) that this graf is making the mistake of equating RC4 (a primitive) with constructions and cryptosystems that actually use RC4. This would fall more under the category of an "implementation risk" than a flaw in the algorithm. Can someone sanity check and either fix or remove the tag on the graf? Thanks. --- tqbf 22:55, 15 November 2007 (UTC)
replies: text: Have had a go at rewording — ciphergoth 16:16, 30 November 2007 (UTC)
thread_title:  RC4 and nonces 

message: The intro says RC4 "is not recommended for use in new systems."  That seems like a fairly reasonable position (doubly so if you just mean RC4 with no bytes dropped), but I worry it may be OR unless we can find an anti-recommendation.
It's also sad and interesting to me that RC4's problems stem from a bad key schedule, with just the distinguishing attack on the actual PRNG.  I don't know whether there's any legitimate way this should to be reflected in the article, but figured I'd throw it out there. 75.24.111.126 (talk) 17:35, 16 January 2008 (UTC)
thread_title:  RC4 not suggested for new cryptosystems? 

message: I redid it in perl. Mine shows all the steps for encryption and decryption and prints strings so you can see the output.
my $key = "Secret";
my $plaintext = "Attack at dawn";
my $hexText = ;
for ( split(//,$plaintext) ) 
	{ $hexText .= sprintf("%01X",ord); }
print "hex('$plaintext') => $hexText\n";
my (@S,$i,$j); # state variables
KSA($key);
# PRGA encryption
my $cipherText = PRGA($hexText);
print "RC4($hexText) => $cipherText\n";
KSA($key);
# PRGA decryption
$hexText = PRGA($cipherText);
print "RC4($cipherText) => $hexText\n";
# And the original string
my $origString = ;
for ( $hexText =~ /../g ) {
	$origString .= chr hex;
}
print "dehex($hexText) => $origString\n";
sub KSA { 
	my ($k) = @_;
	my @keyArray = split(//,$k);
	
	for ( 0 .. 255 )
		{ $S[$_] = $_; }
	$j = 0;
	for $i (0 .. 255 ) {
		my $keyValue = ord($keyArray[$i % ($#keyArray + 1)]);
		# mix in the key
		$j =  ( $j + $S[$i] + $keyValue ) % 256;
		($S[$i],$S[$j]) = ($S[$j],$S[$i]); #swap
	}
	$i = 0;
	$j = 0;
}
sub PRGA {
	my ($text) = @_;
	my ($keyStream, $cipherText);
	my @plainTextArray = $text =~ /../g;
	for ( @plainTextArray) {
		$i = ($i + 1) % 256;
		$j = ($j + $S[$i]) % 256;
		($S[$i],$S[$j]) = ($S[$j],$S[$i]); # swap
		$keyStream = $S[($S[$i] + $S[$j]) % 256];
		$cipherText .= sprintf("%02X",$keyStream ^ hex);
	}
	return $cipherText;
}
Addps4cat (talk) 23:01, 5 April 2008 (UTC)
thread_title:  Perl implementation 

message: The Gpcode.AK is a new June 2008 computer virus and trojan horse originating from Russia. It uses RC4 cipher routine as supplied by the Windows built-in cryptographic provider service to encrypt precious document files on infected computers.
The Gpcode.AK virus takes those files hostage, because as a final act of malice, it discards the RC4 key and only keeps a further ciphered copy of it, hidden within an RSA-1024 envelope.
The victimized user only has four choices:
A. Pay the demanded ransom to the hacker, so you get your files back
B. Forget about your lost documents, write off the resulting losses and reinstall Windows
C. Crack RC4 algorythm to get your files back directly and make fun of the hacker
D. Crack RSA-1024 math to get the key which allows deciphering the files yourself, so no pay to hacker
Sorrowfully option C. and D. does not work currently, as the crypto code of Gpcode.Ak virus appears to be sound and well-written, taking an estimated 15 million years to crack if using brute-force computing methods only.
Unless the NSA helps out with a secret RC4 or RSA-1024 vulnerability trick, the infected users will probably never get their documents back for free, they will need to pay the ransom.
I think this scandal may make an interesting addition to the RC4 article. 91.83.19.207 (talk) 20:06, 8 June 2008 (UTC)
thread_title:  RC4 = RedCode4? 

message: This looks like error to me, but I'm not self confident enough to fix it right away ;)
The PRGA code reads as follows:
    i := 0
    j := 0
    while GeneratingOutput:
        i := (i + 1) mod 256
        j := (j + S[i]) mod 256
        swap(S[i],S[j])
        output S[(S[i] + S[j]) mod 256] ^ input[i]
    endwhile
The last line in the loop XORs RNG output byte with byte i of the input stream.
Index i is MOD 256, so we are looping only first 256 bytes of the input. There should be additional var for input indexing. OTOH, this code snippet is about generating random numbers, so whole XORing thing could be dropped. After all it's trivial way to use any stream cipher, and only confuses here.
Test vectors should also contain prng outputs without plaintext XORing.
Jatufin (talk) 00:29, 8 November 2008 (UTC)
replies: text: It looks like this bug was introduced here.  Previously, the PRGA pseudo-code was only producing the key stream rather than the actual ciphertext.  I've reverted the change, as the text indicates that the code generates a key stream. --James (talk) 00:50, 24 November 2008 (UTC)
thread_title:  Error in pseudo code? 

message: I originally didn't post a complete rationale for the minor changes I did to the C code, because I felt that the changes were uncontroversial. I guess I was wrong, since the changes has now been reverted. So here is the rationale, with references to the ISO C standard.
That the example should be C90-compatible is of course just my subjective opinion. But since the required changes are so minor I think it is unecessary to make the example ill-formed on the most frequently used C implementations.
*Changed:
 
/* ... */
unsigned char temp = S[i];
to:
 
unsigned char temp;
/* ... */
temp = S[i]; 
Rationale: In C90, declarations may not appear after executable statements. 
*Changed:
 
unsigned char *test_vectors[3][2] = { 
{"Key", "Plaintext"}, 
/* ... */
to:
 
unsigned char test_vectors[3][2][32] = { 
{"Key", "Plaintext"}, 
/* ... */
Rationale: The former is ill-formed because the literal, when evaluated, yields a (const) char * (6.4.5/5), not an unsigned char *. This conversion requires an explicit cast (6.5.4/3). The latter is permitted by (6.7.8/14).
*Changed:
 
rc4_init(test_vectors[x][0], strlen(test_vectors[x][0]));
to:
 
rc4_init(test_vectors[x][0], strlen((char*)test_vectors[x][0])); 
Rationale: Again, an explicit cast is required per (6.5.4/3).
*Changed:
 
/* ... */
int y;
to:
 
int y;
/* ... */
Rationale: Same as above, in C90, declarations may not appear after executable statements.
decltype 10:31, 10 February 2009 (UTC)
thread_title:  Rationale for the "inane" changes to the C implementation 

message: Does anyone know about a lower bound to the period length of this generator?
The state space (set of possible content of the array S) is finite, so after some steps a previous state must occur again. Can this be a problem? Seemingly not, because I haven't read about the period length yet. Can it be proved that the period is always long enough?  —Preceding unsigned comment added by 84.164.191.247 (talk) 16:18, 10 October 2009 (UTC)
thread_title:  Period length 

message: 1. Change max key size to 2048 bits.
2. Use types from stdint.h in the C examples.  —Preceding unsigned comment added by 80.251.192.2 (talk) 05:34, 9 June 2010 (UTC)
replies: text: Where did you take that 2048-bit key size from? There are many ciphers that can be used with large keys, but what matters is key sizes that it was intended for — i.e. key sizes where it was conjectured to actually provide the requested amount of security. -- intgr [talk] 23:41, 9 June 2010 (UTC)
thread_title:  Two small things (suggestions) 

message: def rc4(msg,pw):
   s = []
   for i in range(256):
      s.append(i)
   j = 0
   for i in range(256):
      j = (j + s[i] + ord(pw[i % len(pw)])) % 256
      tmp = s[i]
      s[i] = s[j]
      s[j] = tmp
   i = 0
   j = 0
   cmsg  = ''
   for k in range(len(msg)):
      i = (i + 1) % 256
      j = (j + s[i]) % 256
      tmp = s[i]
      s[i] = s[j]
      s[j] = tmp
      rnd = s[(s[i]+s[j]) % 256]
      out = (ord(msg[k]) ^ rnd) % 256  
      cmsg = cmsg + chr(out)
   return cmsg  —Preceding unsigned comment added by 178.203.183.22 (talk) 17:21, 4 May 2011 (UTC)
thread_title:  Python 

message: The following statement gives the impression that there is a weakness in CBC mode:
the 2011 BEAST attack on TLS 1.0, which exploits a known weakness in the cipher block chaining mode used with all of the other ciphers supported by TLS 1.0
That is however slightly misleading as the weakness is due to TLS using CBC incorrectly. TLS uses a predictable IV, but CBC requires the IV to be unpredictable. Kasperd (talk) 20:40, 15 December 2011 (UTC)
replies: text: I changed the sentence to indicate that the fault is not with CBC itself; feel free to improve upon it if you feel it is still not clear enough. — DataWraith (talk) 09:57, 16 December 2011 (UTC)
thread_title:  Misleading statement about CBC 

message: The test vectors have been changed around a few times without a good explanation
in the past months, so I'd like to make my case for the following vectors (or
shortened versions of them), which I think are the correct ones, and have been
in the article previously:
Key   	Keystream                          	Plaintext	Ciphertext
Key   	eb9f7781b734ca72a7194a2867b64295...	Plaintext	bbf316e8d940af0ad3
Wiki  	6044db6d41b7e8e7a4d6f9fbd4428354...	pedia    	
1021bf0420
Secret	04d46b053ca87b594172302aec9bb992...	Attack at
dawn	45a01f645fc35b383552544b9bf5
Rationale:
* The Ciphertext values were previously verified by multiple people. See Talk:RC4#Test_vectors.
* The Ciphertext is constructed from the Plaintext by xoring with the Keystream. Reversing this computation, we get the correct Plaintext back using the proposed values:
Ciphertext                  	Keystream                   	XOR                         	XOR (Ascii)
bbf316e8d940af0ad3          	eb9f7781b734ca72a7          	506c61696e74657874          	Plaintext
1021bf0420                  	6044db6d41                  	7065646961                  	pedia
45a01f645fc35b383552544b9bf5	04d46b053ca87b594172302aec9b	41747461636b206174206461776e	Attack at dawn
*Using any other keystream would obviously result in different decrypted text, hence I think the currently listed keystream values (4B33849DC0C81DA8, 8BA02E9A20B15BBC, 2EB51E93263FB871) are incorrect.
* Lastly, I wrote an RC4 implementation a few years ago, which produces the values I listed. The implementation output matches  the official test vectors from RFC 6229, so I am fairly confident it is correct. You can find it here.
— DataWraith (talk) 15:50, 1 July 2012 (UTC)
replies: text: FWIW I've added RFC 6229 to the external links, maybe you want to add your Ruby github source in this line? Source code for an almost twenty years old algorithm matching what is published in an RFC might not be considered as "original research", but I let the registered users hash (pun) this out... ;-) 89.204.155.87 (talk) 21:45, 29 March 2013 (UTC)
thread_title:  Keystream correctness 

message: In the session "The key-scheduling algorithm (KSA)", it says "'keylength' is defined as the number of bytes in the key and can be in the range 1 ≤ keylength ≤ 256"
So, 1 ≤ keylength ≤ 256 is of bits or bytes? Can anyone write it clearly? Thanks --Gqqnb (talk) 15:08, 14 November 2012 (UTC)
thread_title:  1 ≤ keylength ≤ 256 ? 

message: "This conjecture was put to rest in 2004 with a formal proof given by Souradyuti Paul and Bart Preneel."
 
It is unclear to me, without prior knowledge and with reading the source, what this means? "Put to rest" must mean that any "uncertainty was resolved". But in what direction?
Did they prove the "Combinatorial problem" exist? Or did they disprove it?  — Preceding unsigned comment added by 87.104.56.74 (talk) 16:47, 16 December 2012 (UTC)
thread_title:  Combinatorial problem unclarity 

message: In OpenBSD arc4random used to be based on RC4, but it's now based on chacha20, see the original announcement, the same change in the implementation of /dev/random, the manpage; other operating systems/projects using arc4random are likely still using RC4 (eg FreeBSD).
Useurandom (talk) 20:56, 18 March 2014 (UTC)
thread_title:  arc4random no longer based on RC4 

message: see https://github.com/jsonn/src/commit/fac432726d0c90b62d0802e9912f1e63de053858  — Preceding unsigned comment added by 82.48.101.60 (talk) 18:01, 1 December 2014 (UTC)
thread_title:  TODO - NetBSD now based on chacha20 (reduced to 8 rounds) 

message: The Spritz link in the "See Also" section redirects back to this RC4 article.
24.89.3.219 (talk) 20:35, 28 September 2015 (UTC)
replies: text: Thanks, removed it from see also. By the way, Wikipedia is a wiki that you could edit yourself, too. -- intgr [talk] 21:10, 28 September 2015 (UTC)
thread_title:  Recursive Spritz link 

message: Hello fellow Wikipedians,
I have just added archive links to  on RC4. Please take a moment to review my edit. You may add  after the link to keep me from modifying it, if I keep adding bad data, but formatting bugs should be reported instead. Alternatively, you can add  to keep me off the page altogether, but should be used as a last resort. I made the following changes:
*Attempted to fix sourcing for http://cypherpunks.venona.com/date/1994/09/msg00304.html
When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at ).
Cheers.—cyberbot IITalk to my owner:Online 03:14, 31 March 2016 (UTC)
thread_title:  External links modified