UPDATED SEPT 17 2013: Looks like the official recommendations are coming down now for that to happen after all these NSA revelations. And it gets worse.
But here's the rub. It was so widespread during the early days of many Internet and Wireless protocols (and is STILL used), you actually CAN'T get rid of it entirely, and you can't improve upon it without breaking compatibility with older systems.
This is probably the most frustrating aspect of ALL crypto-systems: Something that is great one day, can be (probably) broken in a short time frame (5-10 years or less), but is SO great, that it gets put into EVERYTHING before all hell breaks loose, and the industry as a whole is slow to adopt new tactics and algorithms, leaving the rest of us with "Swiss cheese security."
Take DES, as an example. It was developed a long time ago when computers were still HUGE, and desktop computing hadn't really happened yet. It was quickly broken as home computers became more and more powerful in the late 80's, and as cryptanalysts developed new techniques for getting algorithms to give up their secrets (quite literally) through careful bit manipulation and extensive comparison of inputs and outputs, it became clear that a new algorithm was needed.
In the move to get rid of DES, it was so prevalent, that the best anybody could do at the time (since DES was an adopted NIST FIPS standard) was to simply implement it 3 times in succession with a longer overall key (once forward, once backward, once again forward, each with a different, usually independent, piece of the overall key). Thus "Triple DES" or "3DES" was born. Hardly any new hardware required, and very little new software, just use what you have 3 times.
This was... ok... except it was later determined that the process of having the center transformation reversed caused some of the bits in the key to "not matter." Instead of 168 bits of security, you basically only get 112. Bummer.
And NIST calls it, effectively, 80. Double bummer.
And with modern hardware, a single DES key can be broken by brute-force in a matter of minutes or hours. Triple bummer. (see what I did there?)
Then came AES, which was chosen after a long competition held by NIST with some of the best crypto minds in the world (it was adopted in 2002 officially after an exhaustive process starting in 1997). It's only just now starting to show cracks (in 2011 or 2012, I can't find the original article, someone figured out that in the 256 bit version, the key expansion schedule had some peculiar behavior that COULD someday lead to an attack).
AES is now one of the most adopted algorithms in software*, because it's free, open source, and actually required for many US Government processes. (*I'm making an educated guess here based on my own experience.) It's even found its way into some Intel CPU architectures as a stand-alone Arithmetic Logic Unit (ALU), right alongside all the other key parts of the CPU. Try changing that out in all the PC's in the world if it were ever broken! UPDATE Another CPU was announced recently! I just don't have the link handy, but many have Tweeted about it.
But I'm getting away from the plot...
RC4 was one of those algorithms that emerged and showed great promise due to its great speed and small memory footprint (less than 280 bytes in memory). It was so fast, in fact, that it was adopted when the first short-range, wireless connectivity standards were being implemented (remember 802.11a and WEP?). It does, however, still require a license (as of the time of writing this article) from RSA, the original developer.
The trouble is, by the time all the faults were discovered, 802.11a and all of its children were already in VERY widespread use. The idea of forcing manufactures and software vendors to change hundreds of thousands of devices (many of which had no way to "flash" new programs) was completely out of the question. New standards, which overcame SOME of the flaws, were later adopted (enter WPA, WPA2Personal/Enterprise), but the damage had already been done.
RC4 is dead! Long live RC4!
Yup, it's still out there, in use, in production, and it shouldn't be... but I digress.
One thing I will say, though, is that for quick-and-dirty encryption (read weak and probably easily cracked), its speed is largely unmatched. So even I dipped my toes in the water with a way to try and improve it,
UPDATE: Yeah, I'm essentially striking this from the record. Even this "improvement" is just polishing a turd. JUST DON'T USE RC4!!!!
2. Initialization is increased from 1 pass through the state buffer to 3
3. First 4096 bytes of stream output (without salt) are dropped.
4. A salt is added to all final output bytes.
(a) The salt is defined as a [RIPEMD-160] HMAC buffer (keyed by *original* input key)
(b) A single persisted byte 'R' determines the index from the salt buffer to be used
(c) The salt byte at index 'R' is XOR'd with the next stream output byte, which is