[tptacek]

No, it's not as secure as your browser and AES. It's exactly as secure as Bonchat's servers and application code, because your browser is going to trust any Javascript fed to it from Bonchat.org, whether or not that code subtly destroys the security of the AES encryptor.

Why even bother with JS AES? If you're served a court order, you can be forced to transparently record everything being said on the site anyways, without anyone being the wiser.

[nickbw]

Transparently? Without anyone being the wiser?

The javascript is there for the auditing. The server-side code is not, but you're completely free to analyze the client-side code to verify that it never sends your password to the server. I've avoided minifying any of it (save jquery.js, which you can diff against the official release to make sure I haven't modified it) to make it more auditable.

It's true that you probably won't check the javascript every time to make sure bonchat.org hasn't started serving up a compromised version. Just like I don't tcpdump my network traffic every time I boot up my OS X machine to make sure FileVault isn't secretly beaming my password home to Apple. The point is that I could. More practically (hah), I can randomly sample.

Actually, it would be pretty easy to verify the javascript each time. As long as you're satisfied that any version of the js is secure, you can save a copy to your hard drive and write a script (curl | diff?) to verify the server's copy every time you load up a bonchat.

No, it can't guarantee that the server is free from tampering. Nothing can. But I believe it's the first web chat secure/transparent enough that you can protect your data even if the server is compromised.

[tptacek]

"The javascript is there for the auditing" doesn't mean anything. Javascript is the worst possible environment for running crypto code: it's accepting and running code delivered over a network from untrusted hosts bound in all sorts of unpredictable ways to an extremely complicated markup format optimized for display, and, on top of that, almost every single feature in the language can be overridden from the code.

Even if you were among the 0.00000001% of potential users who could possibly look at a block cipher implemented in Javascript and judge whether it was intact (and among the 0% of people who would actually do this), you can't just look at one piece of code in JS and know what it's actually going to do. You have to have a way of assuring every single bound function in the entire Javascript runtime.

That mechanism of ensuring the entire state of a Javascript context in a browser? It doesn't exist yet in any modern browser.

Your last sentence? What a huge dodge. If your server is compromised, your users lose. My browser trusts your server absolutely. If you'd like me to demonstrate this to you vividly, you can catch me offline and we can arrange terms.

[nickbw]

Your objections seem to boil down to a superstitious distrust of javascript. The web may be a messy platform, but javascript is not a particularly difficult language to read, and (if I may say so) the relevant chunks of bonchat are written in a pretty plain style.

I'm not making any promises of 100% perfect security with no effort and no room for attacks. Bonchat is merely an experiment in securing content against servers as well as network snoops.

I trust Linux more than Windows. I haven't personally audited all the code on my Linux box, and I don't know any one person who even has the skill to do so. But the code is there to be audited, which gives me more confidence than when I use a opaque operating system. The same applies here. Bonchat isn't perfect, it's just trying to be easier to keep honest than a normal web app.

[tptacek]

You say "po-TAY-to", I say "po-TAH-to".

You say "to-MAY-to", I say "no thank you".

You say "supersititious distrust of Javascript", I say "a day job finding, breaking, and fixing the horrible things people try to get away with doing in Javascript". (Or, less charitably: "knowing how Javascript works in browsers.")

Trust me on this one. It's a cool little hack. It's even useful if you get rid of the vanity crypto. But you are asking for someone to write a really mean blog post about you and your actual understanding of how crypto works. That's drama you don't need. Don't bother with the AES stuff.

[nickbw]

If you would like to propose improved crypto code, I would love it. Honestly.

But "javascript is a messy language" is not inherently an attack. You can obfuscate just about any language. Do you actually have an attack in mind based on the fact that it's implemented in the browser?

It's true I don't have a deep understanding of the AES algorithms, and the AES code, as stated in the attribution, isn't even mine. Again, I'd love improved code. But you have yet to make any rational argument that javascript in the browser is inherently unsuited to encryption.

I completely agree that the many attempts to make SSL irrelevant by doing all the encryption in JS (and usually horribly naive JS) are foolish. That's not the point. Bonchat isn't a shopping cart or a mail reader. SSL is for securing communication to the server. Bonchat is an experiment in securing communication against the server. Do you have a better way than client-side encryption?

[SamReidHughes]

Do you actually have an attack in mind based on the fact that it's implemented in the browser?

You, the owner of the server, change the code. That's the attack. There's no way for me to tell my friend Charlie that he can use the service and get secure communication, unless he installs a plugin for his browser to verify that the server has not changed the data it sends the user from the time when I verified the correctness of the code. And if he has to install a plugin to safely use this service, which is now never permitted to change its code, he might as well just install a plugin that has the code, or install a separate application for this purpose.

[tptacek]

You seem intent on evading the point. Most security systems don't depend on me being able to read the code every time I use it.

[whimsy]

There are some solutions to this, right? For example, you could solve the problem for FireFox by writing a GreaseMonkey script to verify the JS is the same as last time, or just has the right hash.

Another way would be to make it an option to only use the GreaseMonkey encryption - trust it to rewrite the JS on the page, so the user can control updates to the JS.

[alecco]

  > Why even bother with JS AES? If you're served a court order,
  >  you can be forced to transparently record everything

They can try the "Warrant canary" approach. Nothing to lose (but I'm foreign and not a lawyer.)

http://en.wikipedia.org/wiki/Warrant_canary

Still it would be vulnerable to ISP-level MitM with SSL CERT hijacking. Aren't major government agencies (at least technically) able to control root CAs?

EDIT: (relevant discussion on the Clipperz forum) http://groups.google.com/group/clipperz/msg/c4e5f76af2e77bf6