You must log in or register to comment.

throwaway_lmkg t1_je69nv0 wrote

Standard messaging platforms resemble an old-school telegraph. End-to-end encryption more closely resembles physical mail.

To send a telegraph, you beep out your message. This gets sent to a telegraph station, where a person listening writes down your message, and then beeps it on to the next station down the line, where there's another person waiting. Eventually, someone writes down the message and hands it over to the recipient.

The important thing to note is that the telegraph operator reads the message at every hop. So if your telegraph operator knows your cousin, they'll gossip. And if the Government thinks you're up to Crimes, they'll watch over the shoulder of the telegraph operator to see if anything Looks Like Evidence.

Mail, on the other hand, is sealed in an envelope. And that envelope gets handed to a postman, tossed around by baggage handlers when it's put on a plane, carried around by another postman, and then delivered unopened to the recipient. No one else has seen the content of the envelope until the recipient opens it. It is a crime for anyone else to open this mail, even the Government if they're not going through proper channels (warrantee void where it's voided).

The encryption is, more-or-less, the envelope that stops non-recipients from reading. The "end-to-end" part is the fact that it stays unopened from the beginning of the journey to the conclusion.

This, of course, relies on trusting the postal system actually does what they say they do. The post office has actual laws that guarantee it works this way, whereas some service that claims end-to-end encryption does not.


sethguy12 t1_je6fkoa wrote

Any idea how the Patriot Act plays into that in the US? Does the NSA have some sort of backdoor into the encryption?


Pokinator t1_je6qy6l wrote

The answer is extremely dependent on the platform.

Generally, once a message has been encrypted with a doesn't-suck-ass encryption algorithm, the only way to read the message is by having the key or breaking the encryption algorithm to get the key. (most in-use algorithms are pretty break-proof at the moment). Without the key, the message in transit is just gibberish.

When it comes to back doors, it's pretty hard to implement them without severely weakening security. Any point where you say "okay but at this part you can use our magical master key to read it" becomes a gaping hole in the integrity of your encryption.

More commonly, if the platform wants a back-door they'll do it on the client ends instead of in the middle. Create a way to hack into a user account and get their keys. Even that is a major security hole though.

If you want reliable security, there can't be a back door at all.


Blueroflmao t1_je8u99j wrote

For what its worth, AES (Advanced Encryption Standard) which is currently applied by default for nearly everything on the internet is the standard for a reason. A brute force attack (trying all combinations to find the right one) is... Impossible, with todays technology. The selection for AES was started in 2001 by the NSA, and in 2003, the Rjindael cipher was selected and it still remains the AES to this day.

As far as I know, several different attacks and methods have been found through cryptanalysis, the best of which was found in 2011. Named the "Biclique"-attack, it was further optimized in 2013.

Now heres the real kicker: there are generally three kinds of AES in use, all with slightly different designs depending on the size of the key used to encrypt (secret key/initial state, the key an attack is trying to find) These are AES-128, 192 and 256.

So using the most efficient attack that is publicly known, how long would it theoretically take to break one single instance of 128 (the simplest one)? Optimally, about 9007 Terabytes of storage is needed (down from the original version of the attack needing 38 TRILLION Terabytes) The time complexity remains the same, despite this improvement, at 2^126. (Simplified, theres some technicality involved here)

What this all means, TL; DR: The simplest form of AES in use (AES-128) would take billions of years to crack, taking ~ 2^126 operations to do so, requiring OVER 9000 terabytes of storage while executing.

As far as we can tell, AES is set to remain the standard until quantum computing comes far enough to actually be useful in Cryptanalysis (meaning we can actually extract the result of our computations, something we are unable to do today)


famous_cat_slicer t1_je94s49 wrote

> (most in-use algorithms are pretty break-proof at the moment).

Your use of "most" in this context is slightly worrying. What are the exceptions?


frzx1 t1_je99odh wrote

The exceptions fall in the experimental area of encryption. What I mean by that is that the most applications you use today, WhatsApp, Signal, Banking apps, are all encrypted with a military grade encryption, but if you go try out experimental encrypting algorithms then you are at risk. Note that the latter does not happen in your regular day to day life, encryption standards are extremely uniform.

Edit: also, be aware that the applications that have implemented an unbreakable encryption algorithm can still decrypt your files as they have the keys to decrypt them. They're bound to not do it going by the privacy agreement but they potentially can. There are exceptions to it, like Apple's advanced E2E standard where not even Apple has your keys.


Dovaldo83 t1_jea3yqt wrote

Quantum computers are capable of taking encryptions that would normally take super computers 500 years to crack and crack them in minutes.

That said quantum computers are still so expensive and rare that you and I shouldn't be concerned about someone using them against us. They've already started development on encryption methods that use quantum phenomena to encrypt messages that even quantum computers have a hard time cracking.


Pokinator t1_jea9qwz wrote

I used "Most" instead of "All" mainly for technicality.

TL;DR Rock-Solid encryptions exist, but that doesn't guarantee everyone is using them or using them correctly.

Firstly, just because there's options for solid encryption algorithms doesn't mean they're universally used. For example, the chat app that Bob down the street wrote could be using a very weak Caesar Shift encryption rather than something strong like AES or RSA.

Secondly, some encryptions are only as strong as their choice of key. For example, RSA uses prime numbers to generate keys in a way that's very not ELI5. Basically, 3 primes get used to generate an "encrypt" number, and a "decrypt" number.

If you follow guidelines, the secret "Decrypt" number is practically impossible to guess or calculate. However, if you choose irresponsibly bad starting numbers then a hacker can look at your public Encrypt number and go "hey, that looks like they might have..." and workshop the secret from there.


nighthawk_something t1_jea15a5 wrote

Yup that's why there's no "make a back door just this one time so we can stop the terrorist".

It's all or nothing. The backdoor is wide open for everyone, or for no one.


throwaway_lmkg t1_je6hszf wrote

I'm only aware of this in generalities. My understanding is that platform providers can be lawfully compelled to read telegraphs or open envelopes, if it is technically possible for them to do so.

A "true" end-to-end encryption scheme would mean that the post office physically cannot open the envelope. In practice, most of the time they could but choose not to, and this is the type of system which can be overcome by a warrant. This happens because a) e2e encryption is bolted on-top of a non-e2e system b) a "true" e2e system like that requires the sender and recipient to manage keys, which is a hassle so usually the platform does it for you c) platforms get political brownie points for being friendly with law enforcement.


