SAF evolved from my answer to the CipherSaber challenge: that anyone with some minimal amount of code inscribed on their soul should be able to, in the simple interests of freedom, be able to produce strong encryption software at the drop of a hat. The algorithm proposed was of course symmetric — just try coding large-prime-factorization in thirty-odd lines of **any** language — and actually surprisingly secure for the amount of code required to produce it: RC4.

Well, not RC4, exactly. See, still thinks they have some sort of proprietorship over the algorithm, even though it was never patented, simply because they reft all the rest of Rivest, Shamir, and Adleman's work from the public — but that's neither here nor there. What CipherSaber (and hence, SAF) implements is the alleged RC4 algorithm (hence the "A" in"ARCFour"). Some years ago, an anonymous benefactor the the cryptographic community at large reverse-engineered RSA's code to find what he claimed was the RC4 algorithm, and released it to the public.

The alleged RC4 algorithm is deceptively simple, involving a pseudorandom stream which is combined with the plaintext stream, each new cyphertext character thus generated affecting the following pseudorandom byte. In fact, it's so simple that as I read the description of the algorithm I thought back to my eleven- and twelve-year-old days of pencil-and-paper ciphers, and realized that I had very nearly implemented ARCFour independently — albeit using only the letters of the alphabet, and hence adding modulo twenty-six rather than modulo two-fifty-six.

That aside, SAF is my offering to the cryptographic community. It currently implements one of the two known fixes for the Fluhrer/Mantin/Shamir attack. This attack takes advantage of the fact that the first few bytes of any given ARCFour/RC4 output stream are strongly non-random, in fact leaking information about the key. This tendency can be reduced by iterating through the key-scheduling algorithm some larger number of times (say twenty rather than one). It may also be defeated by simply dropping the first portion of the keystream.

Currently SAF will iterate through the scheduler an arbitrary number of times, continuing to mix they key into the array. However, this may (though I'm no cryptanalyst) be insecure as well. A better solution (which will soon be implemented) would be to iterate through the scheduler without utilizing the key further, very similar to the second workaround.

The second workaround, which is soon to be implemented, is the ability to discard an arbitrary portion of the keystream prior to encryption. This is computationally intensive, however, since the nature of the keystream requires the entire stream to be calculated up until the first usage point, even though it's slated for discard.

The last security feature in current development is a better key generation function. Currently, SAF simply concatenates the rawkey to the raw nonce (initialization vector), and uses that concatenate as the permutor for its key schedule. A possibly more secure key-generation method would be to use the MD5 sum of the key-nonce concatenate as the scheduling key. However, in light of the previous security enhancements, the effect of such amove may be negligible.

The interface is still clunky. It's usable, and should be obvious by looking at the first dozen lines of code, but it isn't documented at all yet.

SAF | Download Source | View Source