3

I was reading up on end to end encryption and I mostly found applications in messaging (Whatsapp, Telegram etc) and well, email (PGP (sort of?)).

I am curious to know if there are applications for End to end encryption beyond these. Say, communication between two processes in a distributed system? Not sure if they really need end to end encryption.

9
  • 3
    HTTPS is end-to-end encryption too (i.e. web browser to web server). And this is probably much more used than messaging and email together. Feb 28, 2018 at 5:29
  • To be fair, E2EE usually refers to the communication between (end) users of a system, not client-server communication.
    – Arminius
    Feb 28, 2018 at 5:48
  • @Arminius: In case of accessing content on a web server the server is the intended endpoint of the communication and thus HTTPS provides end-to-end encryption. Contrary to this in a web based chat system where the server has access the messages in clear the server is not the intended endpoint and thus it is not end-to-end encryption. In other words: TLS (and also HTTPS) can be used to provide end-to-end encryption but this does not mean that all TLS is end-to-end. Similar not all PGP is end-to-end, for example if company wide encryption gateways are used. Feb 28, 2018 at 6:54
  • All good encryption technology is end to end. What most people mean when they say end to end is really just whether the ends are actually where you think they would be.
    – Lie Ryan
    Feb 28, 2018 at 7:45
  • 1
    essentially anything that uses encryption on the application layer will be E2E. If you upload a password protected zip backup to something like dropbox, that's E2E, no matter what the providers are doing.
    – dandavis
    Feb 28, 2018 at 17:45

3 Answers 3

3

I think just asking for use cases of end-to-end encryption is a very broad question. But in general: whenever two parties exchange sensitive information which need to be protected against sniffing (and probably also modification) by a third party end-to-end encryption makes sense. This includes for example direct messaging, mail communication, protecting passwords entered into web sites, protecting your online banking, telephony, accessing a remote desktop, management of a remote device in the context of IoT and many many more.

You should also note what end-to-end encryption does not offer. While (almost?) all end-to-end encryption implementations protect the message against modification they often don't provide the assurance that the sender is the claimed one or that no message are lost or that messages got replayed. But these are often requirements you have in end-to-end scenarios and which then need to be provided by additional techniques, like cryptographic signatures or message counters.

And then there are cases where end-to-end encryption does not provide the protection one might hope. For example, if you have two processes on the same machine and owned by the same user then end-to-end encryption probably does not make much sense. It does not protect against a user with same or higher privileges since this user could ptrace the applications to extract the unencrypted data from there. For this scenario a communication using (properly protected) UNIX domain sockets or use of socketpair or pipe offers the same protection but without the overhead of encryption.

4
  • "Almost" all is correct. SSHv1 supported using a CRC for message integrity, allowing spoofed messages. The IRC end-to-end encryption protocol FiSH is fairly popular but uses ECB by default (though plain CBC is also supported). It is vulnerable to replay attacks as well. Duplicity does end-to-end backups but can be configured not to cryptographically sign the backups. I'm sure there are plenty more.
    – forest
    Feb 28, 2018 at 8:02
  • Thanks for the elaborate answer! I had been going with the colloquial use of E2E so did not think of SSL as an end to end scheme. Can you expand a bit on "protecting your online banking" ?
    – Limit
    Feb 28, 2018 at 15:30
  • 1
    @Limit: When doing online banking within a browser hopefully HTTPS is used and the endpoint of the connection is the bank, which is the expected endpoint for the user. Any information entered (password, TAN.. whatever is used) is protected end-to-end Feb 28, 2018 at 16:20
  • Thanks! I thought there was something other than HTTPS that you were talking about so asked
    – Limit
    Feb 28, 2018 at 18:57
3

Some examples of end to end encryption that aren't messaging:

  1. Cloud based password manager where all cryptography are on the client side, and the server is designed to be an untrusted party

  2. Cloud file storage/sync/backup where all encryption are done in the client side, and the server is designed to be an untrusted party

  3. A command and control server hosted on the hacker's basement running as a Tor Hidden Service

0
  • Yes, PGP is usually e2e.
  • Cloud storage is rolling out e2e, see Nextcloud.
  • Backups are sometimes done e2e.
  • Websites, as mentioned above, seem like they are e2e from the server to the client so they cannot be read by the coffee shop WiFi.

The last example illustrates that some things seem like they are e2e but according to the wikipedia definition and what seems like common usage to me e2e is between users or their devices. Otherwise essentially all encrypted communication qualifies as e2e between the encrypting parties. So a connection to a webserver would normally not be considered e2e. Nor would communication between distributed systems. Of course the term still makes sense and might well be used. It's not a standard in any way.

2
  • "Cloud storage is rolling out e2e" That's overly broad. That a few open source "private cloud" (i.e. just a server) software packages are doing e2e, doesn't mean that cloud storage in general is moving in that direction. I see it as a big shortcoming that they're not, so I'd try to avoid creating this impression.
    – Luc
    Feb 28, 2018 at 10:10
  • @Luc I agree that's why I wanted to point out that there is now almost an option that does e2e. ;)
    – Elias
    Feb 28, 2018 at 16:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .