SRL Archive - Research & Development Lounge

Was bored, and I was angry at TEA (Tiny Encryption Algorithm), so I decided to implement RC4 instead :)
According to Wikipedia, "RC4 (also known as ARC4 or ARCFOUR) is the most widely-used software stream cipher and is used in popular protocols such as Secure Sockets Layer (SSL) (to protect Internet traffic) and WEP (to secure wireless networks). "

It seems to be compatible with every RC4 implementation, except that it doesn't pad the text that needs to be encrypted to match the length of the key :) So use a bigger text than key, or equal length ;)

Script+Demo

program New;
var
  s : array [0 .. 255] of byte;
  i, j : integer;
const  cyphertext = 'f¬o}bvU\€&bRÓÇ6(Ê-…ù’©®	1XÎɱ~íÃÝúÛX*';
       Key = 'testmeh';
procedure InitRandomGen(key : string);
begin
 for i := 0 to 255 do
     S[i] := i;
 for i := 0 to 255 do
 begin
   j := (j + S[i] + (ord(key[(i mod (length(key))+1)]))) mod 256;
   swap(S[i],S[j])
 end;
 i := 0;
 j := 0;
end;
function GenerateByte : byte;
begin
  i := (i + 1) mod 256;
  j := (j + S[i]) mod 256;
  swap(s[i], s[j]);
  result := S[(s[i]+s[j]) mod 256];
end;
function EncryptRC4(text, key : string) : string;
var CC, LL : integer;
begin
  LL := length(text);
  InitRandomGen(key);
  result := text;
  for CC := 1 to LL do
  begin
    result[CC] := chr((ord(text[cc])) xor GenerateByte);
  end;
end;
begin
  writeln(EncryptRC4(cyphertext, key));
end.

Nice, how could you use this in an script?

Easy: paste all stuff into your script, then call EncryptRC4(TheText, SecretKey); For decrypting call the same function, but with TheText = the encrypted text :)
Useful for stuff like encrypting usernames/passes stored on hard disk :D

Wow, very useful, password in it..cool, though I think I can't use it anywhere..

Is it easy to crack? ;)

RC4 is pretty secure, but according to Wikipedia, the first 256 to 1536 bits might reveal something about the key. Just get a long enough key (like 20 chars or so) and add some random crap to the front of the string and you should be fine :)

Ow, there may be 1 problem…

When I copied encrypted text to scar coding window, it switched line itself…I think there was #13 between p and \.

encrypted text from debug window

ˆ¤žpƒŠp\‚"»ō

After pasting it to coding box it appears like this(it happens when I paste it here aswell):

const cyphertext = 'ˆ¤žpƒŠp
\‚"»ō';

Causes syntax error, in case I use backspace to put lines back together, it won't decrypt it correctly, end of text "fucks up".

I hope you got what I mean.

Edit:
And it's pretty bad to store it on paper, very hard to type in later…very much un-common characters…

But that's just me. I didn't want to say you should make them to usual keyboard chars…

You might wish to modify it to output the string in hexidecimal form, shouldn't be that hard to add.

FYI

Security

RC4 falls short of the standards set by cryptographers for a secure cipher in several ways, and thus is not recommended for use in new applications.

Unlike a modern stream cipher (such as those in eSTREAM), RC4 does not take a separate nonce alongside the key. This means that if a single long-term key is to be used to securely encrypt multiple streams, the cryptosystem 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 hashing a long-term key with a nonce. However, many applications that use RC4 simply concatenate key and nonce; RC4's weak key schedule then gives rise to a variety of serious problems.


Biased Outputs of the RC4

The keystream generated by the RC4 is biased in varying degrees towards certain sequences. 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 high probability. Such bias can be detected by observing only 256 bytes.

Souradyuti Paul and Bart Preneel showed that the first and the second bytes of the RC4 were also biased. The number of required samples to detect this bias is 225 bytes.

Fluhrer and McGrew also showed such attacks which distinguished the keystream of the RC4 from a random stream given a gigabyte of output.[3]


Fluhrer, Mantin, and Shamir attack

In 2001 a new and surprising discovery was made by Fluhrer, Mantin and Shamir: over all possible RC4 keys, the statistics for the first few bytes of output keystream are strongly non-random, leaking information about the key. If the long-term key and nonce 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. This and related effects were then used to break the WEP ("wired equivalent privacy") encryption used with 802.11 wireless networks. This caused a scramble for a standards-based replacement for WEP in the 802.11 market, and led to the IEEE 802.11i effort and WPA.

Cryptosystems can defend against this attack by discarding the initial portion of the keystream. Such a modified algorithm is traditionally called "RC4-drop[n]", where n is the number of initial keystream bytes that are dropped. The SCAN default is n = 768 bytes, but a conservative value would be n = 3072 bytes. [4]

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. Erik Tews, Ralf-Philipp Weinmann, and Andrei Pyshkin used this analysis to create aircrack-ptw, a tool which cracks 104-bit RC4 used in 128-bit WEP in under a minute[5] Whereas the Fluhrer, Mantin, and Shamir attack used around 10 million messages, aircrack-ptw can break 104-bit keys in 40,000 frames with 50% probability, or in 85,000 frames with 95% probability.

-Wikipedia