42

I've been told that WhatsApp implemented "end-to-end" encryption. In the grand scheme of things, what does this actually mean versus, say, another service which does use HTTPS, such as this website (StackExchange) or some other non-end-to-end encrypted site? Is there some point where even HTTPS/TLS will expose data that doesn't occur in an end-to-end encrypted app like WhatsApp?

the_endian
  • 1,169
  • 1
  • 8
  • 21

2 Answers2

55

End-to-end is where the message is encrypted by the sender and decrypted by the receiver. Nobody in the middle, not the chat provider nor other entities have the ability to decrypt it.

Compare this to a simple chat over HTTPS. Each message is encrypted in transit, just based on the fact that TLS is used. Now, while the intended recipient is another user, the TLS connection is initiated with a server (think Facebook). TLS terminates at the server, and whoever controls the server has the ability to view the messages since they are not encrypted end-to-end. Then, the message may be passed on encrypted over TLS again to the recipient.

The key difference is that the provider is able to view the messages in this case.

Below is a simple illustration of End-to-End encryption using ECDH asymmetric algorithm on the P-256 curve to Generate a CryptoKeyPair for Alice & Bob.

They proceed to derive an asymmetric shared secret using AES-GCM-256 algorithm from their own private keys & each others public keys.

Finally they use the AES-GCM-256 symmetric shared secret for all subsequent encryption. Symmetric encryption is much faster.

This can be achieved using the Javascript WebCrypto API.

ECDH P256 Chart

suchislife
  • 130
  • 4
multithr3at3d
  • 12,842
  • 3
  • 32
  • 43
  • 4
    And what if in some theoretical situation, the receiver is just the server and no further point? Then would it be end-to-end? Because the client is one end and the server the other one. – O'Niel Apr 12 '17 at 23:48
  • 13
    Yes, by definition that would be end to end, since the encryption is terminating... at the end. – multithr3at3d Apr 12 '17 at 23:55
  • 1
    Wow. Is there any trick to determining which services offer end-to-end versus what you just said where it's just HTTPS to them and then HTTPS out to the other person?

    I know with email, some services offer encryption of the email message itself and a key which is given to the recipient, so that would be end-to-end over HTTPS as well, right?

     – the_endian Apr 13 '17 at 00:00
  • 9
    There's not really a trick, unless the provider tells you so. Even then, you just have to trust them, unless the service is completely open source or if you are using your own keys. I'd say the only verifiable end-to-end email encryption would be S/MIME. – multithr3at3d Apr 13 '17 at 00:02
  • 1
    @korockinout13 Gotcha. The other option would be a manual encryption (using a proper algorithm ofc) where you literally message the encrypted message in the text, so that even if the organization didn't wrap it at their place, they would only see encrypted message... If I'm not mistaken! – the_endian Apr 13 '17 at 00:12
  • @TeeSee Well, you could verify that the clients actually encrypt the information before delivering it. E.g.: Although WhatsApp is closed-source you can observe the traffic to check that messages are properly encrypted before being sent from your phone to the WhatsApp servers. It's more than just "blind trust". – Arminius Apr 13 '17 at 00:23
  • On the TLS-to-a-server scenario, it could be labeled end-to-end or not depending on how we draw trust boundaries. Consider a TLS connection from a web browser to a load-balancing proxy in front of a set of app servers, which in turn channel user-supplied data to a database. If you look at the whole deployment as falling inside one trust boundary, this is end-to-end; if you look at the load balancer and app servers as untrusted intermediaries between the user and the database, it's not. – Luis Casillas Apr 13 '17 at 00:55
  • @TeeSee if you can see the raw binary you can understand if it was unencrypted and re-encrypted (if they use different keys the payload will be different). Or you can start planning a (fake - just to be sure that nobody takes this seriously) terroristic attack; if the authorities come knocking at your door, then probably someone was able to read your messages... – frarugi87 Apr 13 '17 at 10:07
17

End-to-end encryption (think: enduser-to-enduser encryption) is a concept where communication is encrypted directly between the users of a system, whereas many systems just provide encryption between each individual user and the service provider. That is, with E2EE only the sender and receiver of a message can access the message content. Neither the service provider nor any party involved in delivering the message would see it in clear text at any time.

What's the difference between end-to-end and regular TLS encryption?

E2EE does not describe a particular technology or dictate certain protocols, it only describes the way a system is designed. TLS on the other hand is a specific cryptographic protocol that could be used for an E2EE implementation (although many E2EE chat programs use advanced algorithms that are better suited for instant messaging than TLS, such as the Signal protocol). Note that technically speaking, any secure communication tunnel provides encryption between two ends, but the term end-to-end encryption is usually applied to messaging services or, more generally, the secure communication between users of a service but not between a user and the service provider itself.

So, if you send a regular Facebook message, it's not end-to-end encrypted between you and your conversation partner because Facebook's servers store your messages in plain text. Therefore, the message content would be accessible to Facebook administrators or law enforcement upon request. However, your connection to Facebook is technically an end-to-end encrypted connection between you and Facebook because you're using HTTPS.

Arminius
  • 44,770
  • 14
  • 145
  • 139