pseudopad t1_je72wwo wrote

If you want a free and true e2e messaging app, Signal is pretty alright. It's also open source, so it can be audited by anyone with the time and skill to do so.


E_Snap t1_je7k3de wrote

You’d have to audit whatever specific instance of compiler or interpreter they use to run it, too. Remember, Ken Thompson was able to hide an undetectable back door in UNIX by modifying a compiler to add the back door to the kernel whenever it was compiling it, and then modifying the compiler to add the back-door-adding code to the compiler code whenever it found it was compiling itself. Bam, no trace of malware in the source, all the checksums work out, and the only way you’d ever find out is by compiling a clean version of the compiler source with a clean version of the compiler and then starting your audit.


pk10534 t1_je6qbwu wrote

You’re thinking more of the Foreign Intelligence Surveillance Act (FISA); Patriot Act applies more to domestic agencies such as the FBI. But yes, Title 1 FISA gives the government authority to intercept US-based intelligence from foreign agents/powers operating in the US and the FISA amendments act section 702 gives the government authority to issue warrants to US companies to intercept foreign intelligence. It doesn’t require a back door so to speak, but google can’t just say “no, we’re not giving our records over” if they have them. But if the NSA wants a way in for whatever reason, it probably won’t matter if the company has implemented end-to-end encryption or not.


Nickjet45 t1_je6peze wrote

Presumably no,

A back door for one person, is a back door for everyone. Companies who are serious about security, understand this and don’t have back doors.

NSA does have tools to brute force encryptions, but they take time and can be patched out (assuming it’s a software, not hardware, solution.)


pseudopad t1_je73a1k wrote

They may also have been hoarding exploits to circumvent encryption, using "side channel" attacks.

You don't need to brute force an encrypted message if you can install an exploit on the user's phone that makes a copy of the message after the user has voluntarily decrypted the message to view it.

Such attacks may also be able to extract the encryption key from the phone (or pc), which may allow them to monitor the messages to and from that particular user while they are in transit.


vettrock t1_je6tu9z wrote

If it is true end to end encryption, NSA or anyone listening on the wire cannot read it unless they resort to brute force or some sort of vulnerability in the system. If they can get access to either endpoint they can read it there, or harvest the keys from there.

