Hacker News new | ask | show | jobs
by nickbw 5860 days ago
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.
1 comments
sweis 5860 days ago
It's not just two messages colliding on the exact millisecond. They can collide on subsequent blocks. So if Alice sends a 10 block message that starts at T_0 and Bob sends a 5 block message that starts at T_5, then the server learns information about half of Alice's plaintext and all of Bob's. Each client should use an independently-chosen and unpredictable IV.

You are incorrect on your statement that the corrupted server needs both the plain and encrypted versions of a message to send bogus messages. Without authentication, the server can flip arbitrary bits of a CTR message. This opens up several types of attacks. You should apply a MAC to the ciphertext.

I think that the encryption needs to happen entirely in the client and you can't rely on code downloaded from an untrusted server.

link
nickbw 5859 days ago
Thank you for the insightful comments, and for taking the time to read the code! I really appreciate it.

I've added a pseudo-random component to the nonce, and a MAC to the messages.

I certainly agree that you can't rely on code from untrusted servers, but I think doing the encryption in the client with code that is publicly viewable, even if it can be compromised at any time by a malicious server, is the best we can do for web apps unless/until major browser vendors incorporate client-to-client encryption. Right now there is no reliable protection against a compromised server, but I would like to at least see web apps strive to be more accountable.

link