7

I'm building a simple web application for encrypted chat. Each message will undergo 256-bit AES encryption on the client side, using the Stanford Javascript Crypto Library. No unencrypted data or password information will ever leave the user's browser.

Is it safe to implement this scheme, using client-side encryption, even without SSL?

  • 3
    How will you relay the encryption key securely? If you haven't given thought to this, the answer is definitely a great big "NO". If you have given thought to this, the answer is probably a big "No". Just use TLS. – AviD Dec 25 '13 at 11:00
7

Javascript is sent from the server to the client; whatever cryptography you do client-side will provide security only insofar as the code which the client runs has not been altered in transit -- which means that SSL is still required, at least to make sure that what the client receives and runs really is the genuine implementation of your protocol.

This implies that if the server is hostile to the client, then the server wins and the client is doomed. Correspondingly, it is a futile endeavour to try to protect the client computations from the server. From this (somewhat simplistic) argument, we may conclude that it makes little sense to encrypt data on the client; just use SSL, send the data to server, and let the server do its job. The server is trusted, which means that if the server wants to betray you, then you are defenceless.

The Stanford Javascript Crypto Library is still good science, but it does not map well to the use of Javascript in a classic Web context. It would make a lot more sense as part of a browser extension or anything similarly scripted which benefits from a specific, independent, secure distribution mechanism for code.

(Note that all of the above applies even if your protocol is rock-solid from a cryptographic point of view -- and not many cryptographers would dare pretend that they can accomplish such a feat by themselves, without extensive peer review.)

  • Thanks for your feedback, Tom. Now I see why my planned implementation of the Stanford JS Crypto Library would be insecure: attackers have the ability to modify client-side code. I'm fairly familiar with the idea that the front-end is not be trusted. For example, I always validate form input on the backend to guard against cross-site scripting. However, I don't know how an attacker would actually intercept and modify the JavaScript sent to my users. Would you mind explaining the process? – hawkharris Dec 25 '13 at 23:37
  • If the JavaScript comes over HTTP (not HTTPS) then what the attacker does is the following: he redirects the HTTP requests from the client to his own server. This is easy enough in WiFi contexts (attacker operates his own WiFi access point) or through DNS poisoning (attacker spams the target or its main DNS server with fake answers so that the client uses the attacker's IP address instead of the genuine one). Since the attacker relays the complete traffic, he can alter parts of it at will. – Tom Leek Dec 26 '13 at 14:11
1

Not enough information but from the sound of it...NO! Don't roll out your own scheme.

The problem with here isn't the encryption..AES is very strong. The problem is the protocol, which has many nuances like the key agreement, how integrity is ensured, etc.

Here is a recent example that is Ripped from the Headlines of some developers rolling out their own protocol for secure messaging. Moxie does a good job pointing out some places where you could have made a mistake.

Encrypting with AES using sjcl one time will result in a ciphertext that an adversary probably can't figure out the result of.

Implementing an entire secure chat protocol where AES is used for confidentiality might be good...but it might have severe problems that could get someone thrown in jail.

  • 2
    How is this rolling your own crypto if he's using the Stanford crypto library? Also thrown into jail? For what? – Lucas Kauffman Dec 25 '13 at 9:21
  • @LucasKauffman "rolling your own crypto" doesn't refer just to creating new algorithms, but also using the existing algorithms to create your own protocol or cryptosystem. – AviD Dec 25 '13 at 10:58
  • @AviD and who says that key will be negociated through the server? After all the whole point of encrypted chat is that not even the server can see the shared secret between clients. I'd say that maybe for the integrity part you could still use https. – Lucas Kauffman Dec 25 '13 at 11:52
  • @LucasKauffman exactly, see my comment on the question... – AviD Dec 25 '13 at 12:23
  • Nothing says he is negotiating through the server but nothing says he isn't @Lucas Kauffman . this is why the first line says Not enough information – user11869 Dec 25 '13 at 14:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.