I'm currently researching the possibilities for creating a (peer2peer) messaging client in terms of encryption thus security. This application will be based on web technologies (if possible).
My questions are: is end-to-end encryption possible with only javascript (client & node.js/peer.js)? If yes: is it correct to look into the HMAC (RSA) kind of encryption techniques? I already tried to understand a bit how these libraries work but I have no luck so far :)
lib's I find interesting but i don't (completely) understand and know how to implement (in this use-case):
I can try to elaborate more if needed.
UPDATE: The application is going to be a mobile application. The use of web technologies is a bit proof-of-concept.
End-to-end encryption (E2EE) is a method of secure communication that prevents third parties from accessing data while it's transferred from one end system or device to another. In E2EE, the data is encrypted on the sender's system or device, and only the intended recipient can decrypt it.
With JavaScript's web cryptography API in place, the server can't see data since it's cryptographically secure. Only the sender and receiver have access to communication data. From the diagram above, you can see that data from the sender is encrypted with the API.
While E2E encryption in the native stack is well developed and has been possible for years, E2E encryption in the browser is brand new and at the early stages of experimentation.
End-to-end encryption secures data on the user's device and only ever decrypts it on the recipient's device. This means, the data can never be decrypted on the server nor in transit nor on the user's device.
The goal of end-to-end encryption is that users can be certain of the security of the communication even if the central server is cheating. There are two main challenges that need to be solved:
(1) Users need to be 100% certain that they are communicating with whom they think they are communicating. This is to prevent man-in-the-middle (MITM) attacks, where the man-in-the-middle could be anybody including the server itself (example: Apple iMessage has this weakness).
(2) You need to be 100% sure the client-side code is not cheating. For example, is it really encrypting the data using the other person's public key, or is it just sending it in the plaintext somewhere else, and then encrypting from there. Given that whoever has access to the server can swap the JavaScript any time, this is a huge challenge.
Both problems seem solvable.
For (1), users can verify public keys out-of-band, as is done in PGP/GPG (unfortunately many people skip this step, but for true end-to-end security, you need it) or keybase.io.
For (2), a group from MIT claims to have solved this in their Mylar design. See section 6. It should be stated that researchers have found security issues with Mylar, but to my knowledge, their solution to client-side code integrity has not been compromised.
So in theory, end-to-end encryption can be done entirely in JavaScript (what server language is used is not so relevant). In practice ... it will not be easy.
You are currently looking at security implementations. If you don't understand the security model & cryptography behind these libraries, your solution will - to a high certainty - not be secure.
Artjom is correct in indicating that for peer to peer encryption you most likely need authentication of both parties. That is not provided by normal SSL/TLS, you'll need client authentication. But for client and server authentication you need to have established trust. On normal browsers this is provided by the internal certificate store. It is however much trickier to trust the clients.
All the other stuff (like how RSA is not a HMAC) are implementation details. You should however not be implementing anything related to security right now. First focus on your use case, threat scenario and protocol design.
At most, you can have "novelty" end-to-end encryption using Javascript in a web browser. That is, it'll look and feel like end-to-end encryption, but the implementation will most likely be scoffed at by cryptographers.
The main reason is that no matter what piece of puzzle you put in to encrypt data on the frontend, your client ultimately depends on what the server sends it.
Required reading:
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With