4 ms·
So one of the things that feels the most damning to me about Signal-like protocols is that you have to inherently trust their server. Consider this paragraph f
by xrisk 6y ago
So one of the things that feels the most damning to me about Signal-like protocols is that you have to inherently trust their server.
Consider this paragraph from the Signal protocol
> ...For example, they may compare public key fingerprints manually, or by scanning a QR code. Methods for doing this are outside the scope of this document.
> If authentication is not performed, the parties receive no cryptographic guarantee as to who they are communicating with.
I have not known anybody that actually does this. If an active attack does happen on somebody, I'm pretty sure they would not notice.
As far as I understand, a decentralized model solves this problem. Don't trust the server? Run your own instance or have some other way of validating clients (via your own PKI infra or similar).
- StavrosK 6y agoYou understand wrong. Nothing solves this problem except verifying fingerprints manually (in person!) or scanning the QR code (again in person!).
- xrisk 6y agoWhy? I trust that my own server is not backdoored (thus reducing the need for off-channel fingerprint verification), I have no such guarantee about Signal's server.
- StavrosK 6y agoBecause you can never be sure that the other person's server or connection (or your connection) aren't being MitMed.
- xrisk 6y agoYes, but I can get all the parties I want to talk to on my own server (if the need arises). About your point the connection itself being MITMed, I don't exactly understand how an active attacker sitting on my connection would undermine the connection? Presumably I have a way to verify the identify of my server. Please do elaborate if I'm missing something. Regardless an interesting thought.
- StavrosK 6y agoIf you're cryptographically checking that the connection you have is to your own server, sure, but I don't know any program that does that sort of thing. I guess if you're using TLS as a transport, the client handles that (if you have a self-signed certificate that you've told the client to trust exclusively).
- xrisk 6y agoYeah, TLS solves that right? So we can agree that a decentralized system effectively removes the need to ever trust any third party system?
- StavrosK 6y agoOf course not. You didn't write all the code yourself, even if you did make your own CA and removed all other CAs from your computer (or did you? Because they can MitM you if you didn't). You still have to trust the people who wrote the code to have done so correctly and non-maliciously, plus the people who wrote the OS, and the computer, and everything. It's a much smaller leap to go from "I trust you to have written the code correctly" to "I also trust you to run the server well" than it is to go from "I don't trust anything" to "I trust all these billions of lines of code I didn't write".
- hiq 6y agoTLS is not decentralized in its common form, you just use a certificate signed by a third-party (CA). So you end up trusting this CA. Why are you willing to trust this CA instead of Signal's server? If you self-sign a certificate instead, how do I check that the signature matches yours? To get a (proper) secure channel, you need at least an authenticated channel first.
- oconnor663 6y agoKeybase solves this problem.
- MAGZine 6y agoThis is the same for any piece of crypto. If you've been provided someone else's encryption keys, and they're not either from the person themselves, or from a trustworthy intermediary, then your channel could be getting intercepted. It's a philosophical/conceptual problem with encryption, not one restricted to signal.
- StavrosK 6y agoIndeed.