Live data from Hacker News

Global Encryption Day: Demand End-to-End Encryption in DMs

blog.torproject.org

51–60 of 78 posts

Re: Global Encryption Day: Demand End-to-End Encryption in DMs

#51
post #19

Earlier quoted context omitted.

So what you're saying is, we can just put a green lock in the UI and call it a day.

We can put some thought into how to set up the third parties to be trusted with our keys. Curretly it's very haphazard. And it's not avoidable. Even Phil Zimmerman, inventor of PGP, won't accept PGP encrypted mail because he claims to have lost his private key. The outrage "own your private keys or bust!" is much easier tho.

Do you happen to know which OS Phil was using, when he lost his private key and what the exact circumstances were? This is a nice story to be told, but without details it is not worth that much.

Re: Global Encryption Day: Demand End-to-End Encryption in DMs

#52

What I find intriguing is that E2EE was significantly more common long ago than it is today. Multi-protocol chat clients would utilize the OTR libraries meaning 'off the record' and even auto-negotiate with folks over AIM, MSN, ICQ, IRC and others to assist in showing fingerprints and sharing public keys which could be done over the platform or out of band if one so wished. I would have expected that by today that no…

> What I find intriguing is that E2EE was significantly more common long ago than it is today.

This is absurd. Today a large fraction of the world's population is using E2EE via WhatsApp.

Re: Global Encryption Day: Demand End-to-End Encryption in DMs

#53

What I find intriguing is that E2EE was significantly more common long ago than it is today. Multi-protocol chat clients would utilize the OTR libraries meaning 'off the record' and even auto-negotiate with folks over AIM, MSN, ICQ, IRC and others to assist in showing fingerprints and sharing public keys which could be done over the platform or out of band if one so wished. I would have expected that by today that no…

> What I find intriguing is that E2EE was significantly more common long ago than it is today. This is absurd. Today a large fraction of the world's population is using E2EE via WhatsApp.

Today a large fraction of the world's population is using E2EE via WhatsApp.

That is good example of the problem I am describing. People are using E2EE created, deployed and maintained by WhatsApp in WhatsApp. That is a problem. The E2EE in WhatsApp is not truly E2EE if it is maintained by the very people providing the service in my unwavering opinion. True E2EE is entirely outside of the service transport that messages are traversing meaning that FB could not possibly intercept the messages even if their livelihood depended on it. Today people have to just trust that FB are not targeting people with custom intercept code or code that otherwise preclude E2EE for specific messages or recipients. That is what I call a pinky promise sometimes also referred to as a Pinky Swear [1].

I follow the logic of, people will do what people can do. If the application can be monkeyed with, it will be. Message encryption must be entirely outside of the purview of the application. Even OTR was somewhat at risk of interception. That is why I would have expected that by today this would have been a solved problem and highly evolved.

[1] - https://en.wikipedia.org/wiki/Pinky_swear

Re: Global Encryption Day: Demand End-to-End Encryption in DMs

#54
post #48

What I find intriguing is that E2EE was significantly more common long ago than it is today. Multi-protocol chat clients would utilize the OTR libraries meaning 'off the record' and even auto-negotiate with folks over AIM, MSN, ICQ, IRC and others to assist in showing fingerprints and sharing public keys which could be done over the platform or out of band if one so wished. I would have expected that by today that no…

I used OTR, but I would not say that it was _more_ common, as that was just a layer over a non E2EE platform like the ones you listed. Using OTR meant using a non-standard client, installing the plugins for it, and configuring it. Worse, all parties you wanted to chat with had to do it as well. Which means it was almost always a novelty feature among nerdy friends and no one else. Because most people did not have it…

Because most people did not have it installed

In my circle of friends, everyone used a non standard client so they could customize the skin of the client. Most of these people were either not technical or at least just technical enough to follow simple instructions. I personally knew many people that used the multi-protocol chat clients. Their primary interest was for the customization capabilities of the client and having all their messages in one place rather than encryption plugins. The vendor clients did not have a dark mode and were nowhere near as customizable. The E2EE aspect was just a nice to have for some.

I suspect this will never be a thing again as vendors might decide to ban accounts that use a client other than their own and people would fear losing their social circles in the vendor locked in services. That is, outside of IRC. One can still use E2EE in IRC.

Re: Global Encryption Day: Demand End-to-End Encryption in DMs