There were some recent congressional hearings where the FBI, etc wanted to make companies provide a back door into the system. Law enforcement may like it, but anyone who works in security will tell you it is a bad idea. In theory the backdoor key would be provided with a warrant, but there is not a good way of preventing bad guys from exploiting it. Additionally these companies operate globally. Do we want Facebook to provide a backdoor on the legally binding order of a Chinese or Russian court?


JohnnyWadd23 t1_je7aodu wrote

The NSA can crack almost anything, especially with help from the Mosad Pegasus technology. The US govt has weaseled it's way into these companies producing the end to end encrypted apps.

For example, we recently discovered FBI agents working at Facebook and Twitter. Facebook bought WhatsApp so the FBI working there got its hands on the decryption keys for WhatsApp messages. So they started reading everyone's messages. For example, Chase employees were using it to coordinate efforts to get around regulations. Once the messages were read the SEC stepped in and fined Chase. The SEC had no case without facebooks help decrypting the supposed private messages.


geh4cktes t1_je81s3t wrote

None that we know of. However there are some standardised cryptographic algorithms that have weird, unclear design aspects and we are wondering if these could be back doors we just don't understand yet. In same cases these aspects have also been shown to be insecure but we have no proof that this was intentional.


sephirothFFVII t1_je8cvu6 wrote

It is speculated the US govt has the ability to break eliptic curve based cryptography algos by knowing the "magic number"

Additionally, many sessions are logged and stored in a data center in Utah. No one really knows the extent of the logging but it's reasonable to assume noteworthy traffic is stored and if an insecure protocol is used it is decrypted and read.

Then there's always the equation group, those guys are scary good and who knows what sorts of ins they have to systems bypassing the need to sniff sessions to begin with!


ChaoticAaronStout- t1_je83ptt wrote

Be sure to read the fine print. For a while, Zoom offered end to end Encryption for their meetings with dial in numbers. There are many old school analog phone systems that don't support encrypted.


clocks212 t1_je77yr5 wrote

Keep in mind all major governments are sucking up that encrypted communication with the knowledge that one day the encryption keys will leak or the encryption can be broken or brute forced. If you’re a political dissident in China for example I wouldn’t count on that encrypted data to be encrypted forever.


Kodekima t1_je8k6vo wrote

Quantum computing can break current encryption standards, but that isn't feasible for anyone except the most technologically superior APT. Also, quantum encryption methods exist specifically to mitigate the effects of encryption cracking.


frzx1 t1_je99soi wrote

They're pretty cool, if you read about them. Most of them are lattice based and working in thousands of dimensions.


Arunia t1_je68c89 wrote

The encryption is from your end to the other and only both devices know the code to decrypt the messages. Which means it should be safe.


istoOi t1_je6bjwa wrote

There are some who offer "end to end" encryption, but the app provider actually knows the encryption keys.

So while it is technically true that they have e2e encryption, they can read it anytime they want/need to.


No_Tamanegi t1_je6kmwp wrote

Should mean its safe, but doesn't necessarily guarantee. The software can only guarantee the encryption between the sender and the recipient. But if something on either the sender or recipients device has the ability to intercept the message, it can still be compromised.


Zharken t1_je6kuzl wrote

How does the recipient device know the encryption key?

I'd assume a new key has to be generated everytime and if the sender generates one, to encrypt the message, then it can't send the key to the recipient because if it does so, any man in the middle would also know the key and thus, making the entire encryption thing useless.


BiomeWalker t1_je6yucj wrote

At the start of the conversation each device sends the other a "public key" which can be used to encrypt the data while keeping a matching "privet key" which is the only way to decrypt data that has been encrypted with the "public key"


Zharken t1_je7705e wrote

oh so I give you a key that everyone can see, but can only be used to encrypt, and I have a different key that no one knows that I can use to decrypt what you return to me and vice versa


flux124 t1_je6mt6t wrote

The trick is that there exist encryption schemes such as RSA which allow a private and public key. The way it works it that you generate both, keep the private key a secret and share the public key with the world. The private key only decrypts messages signed with the public one and the public one only decrypts messages encrypted with the public key. This means the public can send you messages only you can read and you can send messages that are verifiable to have come from you because they can be decrypted by the public key. From here you can use AES, which is symmetric, same key for encryption and decryption, to share the same key between both people. This is actually how https Internet security works. Your OS /browser keeps track of certain public keys that can be used to verify domains as being legit.


Devil_May_Kare t1_je6asp4 wrote

