Funny thing about the
RC4 weakness.
It was used in the initial WiFi protocols, and since WiFi sends the same packets over and over, the weakness of
RC4 in those initial permutations was part of the reason WiFi was cracked.
The improved WiFi protocols added some iterations to the start of the
RC4 stream before actually using it.
Kinda like letting a motor run to "get it warmed up" in the winter I guess
After that
RC4 (or ARCFOUR as the open source variant is called due to
RC4 being a trademark) is pretty solid.
Most good stream ciphers (like
RC4) is twice as good as a block cipher at the same key bit size. So a stream cipher at 1024bits is as secure as a block cipher at 2048bits.
A stream cipher also has the benefit of not needing any padding like block ciphers do.
And if a single byte in the stream is wrong then the rest of the stream is useless, whereas block ciphers recover at the next block. I consider this a security feature really and why I like stream ciphers so much
The down side is that a stream cipher need to resend all data if it's corrupted. BUT you can easily add your own block and checksum wrapper and send the stream is blocks yourself, getting the best of two worlds I guess
I'm gonna read through that paper but I doubt I'll attempt to make ARCFOUR-A or -B or -C or -whatever in the nearest future. (if nobody makes one I might end up doing one though)
The code in my post I mentioned earlier is quite optimized and should be one of the fastest ones on these forums (unless a ASM one is lurking around I haven't noticed) and hopefully a nice starting point.
Wikipedia might be a nice starting point too, but considering this will be a modified/enhanced ARCFOUR maybe one should not call it exactly that as it's not stream compatible with ARCFOUR or
RC4.
But I find something like a improved ARCFOUR a must, we got MD5 and combine that with ARCFOUR and you got some quick (very quick actually) hash and encrypt combo.
PS! In my code I iterate/permutate a few times before actually encrypting the data, it may be possible to just use a optimized standard ARCFOUR and simply feed it x amount of binary 0's at the start to get the same permutation iterations. But don't take my word for that though, study the stuff out there describing the weakness and how to avoid it. It's a while since I last read up on this and I could be mistaken.
But if you simply can add on some throwaway data at the start then the standard ARCFOUR could be implemented as is (with a big warning in the documentation to add some throwaway data at the start I guess) thereby retaining stream compatibility.
With a good password (and my post earlier shows how to make a pass longer while avoiding making it weaker, in fact it gets a bit stronger even) ARCFOUR should be adequate for general
encryption use just like MD5 is adequate for general hashing and CRC32 is adequate for general checksums. So a nice team of quick code implementations.
If no weaknesses are introduced in the implementation then it should be enough to protect your average data. (if you are worried about computer slave cracking farms or super computer cracking then the data you are worried about need close to military grade
encryption anyway) ARCFOUR data encrypted with the extra startup iterations and a good password (combined with the expanding MD5 tip in my post) should keep the data safe for maybe a decade or two, to protect the password further I guess you could even mix the pass or concatenate with the date and filename as well to avoid compromising the password in case a single file manages to be cracked a few years later.
What I'm saying is that ARCFOUR itself, while it has a few flaws, those flaws are known and can be avoided. Other than that it is time tested and solid and not weak in and of it self. So using it as the core and instead enhancing it by pre-processing the password and even the data (and don't forget those extra empty permutations at the start) not only keeps the tested integrity of the original but improves it further.
As soon as you start altering the actual ARCFOUR stream code etc. All bets are off and it can be easy to leave a huge weakness open.
Just ask all those that did their own stream ciphers only to realize thir clever Xor did not handle binary 0 so well and bin 0 would reveal the password. Oops!
At least ARCFOUR is solid, which is very important. MD5 is solid as well despite a few collision hits, but it's still solid.
Minirant (and why I like MD5 and
RC4): How scientists can expect to get a perfect hash or checksum is beyond me, the only way to get a perfect one with 0% chances of collisions is if the checksum result itself is as large as the file it's checksumming. *laughs*
And as far as
encryption goes, the only truly safe encryptions are "One Time Pad" based ones with insanely huge key bit sizes. It is more important to delay or disinterest any "evil" people long enough until that data you transfered is no longer valid or outdated and thus no longer sensitive. Safe for 1000 years? Overkill. a few decades? Fie I guess. Imagine encrypting source code, do you believe that todays source code would even matter 10-20 years from now?
*laughs*