#55
post #19

Earlier quoted context omitted.

We can put some thought into how to set up the third parties to be trusted with our keys. Curretly it's very haphazard. And it's not avoidable. Even Phil Zimmerman, inventor of PGP, won't accept PGP encrypted mail because he claims to have lost his private key. The outrage "own your private keys or bust!" is much easier tho.

Do you happen to know which OS Phil was using, when he lost his private key and what the exact circumstances were? This is a nice story to be told, but without details it is not worth that much.

Why does it matter? Private keys are being compromised or lost under all kinds of circumstances and regardless of the OS.

Re: Global Encryption Day: Demand End-to-End Encryption in DMs

#56

Earlier quoted context omitted.

> What I find intriguing is that E2EE was significantly more common long ago than it is today. This is absurd. Today a large fraction of the world's population is using E2EE via WhatsApp.

Today a large fraction of the world's population is using E2EE via WhatsApp. That is good example of the problem I am describing. People are using E2EE created, deployed and maintained by WhatsApp in WhatsApp. That is a problem. The E2EE in WhatsApp is not truly E2EE if it is maintained by the very people providing the service in my unwavering opinion. True E2EE is entirely outside of the service transport that messa…

There are a few reasons why I think it has to be at the app itself.

In order to be actually secure, all conversions must be encrypted, without exception.

OTR is one channel method of encrypting text, but it isn't the only method. For example using PGP over text messages is also a plugin for pidgin. Competing standards means your ven diagram of people and chat protocols now gets an entire new axis of encrption method.

Metadata is data. Without seeing the message content, it is still valuable to see who is talking to who and when.

There are always tradeoffs. While OTR may be more verifiable secure, it's difficultly hiders adoption. A balance has to be reached with ease of use and security. If it is easy to get it wrong then people will have a false sense of security. That is strictly worse than no actual security.

Re: Global Encryption Day: Demand End-to-End Encryption in DMs

#57
post #56

Earlier quoted context omitted.

Today a large fraction of the world's population is using E2EE via WhatsApp. That is good example of the problem I am describing. People are using E2EE created, deployed and maintained by WhatsApp in WhatsApp. That is a problem. The E2EE in WhatsApp is not truly E2EE if it is maintained by the very people providing the service in my unwavering opinion. True E2EE is entirely outside of the service transport that messa…

There are a few reasons why I think it has to be at the app itself. In order to be actually secure, all conversions must be encrypted, without exception. OTR is one channel method of encrypting text, but it isn't the only method. For example using PGP over text messages is also a plugin for pidgin. Competing standards means your ven diagram of people and chat protocols now gets an entire new axis of encrption method.…

There are a few reasons why I think it has to be at the app itself.

I agree it needs to be in an app, just not the app that is created by the service the person is using. Missing today is a universal chat app that can speak to all the services using standard chat protocols and standard authentication mechanisms. All the popular apps today appear to be highly proprietary and in some cases the vendor will even state that using an unapproved client is forbidden.

Re: Global Encryption Day: Demand End-to-End Encryption in DMs

#58
post #24

Which is why many of us are firmly against RCS. End to end encryption is critically important and no messaging standard should exist that doesn't include it.

RCS does include end-to-end encryption though. https://support.google.com/messages/answer/10262381

No, it does not. Google’s proprietary implementation implements Google’s proprietary encryption system. RCS does not.

Re: Global Encryption Day: Demand End-to-End Encryption in DMs

#59

What I find intriguing is that E2EE was significantly more common long ago than it is today. Multi-protocol chat clients would utilize the OTR libraries meaning 'off the record' and even auto-negotiate with folks over AIM, MSN, ICQ, IRC and others to assist in showing fingerprints and sharing public keys which could be done over the platform or out of band if one so wished. I would have expected that by today that no…

ICQ and the like threatened to close your account when you used OTR.

Re: Global Encryption Day: Demand End-to-End Encryption in DMs

#60
post #58
post #24

Earlier quoted context omitted.

RCS does include end-to-end encryption though. https://support.google.com/messages/answer/10262381

No, it does not. Google’s proprietary implementation implements Google’s proprietary encryption system. RCS does not.

While this is currently only in Google's and Samsung's Messages apps, it's basically just the Signal protocol implemented as an RCS extension. It will most likely end up formalised in the next standard release of RCS.
Post reply on HN