https://bonchat.org/cb9d007ac6e12605
pass: hacker news
Bonchat - client-side encrypted web chat for the truly paranoid
21–30 of 51 posts
Re: Bonchat - client-side encrypted web chat for the truly paranoid
#22For any HN crypto nerds: I made a little web chat that even the server can't read. Besides boring old SSL, bonchat.org uses a javascript implementation of AES to encrypt chat client-to-client. There are no cookies, no sessions, and no account registration. You never even send your password or plaintext username to the server. If you chat with someone who knows the same password, you get a simple HTML/Markdown web cha…
No system is ever 100% secure.
Re: Bonchat - client-side encrypted web chat for the truly paranoid
#23No, 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, wi…
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 prob…
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.
Re: Bonchat - client-side encrypted web chat for the truly paranoid
#24For any HN crypto nerds: I made a little web chat that even the server can't read. Besides boring old SSL, bonchat.org uses a javascript implementation of AES to encrypt chat client-to-client. There are no cookies, no sessions, and no account registration. You never even send your password or plaintext username to the server. If you chat with someone who knows the same password, you get a simple HTML/Markdown web cha…
No system is ever 100% secure.
Neither was that ever implied... ?
Re: Bonchat - client-side encrypted web chat for the truly paranoid
#25Earlier quoted context omitted.
Yes. You are right. It is the problem with pretty much everything. The issue here is that you haven't solved that problem. So your application is no more secure than anything.
No. Assuming it’s correctly implemented, it’s more secure than an identical app that sends the password over SSL to the server. This is not an innovation in cryptographic theory, but it’s something you don’t usually see in a web app.
It's something you don't see in web apps because the idea has been roundly rejected. Because in almost every setting where you could possibly implement crypto in JS, you have to run the app over HTTPS anyways, you gain only epsilon more security than if you would without added crypto --- and that's if you get everything right.
Re: Bonchat - client-side encrypted web chat for the truly paranoid
#26This is insecure. It is using Unix time as a nonce for CTR mode: https://bonchat.org/js/aes.js
Clients may send messages encrypted with the same keys and overlapping counters. This could allow the server to recover information on the message contents.
There's also no authentication on the encrypted messages. A corrupt server can alter messages sent to a valid client without detection. This is trivial to do in counter mode.
Also, as people have already mentioned, if the server is compromised, then the Javascript is compromised.
Re: Bonchat - client-side encrypted web chat for the truly paranoid
#27No, 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, wi…
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 prob…
"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.
Re: Bonchat - client-side encrypted web chat for the truly paranoid
#28Earlier quoted context omitted.
It's not by-golly secure; it's insecure in a way that drives me perpetually nuts and that pushes a grevious misconception about how crypto algorithms can secure traffic in browsers. There is perhaps no worse place in the world to do crypto than in a Javascript interpeter bound to an HTML DOM and hooked up to a network.
Got a specific problem in mind? How would you attack this?
See upthread.
Re: Bonchat - client-side encrypted web chat for the truly paranoid
#29This is insecure. It is using Unix time as a nonce for CTR mode: https://bonchat.org/js/aes.js Clients may send messages encrypted with the same keys and overlapping counters. This could allow the server to recover information on the message contents. There's also no authentication on the encrypted messages. A corrupt server can alter messages sent to a valid client without detection. This is trivial to do in counter…
NICE.
Please consider joining our team? Pretty please? We just opened up a SF office. You're only sometimes going to have to deal with my ranting!
CTR nonce collisions are one of my most favoritest attacks. Everyone misses that. It doesn't help that CTR documentation isn't clear on how you should divide the nonce space up between counters and IV-style nonce; you'll find targets where you can induce them to wrap.
Re: Bonchat - client-side encrypted web chat for the truly paranoid
#30This is insecure. It is using Unix time as a nonce for CTR mode: https://bonchat.org/js/aes.js Clients may send messages encrypted with the same keys and overlapping counters. This could allow the server to recover information on the message contents. There's also no authentication on the encrypted messages. A corrupt server can alter messages sent to a valid client without detection. This is trivial to do in counter…
It's using millisecond precision time for the nonce, yes. Nonce collisions in a normal volume chat are unlikely. If you'd like to suggest improved counter code, however, I'm all ears. :)
A corrupted server could alter messages without the key if it had both the plain and encrypted versions of a text. But to get that, the javascript would have to be compromise, and at that point the server might as well just steal the key anyway. This has already been discussed above, and if you're worried about it, the solution is actually pretty trivial. I especially like Whimsy's suggestion of a Grease Monkey script for verification.