[sp332]

From that page:

Why can't I use TLS/SSL to deliver the Javascript crypto code?

You can. It's harder than it sounds, but you safely transmit Javascript crypto to a browser using SSL. The problem is, having established a secure channel with SSL, you no longer need Javascript cryptography; you have "real" cryptography.

So, you can deliver the JS to the browser securely!

[sneak]

If you have a secured channel to the server (e.g. SSL), then you can just trust the server to encrypt on that end.

It doesn't matter if you are running server-trusted JS crypto in your browser, or server-encrypted data. Either way, the server is dictating the code/algorithms in use, and could backdoor/subvert the encryption.

[jeduga]

This project addresses a different problem. One where you want to have multiple people reading a message at anytime in the future without the need for end to end communication in real time.

[sp332]

Right. Matasano is pointing out that securing communications with JS is basically doomed. But they admit that if you can secure the transmission of the entire contents of the page (HTML, JS, everything), then your JS crypto should be OK. They just can't think of a reason to do that, which obviously you have. :)

edit: sneak points out that you have Google Analytics loading on that page, so your data could be compromised that way - theoretically :)

[sneak]

> But they admit that if you can secure the transmission of the entire contents of the page (HTML, JS, everything), then your JS crypto should be OK

Nope. The server operator can still serve you (perfectly secured over an SSL channel) backdoored javascript crypto code.

[jeduga]

Which can be clearly viewed by the community.

[sneak]

Only for that point-in-time. Nothing stopping it from serving backdoored JS _just to your IP_, or _just for five minutes that one time_. Dynamic web app, remember? :)