Remember when Zoom claimed that meetings were E2EE yet you could join the meeting by phone and no one batted an eye for at least one or two years? Noticed how no regular person cares when the "security code" of a chat partner changes in WhatsApp or Signal? Not to mention no regular person uses self-compiled apps for that, even if it were possible. E2EE is close to becoming a cargo cult, because done properly key management and identity verification are a usability nightmare. It will always remain a toy for a niche audience. Most people just don't care, and the non-technical people that do care are happy with a green lock appearing somewhere. I do hope to be proven wrong, though.
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.
IMhO, one company tacled that very problem head on and did a fantastic job and it's my by far prefered chat (+ more) app today. Ironically, that company, https://keybase.io, got acquired by Zoom. Keybase still works today (thankfully), but there are AFAIK no guarantees for how long.
Keybase Chat is fully encrypted, persistent, and cross platform, and has the best solution to the identity problem.
Cargo cult? No. It's not perfect but end-to-end encryption is demonstrably better than whatever we had before. WhatsApp encryption is the same as Signal's and it has already defeated police and courts here. Some judges got so pissed off they ordered WhatsApp to be blocked nation-wide.
We don't live in a perfect world. I'm glad that everyone I talk to is using something this secure by default.
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 not only would this be more common but that the technology would have significantly advanced by now. Instead the opposite appears to be true. People are instead using apps that pinky promise to E2EE things and depend on the chat service to handle the trust mechanism for them which in my view entirely defeats the intent and purpose of E2EE. I assume the motivation is the desire to capture and monetize every conversation, especially the private conversations and/or to comply with national security letters. I've heard people try to rationalize this with because non technical people but non technical people were utilizing OTR just fine.
What could realistically be done to reverse this in a way that puts the control back into the individuals hands? i.e. Even if all the kings horses and all the kings men wanted your messages they could only pound sand again and again.
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 installed, having it auto negotiate always was a non-starter. It meant people who didn't have it would recieve cryptic messages from you at the start of each session and then complain to you.
So most of the time it was completely manual process of enabling it for _some_ chats, and this leaks a massive amount of data. It basically declares that for this particular chat sometime might have been interesting. Often the chat log would include a plain text message like "Let's switch to OTR".
Unlike you I could not get any non-technical friends to care about OTR enough to install it. I have difficulty even today getting people interested in Signal. I still hear arguments like "I'm not that interesting, they can look" and "I've got nothing to hide"
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.
This may be due to policy activism on the side of governments.
I think asking service providers to use more E2EE is not the right approach. Governments' intelligence agencies do not shy away from infiltrating commercial vendors (from Yahoo! to the infamous Crypto AG - https://en.wikipedia.org/wiki/Crypto_AG).
1. People should diversify across many, in particular smaller platform, so that surveillance cannot be done as it becomes a scale & long tail problem.
2. People should use P2P E2EE protocols and GPG-encrypted emails. The single biggest step forward would be easier ways to set up public key encrypted email part of e.g. Mozilla Thunderbird and other clients. But in parallel an attitude change is needed, for the receiving end needs to know how to open an encrypted email.
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.
None of what you lament has been lost. OTR still exists and is used by some folks. There are still OTR supporting clients that also support the current proprietary messaging systems like Facebook. The only thing that was lost is that most people moved away from using Free Software for communication and most new people were born into and grew up within proprietary communication ecosystems.
Please note that OTRv3 uses significantly outdated encryption. There is OTRv4 but it isn't finished yet.
As I understand it, if we had true end-to-end encryption, I would have to make sure I kept a set of keys, copied them between every computer and phone I used for chatting, and if I lost those keys I'd lose all my messages?
Honestly, for most people I don't think that's functionality they would want, at least without us getting much better at interfaces and usability. Standard ways of storing keys, for example in a password manager, would be a good start (does this already exist and I've missed it?)
Not neccessarily, that just happens with bad implementations (i.e. most of them, sigh).
If you get a confidential letter in the physicsl world, you open it, read it, and then store it in a safe,.or a locked drawer, correct?
The software world chose to "re-seal" the letter in its envelope again instead. So if you loose your key, you loose access to the letter. The proper way to implement this would be to store the decrypted contents in the software equivalent of a lockable drawer, e.g. an encryped disk, folder or whatever. Which could (and should) have sensible fallbacks to retrieve its content.
> and if I lost those keys I'd lose all my messages?
Only if the developers of the software insist on encryption at rest in addition to transit encryption.
For example, you don’t lose the ability to open files you have already downloaded via HTTPS just because the client or server certificate later expires.
Using a password manager in a sensible manner already goes a long way! Most synchronized E2EE services only ask for a master passphrase to encrypt your keys before storing them server side (e.g Bitwarden, Keybase, ProtonMail).
Then you only need your password manager to recall the passphrase when synchronizing a new device!
People need to learn again how the devices in their pocket work and the risks for not doing things properly!
IMHO, for most people the best interface would be a physical key (with software keys on it). That is something like a smartcard or ubikey, and even a way of obtaining multiple copies, like with physical keys.
My employer rolled out a smartcard based PKI about 15 years ago, where you may own more than one card (optionally in sim card size for usb tokens) so, for example, you can have one in the office and have another one in your home office. Works quite well (modulo mobile) for now abour 30K employees. And, combined with RFID on the cards, you can call elevators, open doors, pay for food, etc.
Now if hardware manufacturers had standardized on appropriate hardware (chassis, keyboards, smart devices…) some 20 years ago, instead of trying (and failing) all kinds of software "solutions" … and thinner and thinner hardware, so no such cards or sticks would fit anymore …
The difference is: If you lose your smartcard, it's pretty straight forward for your employer to verify your identity and issue a new one.
How do I do that with WhatsApp? We all know how well these tech giants react if you got permanently locked you out of accounts, no matter whose fault it was.
And even if I could get a new key, I would have to explain to all my contacts why my key changed and they would have to re-verify it over a secure channel. It doesn't scale.
Now you might say: just keep multiple copies, but there will be cases where people lose all copies, and depending on how much of our digital lives will be tied to these keys, we will need a secure recovery plan for that.
The secret bits can be protected by a strong passprase (which you can print out) or kept in a hardware device that also does enough of the cryptography to allow the secrets to stay on the hardware device. After that the problem becomes one of backup. You can scatter your encrypted keys all over the internet if you want (or just on a reliable server somewhere). You can have a bunch of hardware devices stored in various safe places and protected in various ways.
You often hear advice that comes down to keeping, say, your PGP keys in one secure place, but that is a terrible idea... E2EE encryption needs a good backup approach. If your system does not provide that in a easy to use way for the user then you have a bad system. E2EE encryption is hard but it doesn't help to leave all the hardness for the user.
> As I understand it, if we had true end-to-end encryption, I would have to make sure I kept a set of keys, copied them between every computer and phone I used for chatting, and if I lost those keys I'd lose all my messages?
Unless you made an unencrypted backup, then yes, that's true and that is the reason why Telegram decided against E2EE by default. According to them their users prefer easy cloud access to their messages over security.
> According to them their users prefer easy cloud access to their messages over security.
And likewise with e-mail, PGP et al. break some features that rely on your mail server having access to the full message contents, like content-based message filtering (spam or otherwise) and server-side search.
How do you know if the Signal client running on your phone right now doesn't include a backdoor? Sure it's open source. But how do you know how it was compiled?
What if someone changed the open source before shipping it to the app store?
> the Signal Android codebase includes some native shared libraries that we employ for voice calls (WebRTC, etc). At the time this native code was added, there was no Gradle NDK support yet, so the shared libraries aren’t compiled with the project build.
Also, assuming you trust the client, how to tell if the Signal server is running the published code, especially given Signal's track record of (not) publishing its source code?
How do you know that the AES instruction set on your device's processor doesn't include a backdoor? Sure, the algorithm is public, but how do you know how it was implemented?
AES starts with 16 bytes and then encrypts it to 16 bytes. So there is no good place to hide extra data. Even a single bit that did not meet the AES spec for the key in use would produce complete garbage at decryption. So attempts to leak the key would at least leave a mark.
If someone with skills X (where depending on your knowledge and precautions, X can range from script kiddie to nation state) is after you specifically, you can only make their job harder, but unless you are very serious about security, you’ll probably get pwned.
If you want general security, you can probably take it as given that someone checked the Signal build to be the one that the source is available for, and that no one intercepted just your download. But you still have to take some parts on faith, always, unless you build your own CPU and continue from there.
Exactly. Demand an open source for every encryption app - or at least those offered to the public en masse.
It's not enough that a FOSS alternative _exists_; it needs to be the case that closed-source encryption is not considered as an actual encryption "end".
Given how everyone uses TLS nowadays, a better analogy would be for the dealership to retain a copy of the key to your car after you buy it. Which would probably upset people but isn't as bad as having no lock at all.
Readit News
The outrage "own your private keys or bust!" is much easier tho.
Keybase Chat is fully encrypted, persistent, and cross platform, and has the best solution to the identity problem.
We don't live in a perfect world. I'm glad that everyone I talk to is using something this secure by default.
Dead Comment
I would have expected that by today that not only would this be more common but that the technology would have significantly advanced by now. Instead the opposite appears to be true. People are instead using apps that pinky promise to E2EE things and depend on the chat service to handle the trust mechanism for them which in my view entirely defeats the intent and purpose of E2EE. I assume the motivation is the desire to capture and monetize every conversation, especially the private conversations and/or to comply with national security letters. I've heard people try to rationalize this with because non technical people but non technical people were utilizing OTR just fine.
What could realistically be done to reverse this in a way that puts the control back into the individuals hands? i.e. Even if all the kings horses and all the kings men wanted your messages they could only pound sand again and again.
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 installed, having it auto negotiate always was a non-starter. It meant people who didn't have it would recieve cryptic messages from you at the start of each session and then complain to you.
So most of the time it was completely manual process of enabling it for _some_ chats, and this leaks a massive amount of data. It basically declares that for this particular chat sometime might have been interesting. Often the chat log would include a plain text message like "Let's switch to OTR".
Unlike you I could not get any non-technical friends to care about OTR enough to install it. I have difficulty even today getting people interested in Signal. I still hear arguments like "I'm not that interesting, they can look" and "I've got nothing to hide"
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.
I think asking service providers to use more E2EE is not the right approach. Governments' intelligence agencies do not shy away from infiltrating commercial vendors (from Yahoo! to the infamous Crypto AG - https://en.wikipedia.org/wiki/Crypto_AG).
1. People should diversify across many, in particular smaller platform, so that surveillance cannot be done as it becomes a scale & long tail problem.
2. People should use P2P E2EE protocols and GPG-encrypted emails. The single biggest step forward would be easier ways to set up public key encrypted email part of e.g. Mozilla Thunderbird and other clients. But in parallel an attitude change is needed, for the receiving end needs to know how to open an encrypted email.
This is absurd. 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
Please note that OTRv3 uses significantly outdated encryption. There is OTRv4 but it isn't finished yet.
https://bugs.otr.im/otrv4/otrv4 https://github.com/otrv4/otrv4/
Honestly, for most people I don't think that's functionality they would want, at least without us getting much better at interfaces and usability. Standard ways of storing keys, for example in a password manager, would be a good start (does this already exist and I've missed it?)
Not neccessarily, that just happens with bad implementations (i.e. most of them, sigh).
If you get a confidential letter in the physicsl world, you open it, read it, and then store it in a safe,.or a locked drawer, correct?
The software world chose to "re-seal" the letter in its envelope again instead. So if you loose your key, you loose access to the letter. The proper way to implement this would be to store the decrypted contents in the software equivalent of a lockable drawer, e.g. an encryped disk, folder or whatever. Which could (and should) have sensible fallbacks to retrieve its content.
Only if the developers of the software insist on encryption at rest in addition to transit encryption.
For example, you don’t lose the ability to open files you have already downloaded via HTTPS just because the client or server certificate later expires.
People need to learn again how the devices in their pocket work and the risks for not doing things properly!
My employer rolled out a smartcard based PKI about 15 years ago, where you may own more than one card (optionally in sim card size for usb tokens) so, for example, you can have one in the office and have another one in your home office. Works quite well (modulo mobile) for now abour 30K employees. And, combined with RFID on the cards, you can call elevators, open doors, pay for food, etc.
Now if hardware manufacturers had standardized on appropriate hardware (chassis, keyboards, smart devices…) some 20 years ago, instead of trying (and failing) all kinds of software "solutions" … and thinner and thinner hardware, so no such cards or sticks would fit anymore …
How do I do that with WhatsApp? We all know how well these tech giants react if you got permanently locked you out of accounts, no matter whose fault it was.
And even if I could get a new key, I would have to explain to all my contacts why my key changed and they would have to re-verify it over a secure channel. It doesn't scale.
Now you might say: just keep multiple copies, but there will be cases where people lose all copies, and depending on how much of our digital lives will be tied to these keys, we will need a secure recovery plan for that.
You often hear advice that comes down to keeping, say, your PGP keys in one secure place, but that is a terrible idea... E2EE encryption needs a good backup approach. If your system does not provide that in a easy to use way for the user then you have a bad system. E2EE encryption is hard but it doesn't help to leave all the hardness for the user.
Unless you made an unencrypted backup, then yes, that's true and that is the reason why Telegram decided against E2EE by default. According to them their users prefer easy cloud access to their messages over security.
And likewise with e-mail, PGP et al. break some features that rely on your mail server having access to the full message contents, like content-based message filtering (spam or otherwise) and server-side search.
What if someone changed the open source before shipping it to the app store?
https://signal.org/blog/reproducible-android/
I have a phone with Signal on it. Tell me what I should do to verify it's running the open source Signal code.
> the Signal Android codebase includes some native shared libraries that we employ for voice calls (WebRTC, etc). At the time this native code was added, there was no Gradle NDK support yet, so the shared libraries aren’t compiled with the project build.
Also, assuming you trust the client, how to tell if the Signal server is running the published code, especially given Signal's track record of (not) publishing its source code?
https://linuxreviews.org/Signal_Appears_To_Have_Abandoned_Th...
https://bootstrappable.org/
Otherwise somewhere in the chain you are relying on binaries of unknown provenance.
If someone with skills X (where depending on your knowledge and precautions, X can range from script kiddie to nation state) is after you specifically, you can only make their job harder, but unless you are very serious about security, you’ll probably get pwned.
If you want general security, you can probably take it as given that someone checked the Signal build to be the one that the source is available for, and that no one intercepted just your download. But you still have to take some parts on faith, always, unless you build your own CPU and continue from there.
Dead Comment
It is fallacious because you'll never get there if you're not allowed to make incremental advances.
It's not enough that a FOSS alternative _exists_; it needs to be the case that closed-source encryption is not considered as an actual encryption "end".
It literally isn't possible for an ordinary person to audit all code.
At some point you have to blindly trust.
https://mako.cc/copyrighteous/google-has-most-of-my-email-be...
https://briarproject.org/how-it-works/
We don’t want the dealership to keep the key, but we do want them to give us a new one if we lose it.
So afaik we trust the manufacturer to keep the info, and to keep sufficient logs that anyone that abuses it to steal cars can be caught.
I don’t think the way this is works can be extended to communications apps though.