When messaging/journaling/etc apps say this, what does it actually mean, and why does it give people reassurance that their private info is safe?
In: 111
Any even remotely competently written software will encrypt data when it’s sent over the Internet.
A chat app that is not end to end encrypted (E2EE) will encrypt the connection between the app and the server. The server will decrypt the message, then encrypt it again for the recipient, and as a result, it will be able to read it.
If the chat app is end to end encrypted, your phone will first encrypt the message so that only the recipient’s phone can read it. Then it will send it to the server (the connection to the server will typically still be encrypted one more time). Now the server can see that you’re sending a message and to whom, but it can’t see the content.
The hard part is doing it right and making sure you’re actually encrypting it to the right recipient. Encryption is usually done with public key encryption systems. A recipient generates two keys, public and private, and gives the public key to everyone. You can use the public key to encrypt a message so it can only be read using the corresponding private key.
But how do you know which public key belongs to the recipient? Usually, you ask the server. The server could instead send you its own public key (pretending that it’s the public key of the recipient). Your phone would now encrypt the message using that key. The server could decrypt it, read it, then encrypt it with the recipient’s key.
For this reason, apps like Signal let you verify your contact’s “safety number” which is the fingerprint of both your and their public keys (if you look closely, one half of your safety number is the same for all your contacts – that’s your public key fingerprint!)
By checking this, e.g. if you meet in person, you can be sure that the attack I described above (“man-in-the-middle”) is not happening. Some e2ee apps don’t do this. This still means the server has to actively mess with the data rather than just reading it, but it’s far from perfect.
Even e2ee is no guarantee: for example, a malicious server could send you a software update that just uploads your message history.
WhatsApp and signal use the same encryption, but a) WhatsApp doesn’t warn you by default when your contact’s key changes (because people lose their phones/reinstall all the time and it confuses people), b) WhatApp pushes really aggressively to back up your chats to the cloud, and once either you **or your contact** do that, the (already decrypted) messages are backed up to apple/google… (there is some other encryption involved but if someone gets the data from Apple/Google, and a key from Facebook, they can read those backups).
They mean that encryption/decryption takes place on the source and destination devices, so in **theory** the servers and attackers in the middle can’t read the traffic.
In **practice**, whoever holds and applies the keys can read the traffic. So if your end device is using code from the server to do this, potentially the server could give you malicious code and read your traffic. The solution is to have the encryption and the storage/transport done by different companies or projects. Use an encryption package such as PGP or Mailvelope, and then a service such as normal email.
They mean that encryption/decryption takes place on the source and destination devices, so in **theory** the servers and attackers in the middle can’t read the traffic.
In **practice**, whoever holds and applies the keys can read the traffic. So if your end device is using code from the server to do this, potentially the server could give you malicious code and read your traffic. The solution is to have the encryption and the storage/transport done by different companies or projects. Use an encryption package such as PGP or Mailvelope, and then a service such as normal email.
They mean that encryption/decryption takes place on the source and destination devices, so in **theory** the servers and attackers in the middle can’t read the traffic.
In **practice**, whoever holds and applies the keys can read the traffic. So if your end device is using code from the server to do this, potentially the server could give you malicious code and read your traffic. The solution is to have the encryption and the storage/transport done by different companies or projects. Use an encryption package such as PGP or Mailvelope, and then a service such as normal email.
Latest Answers