They absolutely do work, as proven by email.
In other words, it didn’t accomplish what any pro-Federation activist actually wants to accomplish.
The fact is that you generally don't, because you want to access your mail from any device and you want a server-side search. All of this is made impossible by a proper e2ee.
Also, proper e2ee requires identity verification of your contacts, where you check their key fingerprints using an uncompromised channel. If you skip this part, all e2ee you use is just a security theater.
[1] https://delta.chat/en/help#which-standards-are-used-for-end-...
Not with the same security guarantees, the same usability, nor the absence of footguns that apps such as Signal provide.
> Also, proper e2ee requires identity verification of your contacts, where you check their key fingerprints using an uncompromised channel. If you skip this part, all e2ee you use is just a security theater.
Even if you don't check fingerprints, you're fully protected against passive attackers, as well as attackers who started being active only after the key exchange. For casual users, Signal is a good protection against dragnet surveillance. For advanced users, Signal with key fingerprint checks is a good protection against more powerful attackers that control the network.
It is not a protection, just a security theater. If you don't trust your service provider not to spy on you, you must not trust it completely. Thus, Signal tells you that you are talking to Joe, but it can easily make it so that you talk to MitM who talks to Joe, for everyone, dragnet style. (those who do indeed verify fingerprints are excluded from this program)
Nobody but the slim nerdy minority wants to burden themselves with proper e2ee, yet everyone insists on having some snake oil too.
Don't want to be spied by your service provider - run you own server. That's what federation is for.
If they introduced blanket MitM, it would only take one person to verify fingerprints for it to become public. You mention that people who verify fingerprints would be excluded, but I've no idea how you'd achieve that. My understanding is that proper fingerprint confirmation has to, by definition, be conducted out of band.
With any FLOSS everyone is trusting that another geek somewhere is paying attention to a particular piece of software and will raise the alarm if there is something wrong. And I do mean everyone. I don't think its conceivable that even the most paranoid, technically proficient user could verify the integrity of their entire technology stack.
You see, this is all a question of trust. The only threat against which the e2ee is useful is non-trusted server admin. But then signal fans paradoxically don't trust Signal to have their unencrypted communications and simultaneously trust them to have means to get access to their messages.
So in practice a personal/corporate email / xmpp server without any e2ee gives you a better level of security than using third party service like Signal with e2ww, because in that case the attacker will have to somehow gain admin access to your server to learn anything about your communications, while in Signal's case, even if they don't compromise your encryption, they still have means to know who you are talking with, when, your IP addresses, etc.
(and don't even let me started on that crap where Signal supposedly has no ability to know who is sending you a message - it all can be logged on server side, and we're not trusting the service operator, right?)
Tldr: insisting on e2ee while fully trusting third party infrastructure is double-think at its best. If you want to be safe, use self-hosted servers. Which brings you to federation. :-D
The fingerprint is computed at key exchange, you can't change it after the fact without warnings about it. If you assume the clients are compromised, E2EE or federation or other network properties won't help, so this discussion is meaningless.
Nobody claimed E2EE was the be-all and end-all of security; only that it's an improvement over having to trust a 3rd party. This is because everything else being equal, the less components you trust, the better security-wise. So given a network operator, if you can choose between trusting them or not, you'll be better off not trusting them. That's why E2EE is better than no E2EE.
Finally "use your own server" seems like the perfect solution if you're only talking to yourself. To take the email example, just because you trust gmx.de doesn't mean you want to trust mail.ru, but it seems that you're either suggesting that the trust propagates between servers in the same federated network (obviously not the case), or that you can just demand your recipients use the server you chose, ending up with a centralized silo within the federated network, which is itself a contradiction.
Compromised apps can very much silence such warnings.
> If you assume the clients are compromised, E2EE or federation or other network properties won't help, so this discussion is meaningless.
Federation absolutely helps. If you get your service and your (preferably open-source) software from different sources, the chances that you'll be attacked via software backdoors is significantly reduced, especially when there are many competing apps. If you run the server yourself, the chance to be compromised becomes infinitely small.
Again, this is not a useful take since this equally applies to any other app, federated or not.
> If you get your service and your (preferably open-source) software from different sources, the chances that you'll be attacked via software backdoors is significantly reduced
No, you just need one of the trusted component to be compromised to lose your security guarantees. You're suggesting to increase your attack surface instead of reducing it.
Wrong. If your client software and service come from different vendors, it is by far harder to attack your privacy via compromised apps - especially if there are multiple vendors of client software and reputable open source repositories like f-droid who build apps from sources.
> No, you just need one of the trusted component to be compromised to lose your security guarantees
While this looks to be true, in real world practice it is completely not so. It is far harder sneaking a backdoor into a F-droid app, with far bigger reputation risks, than doing it in Signal app - especially if the attacker knows which account should be affected. And in a federated environment the attacker might not even know your account name.
> It is far harder sneaking a backdoor into a F-droid app, with far bigger reputation risks, than doing it in Signal app
We'll have to agree to disagree.
Signal is a perfectly good protection against passive attackers. MITMing a non negligible portion of Signal users would be too visible to be worth doing. This doesn't solve target surveillance (but key fingerprint checks help there), but this does ensure that most of the data exchanged via Signal services does not feed NSA databases.
> If you don't trust your service provider not to spy on you, you must not trust it completely.
Ideally you wouldn't trust anything nor anyone, that's the Mossad thread model and it's not useful to judge incremental improvements.
> Don't want to be spied by your service provider - run you own server. That's what federation is for.
A server running where? Most "servers" are rented from a big cloud provider, and there's no physical control over it. Having to trust these is definitely worse in terms of security. This is also forgetting the users Signal is targeting, who are not technical users, but precisely people who don't know what a server is.
You are not trusting Signal to have your unencrypted chats. Why do you trust their client apps? You aren't building them yourselves, right? MitMing ALL users and just showing them matching fingerprints so they feel safe is pretty plausible, since all users communicate using one central server. Of course, this MitMing is best perpetrated by Signal themselves.
> A server running where? Most "servers" are rented from a big cloud provider, and there's no physical control over it.
If you are a criminal, somewhere in TOR. If you are a legal organization, in your server room. If you are neither, nobody freaking cares about your chats and you might as well keep them unencrypted, enjoying better portability and overall improved user experience, as proven by Telegram.
Because it's open-source, has been reviewed extensively, and people (with various degrees of expertise) keep looking at it.
> You aren't building them yourselves, right?
It builds reproducibly on Android, so this doesn't matter.
> If you are neither, nobody freaking cares about your chats
That's not what the Snowden leaks showed, nor what scandals about e.g. some $BIG_CORP employees stalking their acquaintances via their privileged accesses demonstrated. E2EE on Signal means I don't have to trust that some employees won't abuse their rights to access my data. Do you even know how many people could access your Telegram chats if they wanted to? Just look up "stalker facebook employee", this is not some theoretical scenario.
You're basically saying you and others have "nothing to hide". This argument has been repeated and debunked ad nauseam, if the whole literature against this stance hasn't convinced you yet I don't have more to convince you now.
Sooo your security is based on blind trust in some people out there who definitely do keep looking at Signal's apps, somehow verify that every shipped version of their app contain the same code as their open source repository? That's a lot of trusting.
(Wouldn't it be simpler to just trust Signal not to watch what you are texting to your significant other, and keep everything without encryption, saving yourself a lot of trouble?)
> E2EE on Signal means I don't have to trust that some employees won't abuse their rights to access my data.
So your threat model are Signal's employees who might be stalking you? You know, you could run a $2/month xmpp server that would serve you just fine, and you wouldn't have to worry about any threat of this kind. This not-working-federated-protocol is surprisingly effective in sending and receiving messages.
This doesn't hold in practice, you simply cannot trust any single entity about this, since it's bound to be abused eventually.
> You know, you could run a $2/month xmpp server that would serve you just fine, and you wouldn't have to worry about any threat of this kind.
So instead of managing my client, I need to manage both my client and a server, and trust this server on top of the client? That's obviously worse, I'm starting to think you're trolling.
For the record, Signal's servers run on US cloud providers, including AWS and Google Cloud. Signal do not have physical control over their machines either, which I believe invalidates this point about self-hosting.
On the other hand, I don't need to trust Signal's servers, by design, thanks to E2EE.
Does this use mind-reading or time travel? Which is it?
Suppose I walk across to my friend Steve's house tomorrow and I verify our Safety Numbers match. Do the Secret Police hop into their time machine and go back and cross Steve and myself [and all our contacts?] off their MITM list?
Or did they use precognition to know I was going to do it and so they were able to never intercept the affected messages in the past?
> Don't want to be spied by your service provider - run you own server. That's what federation is for.
Notice that when you do this, the Secret Police's job is suddenly trivial. Gee, I wonder who we should arrest for this conspiracy that was organised on Andrew_nenakhov's server? Let's try starting with Andrew_nenakhov. Bingo.
Job #1 if you actually don't want this sort of global surveillance effort to be successful is Don't Stand Out. If your traffic is special, if your users are different, if your service is unlike all the others - you are a target. So blend in, that means you use TLS because everybody else does, and you use Google's Play message service because everybody else does, and you use the same server for all the mundane shit that is used for the plot to kill the Secret Police chief.
Read my lips.
You do not trust the service provider. To be consistent, you do not trust the software provided by this provider. From here, the possibilities are endless. They can just show you some fingerprint numbers so you feel safe, while in practice they might be completely unrelated to the real keys. Or whatever. The keys you verify with your friend Steve might be generated on the very moment you look at them, unrelated to your prior keys that you used 'trusting' the Signal's CA.
> Job #1 if you actually don't want this sort of global surveillance effort to be successful is Don't Stand Out.
That's why just use a plain old email server in TOR network, not tied to your identity. Email blends in juuust fine, certainly much better than centralized silo Signal where your accounts are tied to your identites.
These are completely different threat models. You're saying that since you can't have bulletproof security, you might as well have none. This is simply not the case.
At least with encrypted email you are less likely to kid yourself. If you do figure it out then the existence of identities you treat as objects ("public keys") makes it intuitively obvious that you have to get the right one.
I am old enough to be pretty cynical about this stuff. People keep on coming up with purely technical solutions to the encrypted messaging problem. They all eventually fall down on the human side. This isn't working. We have to do something else.
[1] https://www.ndss-symposium.org/wp-content/uploads/2018/03/09...
This is a post on the Signal blog. They are obsessed with E2E encryption, and will never be talked down from it.
Also, I presented several problems with email, not just poor support for encryption.
> Email can be e2e encrypted easily if you want it.
E2E encryption should have forward secrecy. The way that’s usually implemented requires “handshake” messages to be exchanged before the payload is sent anywhere, which cannot be easily retrofitted onto PGP (adding it would be less “encrypted email” and more “an entirely different communication protocol, tunneled over SMTP”). The Axolotl ratchet that Signal uses requires the key for a communication channel to change over time, which is also pretty far away from what PGP and S/MIME currently do.
> The fact is that you generally don't, because you want to access your mail from any device and you want a server-side search
Signal and WhatsApp both exist and people use them, so they obviously aren’t deal-breakers.
> Also, proper e2ee requires identity verification of your contacts, where you check their key fingerprints using an uncompromised channel
It requires you to verify the identity of one, initial contact to bootstrap your social network. From then on, the “uncompromised channel” can be the previous E2E encrypted channel you already created.
I'm not responding to a person who writes the Signal blog. I'm arguing with a silly statement 'but but email doesn't have e2ee'.
Spam problem is big, and can be solved in other federated protocol like XMPP by requirement to authenticate sender before sending a message.
> E2E encryption should have forward secrecy.
That is an arbitrary requirement imposed by you just now. For many people it absolutely SHOULD NOT have forward secrecy, and a message signed by a public trusted key would be much better.
Regarding that 'axolotl ratched', my developers have implemented it on at least 2 platforms, that protocol can absolutely be ported to email. But nobody will do it because in practice nobody really needs it, just some obsessed nerds.
> Signal and WhatsApp both exist and people use them, so they obviously aren’t deal-breakers.
... And Telegram CRUSHES them with BY FAR superior user experience precisely because they DON'T have e2ee for regular chats.
> It requires you to verify the identity of one, initial contact to bootstrap your social network.
No, this is a security theater again. If you need e2ee you should not trust someone else to do a verification work for you. Not your contacts, not a Signal's CA, nobody. Imagine you are a gangster in a sinister organization. All it would take to compromise your communications is just one mole coerced to work with the police.
And if you aren't willing to do this work because it is too burdensome, you should honestly face the fact that nobody is interested in your communications, and that your insistence on e2ee does not, in fact, increase your privacy, but just makes you feel more safe.
Curios, why? What scenarios does PFS protect you from exactly?
So first you implement an e2ee protocol with PFS, then make a hole in your security to make using it a little less inconvenient. Good job!
Matrix doesn't encode all data on the server with your current password.
Messages are encrypted through keys according to MEGOLM.
If the user chooses keys can be encrypted using a security key either generated randomly or derived from a password.
I think Signal's derision towards federated protocols should be taken with a grain of salt, but email is genuinely kind of bad on multiple axes. It's difficult to encrypt well, the network is difficult to federate with as an independent user because of anti-spam measures, there's a lot of stuff that providers have kind of stapled on top of it to get around the problem of embedding remote images/resources, message verification, etc... there's just so much duck-taping over problems with the protocol.
> If you skip this part, all e2ee you use is just a security theater.
No, not at all. It's better if you take that step, but skipping it doesn't necessarily mean there are no benefits elsewhere. Proper E2EE does require verification, however, proper E2EE implementations only require additional verification for new devices, movement, etc... verifying something once, even verifying poorly once, is still a lot more secure than verifying it multiple times in a row.
We can get into big debates about the technical side of E2EE, but the short version of that debate is that if E2EE didn't matter, attackers wouldn't be making as much of a big deal about it. This is a good general metric to use when thinking about privacy measures, whether that's sandboxing improvements in iOS, or DNS over HTTPS, or ESNI, or E2EE. If the primary attackers are freaking out about it, there's probably a reason for that. And all of them are freaking out over E2EE so unless you think this is some kind of giant coordinated conspiracy, probably the reason they're freaking out about it is because E2EE does make it harder to monitor people.
If there were a standard for strictly formatted "introductions", which were the only type of message you could send someone unless you were in their address book (and had confirmed public keys out of band?), then spam probably wouldn't be profitable enough to exist.