At least the author wrote a rather clear page on how his encryption works. Notwithstanding, this looks like a rather old-style homemade stream cipher, which is not good news, since most of such systems have been thoroughly broken. It appears to consist of a basic LFSR subsystem (two LFSR with key-dependent polynomials; the bit about the polynomials operating in "reverse direction" is a red herring, because this subsystem is still wholly linear) and another LFSR which acts as a non-linear selection engine. There are a few select designs which roughly look like that and appear to offer a non-negligible cryptanalytic resistance (e.g. the Alternate Step Generator), but this comes at a price, namely that you need quite much more than n internal bits of state if you want to achieve a 2n security level. Also, many such designs turned out to be weak.
We can trust in the resistance of a cryptographic algorithm based on the combination of the following properties:
- The designer is known to be very good at designing algorithms (e.g. his name is Rivest).
- The design got wide exposure, such as being published in some high-profile conference and/or being deployed at a large scale.
- Several years have elapsed, and nobody found any issue.
This design is a bit lacking on the three points.
Edit: I had not noticed it (I need more coffee in the morning) but the generated stream is deterministic for a given password. This means that if you encrypt two archives with the same password, you are in the infamous "two times pad" situation, and you have basically lost.
var" or "
function"), then the whole thing is vulnerable to dictionary attacks, aka "exhaustive search on password" (trying out potential passwords until a match is found). It is possible to have a big fat random password which defeats dictionary attacks, and a human brain could still remember it with some effort. But most passwords are weak in that respect. Also, no salt: for a given password, you always get the same stream. Therefore, one could precompute the first bytes of the stream for each potential password, and afterward cracking any instance would be a matter of a few lookups in the table (the table could take the form of a rainbow table for more compact storage).
For the password-handling part, this scheme is definitely weak.
<img> tag with a URL pointing to an attacker-controlled server and encoding the password).
Summary: I recommend against using this piece of code. I still note that, at least, the designer of SDA appears to have made commendable efforts at documentation, and to be sane -- sanity alone puts him in a minority, among the crowd of cipher designers on the Internet.
The problem with all of these types of things is that you can't really determine how secure they are. What we do instead is place some trust in ones that have been tested over time by a large number of experience people (@ThomasPornin has an excellent answer on this, which I will try and find a link to) - this is probably why the author has placed the challenge: He wants it tested.
This one may use a secure algorithm, but if the implementation has weaknesses then it may be insecure.
In summary - if you have a real need for a secure SDA, I would advise going with a tried and tested one, as your risk is likely to be lower. If however you can review the code behind this one and assess the risk to you for your uses to be sufficiently low, then this may be fine for your purposes.
(Sorry that's a bit uncertain, but a lot of this is...)
I general would stay away from anything where you can't review the code and you have to do encryption online. Maybe it's not the case here, but every time in the past I've seen new encryption or steganography algorithms which were available only online, it was a honeypot collecting data on what people out there might want to encrypt/hide.