How secure are self decrypting HTML files for data storage?

Question

I recently came across a JavaScript self decrypting archive. Is it secure enough to be used as a portable password storage tool? The author has even challenged it to be cracked.

Answer 1

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 2ⁿ 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.

---

Another point is that the password is derived into a key with only a pair of invocations of MD5. MD5 is very fast; a good, but off-the-shelf and not utterly expensive GPU can evaluate MD5 at a rate of roughly one billions per second. If the first bytes of the encrypted data are guessed by the attacker (since cleartext is supposed to be Javascript, the first bytes are probably "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.

---

The use case is also dubious. Since this is Javascript code in which the user enters his password, this is vulnerable to active attacks: an active attacker could simply alter the Javascript code, so that when the user enters his password, a copy of the password is also recorded somewhere (e.g. the decrypted data -- which is supposed to be Javascript itself -- gets an additional code snippet which prints out a hidden <img> tag with a URL pointing to an attacker-controlled server and encoding the password).

To defeat active attacks of that kind, the solution is known, and that's SSL. The "self-decrypting archive" should be served only over HTTPS. But if HTTPS is used, why would self-decryption be needed ? Instead, have the server give the sensitive piece of Javascript only after having duly authenticated the user, with the password. This is a very common model, existing Web servers implement it out of the box, and it is stronger since it thwarts offline dictionary attacks (from the outside, the attacker cannot "try passwords" at the maximum speed of his GPU; he has to ask to the server for each guess, and the server can answer as slowly as it wishes).

---

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.

Answer 2

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...)

Answer 3

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.