What they're claiming is that your data gets encrypted on your phone and doesn't get decrypted until the intended recipient gets it. Encrypted data can't be read without decrypting it first, so in principle end-to-end encryption ought to keep the app developer from sitting in the middle of your conversation reading your messages.

In reality, though, it's important to remember that anyone can claim their app uses end-to-end encryption, whether or not it actually does. So you shouldn't rely on an app to do the right thing.


berael t1_je68ecv wrote

Content is encrypted before it leaves your device, and is only decrypted when it reaches the other person's device. It has been encrypted from one end to the other.


Most_Engineering_992 t1_je6akbl wrote

What is not "end-to-end" encryption is when the email is encrypted during transmission between servers, but is transferred from your email server to you in a form that the server (and its operators) can read.

And that's actually the usual case, as email headers must be readable by the servers because they have routing information, and some email servers will also scan your emails for spam, attacks, and viruses.


PckMan t1_je6fve5 wrote

Typical communication is unencrypted. This means that the data, the contents of the message, could be read by anyone who has access to them at any point in their journey to the recipient. Maybe your internet connection is compromised and someone can see all the data that comes and goes from your connection. Maybe it's the servers of the service that are compromised or maybe your Internet Service Provider is compromised. Your data passes through all those different networks and servers so it is theoretically possible that someone with access to them could read your messages.

End to end encryption is what it says on the label, it's encrypted. When two users have a chat with each other, an encryption key is generated that only their devices have. This encryption key is used to encrypt and then decrypt the data on either end. Without it the encrypted data makes no sense to anyone who may have access to them and is next to impossible to decrypt without the encryption key. This means that even if for example someone has access to my messenger account, and he has it open on a computer, he still won't be able to see my end to end encrypted chat that I have with someone through my phone, since only my phone and their phone have the encryption keys. That's why it's called end to end. A channel of communication may still be encrypted but not necessarily end to end.

End to end encryption offers significant security and privacy benefits but it's not unbeatable. If someone up to no good wants access to your data there's always ways they can get it. The weakest points are obviously the devices themselves. If malicious software that gathers your data is installed without your knowledge on your device it can simply read the decrypted messages and bypass the need to decrypt entirely. If someone has access to the encrypted data they may still be able to decrypt it if the method of encryption is weak or if they have the ability to brute force it with a suitable system. Lastly there's the question of whether the providers of those services themselves are honest about their encryption. What's App or Messenger may say their messages are end to end encrypted but that doesn't necessarily mean that's the case, in which case it poses a huge vulnerability.


ShankThatSnitch t1_je6byq1 wrote

It means it is encrypted on your device, and only decrypted when it reaches the other device.

Sometimes, apps will encrypt the data once it hits the servers, so that, but it is transmitted to those servers un-encrypted first.


Dabliux t1_je6ei80 wrote

Simply put, End to End encrypts the data on the sender's device, and it is decrypted on the receiver's side when it arrives, so it stays encrypted for the whole journey. The only way to decrypt the message is by using the key that only the receiver device has.

Not to be confused with Link Encryption, which works similarly but is able to also encrypt the headers where the routing information is located (IP addresses, MAC addresses, etc). End to End Encryption does not do that; it encrypts the data itself, but not the header.


sacoPT t1_je6lmy4 wrote

It means that the message is encrypted on your phone and decrypted only at the receiver’s phone. Crucially, only the two ends have the decryption key, so it CANNOT be decrypted by the server.

This is in opposition to something like e-mail where your email is encrypted on your phone but decrypted at the email server (Gmail, etc).


PerturbedHamster t1_je6o4i2 wrote

The way modern encryption works is that the receiver has a private key (say two very large numbers) and they send out a public key (say the product of those two numbers). You can encrypt the message with the public key, but to decrypt it you need the private key. This works because it's trivial to multiply two large numbers together, but it's enormously expensive to factor the product of two large primes (until quantum computers come into their own).

If Alice wants to send a message to Bob, Bob can send her his public key. Alice can then encrypt whatever she wants to say to Bob and send it back. Alice may have to send her message through lots of people, but they can't read it without Bob's private key. This is end-to-end encryption - nobody along the way can read it.

Of course, maybe facetergram is sitting between Alice and Bob, and the message goes through them. Facetergram may say "hey, use my public key", then Alice sends a message to facetergram, then facetergram decrypts it, then re-encrypts it with Bob's public key and sends it off. In this world, Alice doesn't need to know Bob's key (convenient!), but facetergram can now read Alice's message if they want to. This is not end-to-end, since the message gets read in the middle.

