3 ms·

It isn't end-to-end encryption if you have to trust someone in the middle. Right?

bawolff 5y ago
Well usually the term end-end means from you directly to the user you are talking to (if its in a chat context for example). TLS (in its normal usage) isn't end to end, putting encryption in a lower layer makes it even less likely to be end to end. In end to end encryption, preventing mitm attacks is the hardest part and often is glossed over. How many people actually verify the "safety number" when using signal? Probably most do not. So i would say common definitions of end to end allows for trusting someone in the middle to not perform active attacks (after all, you also have to trust them not to provide malicious binaries with keyloggers) but should prevent passive attacks by someone in middle.
- Nevermark 5y ago
  Hmm. I think end-to-end needs to remain end-to-end, and you don't need to trust a plethora of third parties if everyone is using the same library/platform for encryption. Middle parties don't need to know anything about the encryption. The source for that library will be extremely well vetted. Maybe the most vetted code ever written. There are practicalities, such as how improved encryption gets added to the protocol, and how clients from previous versions negotiate the best supported encryption between them. Also, affordances for encrypted delayed transmission, i.e. storage in the middle. For instance, email providers would need to store encrypted messages until your local reader downloads them (either to read or store locally). In some cases such as backups, and syncing between your own clients, end-to-end would really just mean your end. As only you would ever decrypt anything. Either way, zero need for any third party to be involved in the encryption, other than the source & binary provider.Go with a highly respected/vetted version, or even a standards committee's reference implementation officially vetted by many entities, and a mechanism for anyone to vet and report. There is some thought needed for the design, as with any platform. And perfection might never be achieved - but things are much less perfect today. The return on that careful work would be an insane drop in the number of disparate implementations needed, and a much safer internet without all the cracks in and between disparate implementation.
  - bawolff 5y ago
    I'm not sure how having a single code base would help anything. Sure, interopable standards are needed, but what benefit does a single code base get us? > Also, affordances for encrypted delayed transmission, i.e. storage in the middle. For instance, email providers would need to store encrypted messages until your local reader downloads them (either to read or store locally). So the scenario here is we add encryption transparently at either layer 3 or layer 4 and the encryption is end-to-end (the email provider cannot read it, only the intended recipient). How would that work? At the very least the email provider would have to know the application level "to" address to route the email. If its end to end encrypted, they cannot as they are a middle party. Maybe you could say that some metadata is unencrypted, but then the encryption is clearly not happening transparently on a low layer if the application layer turns it on and off for different parts of the message. Not to mention - who are you encrypting it to? (Aka which key are you using). If this is transparently on layer 3/4 one presumes the key is tied to the ip address (and maybe port?) as the only identifier available. If its end to end encrypted through a middle man (email provider) for an eventual destination for whom not only do you not know their ip address, they are offline right now so they literally don't have one, how can you possibly get the right key for that transparently without involving the application layer? > There is some thought needed for the design, as with any platform. And perfection might never be achieved - but things are much less perfect today. Personally i think TLS is pretty good all things considered. Its not without trade-offs but most of those trade offs are pretty reasonable given the technical constraints we have. > The return on that careful work would be an insane drop in the number of disparate implementations needed, and a much safer internet without all the cracks in and between disparate implementation. Very few security issues are caused by interoperability issues between different crypto implementations. One implementation might have a bug a different one doesn't, but settling on a single implementation wouldn't stop bugs from being a thing.
    - Nevermark 5y ago
      An email provider would need a "to" code from you when you registered with them. Then with each request to download your mail, they send you a randomly generated number encoded with your "to" code, and you respond by decoding it and sending the number back encrypted with another number they give you. They don't have to know where the mail is actually going, or what is in it. Just that they are getting a request from a person who owns that mail. It gets more complicated than that, for the wonderful reason that there are so many more great things you can once you have standard primitives for encryption and cryptography. For instance, instead of a general email address, you can also give unique addresses to people so that only people you want can send you anything, and you can verify who its from. You can still have a public address just by creating and publicizing an address for that purpose. Once their is a standard library that developers can take for granted there are so many other things that can be easily done. Today many of those things are difficult simply because there is no standard library, and everyone rolling their own implementations creates a nightmare. It is the vetting and fixing every single vulnerability from each implementation that is too difficult for most developers, even very good ones. That is one reason why everything is so insecure today. A first draft of how the encryption works for email would probably one day's white boarding, since the primitives for this kind of thing have been around a long time. And people have done this kind of thing many times before in small contexts. The actual implementation, to be very fast, extremely vetted (even formally verified) for correctness and after iterating many times of possible use cases and corner cases, would take some time. There wouldn't need to be a single code base, but the point is to have very few implementations that are extremely well vet. So few implementations creates better security. That way most applications and users can forget its even there.

