Hacker News Reader

Comment by sweis | Hacker News Reader

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

View on HN

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.

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.

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.

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.

Reply on news.ycombinator.com