Encryption using the RC4 technique

  The CipherSaber technique takes a given key, normally about 18-20 chars,
    and appends a randomly generated 10 byte IV.  
  To encode a file, your program randomly generates this 10 byte IV and writes this
    IV to the first of the file.  Then the encoded data goes next.  To decode
    a file, your program gets the 10 byte IV from the file, appends this to
    the end of the given key and decodes the file, sending it to a different
    file. Again, see http://ciphersaber.gurus.org/ for more info.  Look under
    "How to get RC4" on his FAQ list.

    The cknight.cs1 file on the above page mentioned is your
    "wall certificate" as a .gif file.  If your decoder works correctly
    and you decode this file, you should have a valid .gif file.
    Use your favorite .gif file viewer (most browsers), and view this
    file.

                      -----========================-----

Here is the way a "CipherSaber" file is decoded/encoded:

   RC4 uses two arrays of eight bit bytes. The "state" array is 256 bytes
     long and holds a permutation of the numbers 0 through 255.
   The "key" array can be of any length up to 246 bytes.
   RC4 also uses two index variables i and j that start off as zero.
     (you don't have to use i and j.  They are given here for explanation
      purposes only)
   All variables are eight bits long and all addition is performed
     modulo 256.  This means that if you add two numbers and the sum
     is greater than 256, you go back to the beginning and move to the
     offset of the remainder.
     i.e.:  128 + 130 = 258
            258 mod 256 = 2
            so now move to offset 2 in the 256 byte array
            (remember that the array is 0 based, 2 is the third pos)

   RC4 has two phases: key setup and ciphering.
    The key setup phase is only done once per message and starts by
     initializing the entire state array so that the first state element
     is zero, the second is one, the third is two, and so on.
    The state array is then subjected to 256 mixing operations using a loop
     that steps i through the values from zero to 255.
     Each mixing operation consists of two steps:
      Add to the variable j the contents of the ith element of the state
      array and the nth element of the key, where n is equal to i modulo
      the length of the key.  (remember, the key here means the 10 byte IV
      at the front of the file, (or the one your program creates, if
      encoding), and the given key on the command line. (Key+IV)
     Swap the ith and jth elements of the state array.
   After the entire mixing loop is completed, i and j are set to zero.

   During the ciphering operation, the following steps are performed for
    each byte of the message:
     The variable i is incremented by one
     The contents of the ith element of 'State' is then added to j
     The ith and jth elements of 'State' are swapped and their contents
      are added together to form a new value n.
     The nth element of 'State' is then combined with the message byte,
     using a bit by bit exclusive-or operation (XOR), to form the output byte.

   The same ciphering steps are performed for encryption and for decryption.

   Note that in CipherSaber the RC4 key array consists of the user's
    CipherSaber key followed by the 10 byte initialization vector.
    This IV is the first 10 bytes of the file to be decoded, or your
    randomly generated IV to be put to the new encoded file.


   If you where going to create a "CipherSaber" program to use for yourself,
     you would want to create a very good random number generator.
    For instance; if you were to use the disk serial number and the current
     date as the 'randomizer', then every file you encoded on a particular
     date, would have the same IV.  Not good.
    Another example would be that if you called this program with the same
     key for each file, and used the contents in the keyboard buffer as the
     randomize text, the keyboard buffer still contains the key you entered.
     Hence, the IV would contain a similarity to the key.  Also not good.
    For a good IV, you will have to do some R&D.  Pick a good scheme.
     If you don't care about the program taking a second or two longer to
     execute, try using many variations.  Maybe combine the date, time,
     disk serial number, and the Master Clock Count all in the same IV.
    Again, see http://ciphersaber.gurus.org/ for more info on creating good
     randomized 10 byte IV's.)