Well usually the term end-end means from you directly to the user you are talking to (if its in a chat context for example). TLS (in its normal usage) isn't end to end, putting encryption in a lower layer makes it even less likely to be end to end. In end to end encryption, preventing mitm attacks is the hardest part and often is glossed over. How many people actually verify the "safety number" when using signal? Probably most do not. So i would say common definitions of end to end allows for trusting someone in the middle to not perform active attacks (after all, you also have to trust them not to provide malicious binaries with keyloggers) but should prevent passive attacks by someone in middle.

Nevermark 5y ago
Hmm. I think end-to-end needs to remain end-to-end, and you don't need to trust a plethora of third parties if everyone is using the same library/platform for encryption. Middle parties don't need to know anything about the encryption. The source for that library will be extremely well vetted. Maybe the most vetted code ever written. There are practicalities, such as how improved encryption gets added to the protocol, and how clients from previous versions negotiate the best supported encryption between them. Also, affordances for encrypted delayed transmission, i.e. storage in the middle. For instance, email providers would need to store encrypted messages until your local reader downloads them (either to read or store locally). In some cases such as backups, and syncing between your own clients, end-to-end would really just mean your end. As only you would ever decrypt anything. Either way, zero need for any third party to be involved in the encryption, other than the source & binary provider.Go with a highly respected/vetted version, or even a standards committee's reference implementation officially vetted by many entities, and a mechanism for anyone to vet and report. There is some thought needed for the design, as with any platform. And perfection might never be achieved - but things are much less perfect today. The return on that careful work would be an insane drop in the number of disparate implementations needed, and a much safer internet without all the cracks in and between disparate implementation.
- bawolff 5y ago
  I'm not sure how having a single code base would help anything. Sure, interopable standards are needed, but what benefit does a single code base get us? > Also, affordances for encrypted delayed transmission, i.e. storage in the middle. For instance, email providers would need to store encrypted messages until your local reader downloads them (either to read or store locally). So the scenario here is we add encryption transparently at either layer 3 or layer 4 and the encryption is end-to-end (the email provider cannot read it, only the intended recipient). How would that work? At the very least the email provider would have to know the application level "to" address to route the email. If its end to end encrypted, they cannot as they are a middle party. Maybe you could say that some metadata is unencrypted, but then the encryption is clearly not happening transparently on a low layer if the application layer turns it on and off for different parts of the message. Not to mention - who are you encrypting it to? (Aka which key are you using). If this is transparently on layer 3/4 one presumes the key is tied to the ip address (and maybe port?) as the only identifier available. If its end to end encrypted through a middle man (email provider) for an eventual destination for whom not only do you not know their ip address, they are offline right now so they literally don't have one, how can you possibly get the right key for that transparently without involving the application layer? > There is some thought needed for the design, as with any platform. And perfection might never be achieved - but things are much less perfect today. Personally i think TLS is pretty good all things considered. Its not without trade-offs but most of those trade offs are pretty reasonable given the technical constraints we have. > The return on that careful work would be an insane drop in the number of disparate implementations needed, and a much safer internet without all the cracks in and between disparate implementation. Very few security issues are caused by interoperability issues between different crypto implementations. One implementation might have a bug a different one doesn't, but settling on a single implementation wouldn't stop bugs from being a thing.
  - Nevermark 5y ago
    An email provider would need a "to" code from you when you registered with them. Then with each request to download your mail, they send you a randomly generated number encoded with your "to" code, and you respond by decoding it and sending the number back encrypted with another number they give you. They don't have to know where the mail is actually going, or what is in it. Just that they are getting a request from a person who owns that mail. It gets more complicated than that, for the wonderful reason that there are so many more great things you can once you have standard primitives for encryption and cryptography. For instance, instead of a general email address, you can also give unique addresses to people so that only people you want can send you anything, and you can verify who its from. You can still have a public address just by creating and publicizing an address for that purpose. Once their is a standard library that developers can take for granted there are so many other things that can be easily done. Today many of those things are difficult simply because there is no standard library, and everyone rolling their own implementations creates a nightmare. It is the vetting and fixing every single vulnerability from each implementation that is too difficult for most developers, even very good ones. That is one reason why everything is so insecure today. A first draft of how the encryption works for email would probably one day's white boarding, since the primitives for this kind of thing have been around a long time. And people have done this kind of thing many times before in small contexts. The actual implementation, to be very fast, extremely vetted (even formally verified) for correctness and after iterating many times of possible use cases and corner cases, would take some time. There wouldn't need to be a single code base, but the point is to have very few implementations that are extremely well vet. So few implementations creates better security. That way most applications and users can forget its even there.