Incidentally, this is why I think a lot of the law enforcement efforts are colossally stupid. If I'm a criminal, I'll just call up Bob and say "hey, Bob, what's your public key?" Then nobody in the middle can read the message. The software to do this isn't hard - I had to do it for a single homework assignment as an undergraduate. Letting facetergram decrypt your messages is an enormous security hole (what happens if they get hacked?), but if I'm a criminal I'd send messages in a way that they couldn't read. So, only legitimate users (or really dumb criminals) can have their messages read, at the price of potentially disastrous leaks.


BiomeWalker t1_je6yllx wrote

End to End encryption means that the transmission service can't read the content of the message.

The way it works goes a little something like this:

Modern encryption algorithms work on two types of "keys", Public and Privet, for this though you can think of them as a "Lock" and a "Key", if I hand you a lock you don't need any special equipment to put in on a box, but once you do that you can't open it.

The nice part about this, is that you can make an arbitrarily large number of locks for anyone who asks for them, they can be reused by the people you send them to, and no matter how many you make it will still be (until a quantum computer gets big enough) just as secure.

The goal of its development being "anyone can close this, only I can open it"

The step by step of using one of these apps goes as follows:

  • A and B start chatting on an app with E2E encryption
  • The first step is that each of their devices create a set of Locks and Keys and send the Locks to the other
  • A decided to sends the following message to B "Lets meet tonight for dinner"
  • A's app takes B's Lock and encrypts the message and makes it look like this: b'gAAAAABkJKWTY1u2sPwSGTUD0N69P8G5HrKJwRJmM0OnX9l4KJLpCmVOlNxLxPbExPw7XIQJRIhT5CC2gEpuReUq8A5bJlFph_QNmncg7tuJJItifUEMG-g=' (actual encrypted version of text, I used Python's Cryptography module)
  • App then sends that over the internet to B's device
  • B's device can then use B's Key to take the gobbledegook and turn it back into the original text of "Lets meet tonight for dinner"

The big deal about if being "End to End Encrypted" is that anyone who was trying to listen into the conversation by intercepting and copying the messages will only have the encrypted versions which are indistinguishable from noise.

The current method for encryption involves 3 numbers: 2 very large primes and their product, the primes are the privet "unlocking" key and the product is the public "locking" one, this works because it is incredibly time consuming with modern computers to go from the product to the prime factors. Quantum computers are changing this but people are implementing new methods of encryption which will still hold up into the future.

Now there are some problems that can come up which I will quickly run through:

  • Not all encryptions are the same, if they are using a weaker algorithm or shorter keys then it can be broken
  • Some algorithms can be set up with a pre-defined 3rd key that will always work to decrypt every message, in this case the company can read everything anyway and if the key gets out then all the encryption is meaningless
  • Current development of quantum computers means that in the not to distant future it will be possible to break the RSA encryption algorithm which has been widely used for decades and there are actors in the space who are simply gathering encrypted data and sitting on it until they can get their hands on the tools to break it open, as it doesn't go bad.

AnApexBread t1_je74zjq wrote

In short it means that only you and the person you're talking to are able to read the message.

It goes directly from you to them without passing through any servers or anything in-between which can read the messages.


aqhgfhsypytnpaiazh t1_je7sw5v wrote

Encryption means information is transformed in some way such that it cannot be read or changed by unauthorised parties. Typically some kind of secret key is required to read the original information. Modern cryptography uses fancy maths to achieve this.

But "encryption" is kind of an ambiguous thing. Like a lot of services say they use "military-grade encryption!" but the claim is kind of meaningless. What really matters is what data is encrypted, where and by whom.

In a typical computer messaging service, you have the Sender, the Recipient, and in the middle a Server operated by the service provider (eg. WhatsApp/Meta). The Server is needed because directly communicating between two end user devices over the internet is actually pretty hard. The Recipient device may be switched off or out of service range and unable to receive messages, there may be NAT, firewalls or other barriers to establishing connections etc. So the Server handles all messages, temporarily storing messages for retry later, sending out push notifications etc.

In between these 3 parties, you have additional parties involved. The cafe who provides the WiFi; the ISPs who provide the internet connections; other companies or governments who operate the internet infrastructure between ISPs; hackers or rogue employees who gain access to systems and networks; governments who force companies to provide access etc.

So at the very least you want to ensure that the connection between the user (Sender or Recipient) and Server are encrypted to prevent any malicious parties snooping on your messages. A common encryption mechanism uses a pair of keys: a Public key that can be used to encrypt messages, and a Private key that can decrypt them.

End-to-end encryption is a specific type of encryption that takes it a step further; the message content is encrypted on the Sender device (one end), and only decrypted on the Recipient device (the other end). The Server only has enough unencrypted information to route the messages to the correct users/devices, it doesn't need to decrypt the message content. In theory, only the Recipient has the decryption key, so the messaging service provider cannot decrypt it even if they wanted to (or were forced to).

The problem is, end-to-end encryption does not enforce this. You use an app like WhatsApp to generation the keys. There isn't anything that prevents WhatsApp sending a copy of the Private (decryption) key to themselves and reading your messages when they want to. You're trusting them to do what they claim. Then we get to the last part: what is encrypted. It's only the contents of the message. Metadata like how many messages you send, their size, to whom & when, are all accessible to WhatsApp. So end-to-end encryption sounds good in theory, but it you need to understand is limitations.


geh4cktes t1_je82g49 wrote

It basically means that only the sender and the intended recipient can actually read the message. This is in contrast to the usual encryption that is only used to secure message from the sender\receiver to\from the server.

It is important though that there are a lot of companies that don't use Cryptographic terms correctly. Though at least for the large direct messengers (e. G. WhatsApp) they usually do use the term end to end encryption correctly.


Quantum-Bot t1_je873rl wrote

End to end encryption is a way of making sure only the intended recipient of a message can read the message, even if that message has to be passed between many different places to reach where it’s going. This is necessary to protect your data on the internet because every bit of communication that happens, from loading websites to posting on social media to filling out online forms, all happens through the public medium of the internet.

If you’re curious how it actually works, imagine you’re sitting in school and you want to pass a note to your friend three seats away. You don’t want anyone in between to read the note, so before class you agreed on a special algorithm to use to scramble and unscramble the messages. Before you send a message, you’ll scramble it, and when you receive a message, you’ll unscramble it.

This works for a while, but eventually you realize: if anyone ever figures out your secret algorithm, they’ll be able to read all your messages. So, you come up with an even better algorithm. This one takes a password, and combines it with your message as it scrambles it such that anyone who gets the message also needs the password to unscramble it. Then you simply agree on a different password to use every day before class.

This works for a while, but eventually, it’s getting to gossip season and people are really trying to steal your messages and find out your juicy secrets. You decide that it’s too dangerous to share passwords before class because someone might overhear. So, you come up with an even crazier algorithm. This one requires two different passwords, one to scramble and one to unscramble. When you want to send a message, you now have to first pass a note to your friend saying you’d like to send a message. Then, they will come up with a scramble password and an unscramble password. They reply to you with the scrambling password. You then use the scrambling password to scramble your real message and you send it back to your friend. Finally, they use their unscrambling password to unscramble the message. This system is perfectly secure because you need the unscrambling password to read the message, and that password is never shared with anyone, so only your friend knows it.


aaaaaaaarrrrrgh t1_je8r8ji wrote

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


billdietrich1 t1_je99asr wrote

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.


PippenDunksOnEwing t1_je6pjqh wrote

Thank you for the replies.

Assuming the companies do what they claim, then is messaging through WhatsApp the same as Signal?


Adversement t1_je6xks9 wrote

Pretty much yes. For normal users, the modern almost ubiquitous end-to-end encryption just exists and works, and the two officially use pretty much identical key exchange.

Whatsapp even allows the user to check (offline, or IRL face-to-face, or say by sending the shown check data by a letter) that you and the other end of a given chat are actually an end-to-end encrypted pair (which would bust a third-party man in the middle impostoring as your friend for you and vice versa for your friend). Of course, Whatsapp is closed source app (but then again, did you build your Signal yourself from source on your device, and do you trust the source audits...).

So, probably depends on why you need it. Nice to have, especially as it should reduce Whatsapp to just use your metadata for marketing purposes (like to whom and when and how often) and not the actual message contents. Signal pf course doesn't do even that.


PippenDunksOnEwing t1_je6zy92 wrote

Appreciate your detail response.

I went over to Signal for privacy purposes and like you said metadata mining; yet majority of my friends remain at WhatsApp so it's really hard to stay away...