Signal is useless for the only people it could be useful for. Most people don't need better-than-TLS security, and for those people Facebook Messenger or any number of other options are perfectly adequate. The people who do need better security are precisely the same people who a) can't afford to use phone numbers as IDs, not even burner phones, when they mean a hostile government who captures one person can immediately start tracing the location of all their contacts and b) can't afford to trust an unaudited server run by a company that could relatively easily be forced to cooperate with a hostile government (particularly when the encryption protocol uses a novel semi-TOFU construct that makes attacks a lot more plausible when the server is cooperating).
There are threat models where TLS is good enough. There are (mostly quite paranoid) threat models where GPG, for all its usability issues, makes sense. There is no threat model where Signal makes sense.
Finally, GPG's usability issues are contingent and fixable. Probably in GPG-the-program, and certainly without abandoning OpenPGP-the-protocol. Throw a bit of money at it, get an actual UX designer to spend a couple of months on a nice UI, and who knows where that would take us? Whereas Signals flaws are there by design.
I agree with the literal interpretation of this statement; most Signal users don't need that level of security. But many users want a level of security that makes it much harder for their government to intercept their messages, and I believe Signal is better for that than Facebook Messenger. I think you could make a convincing argument that Whisper could be strong-armed by the US government, but for me it seems unlikely that they could be compelled to install a back door by Turkey, Russia, China, or some other such illiberal regime (at least, less likely than Google/Facebook).
For example, see https://www.cultofmac.com/426440/whatsapp-wins-encryption-vi..., where WhatsApp (which uses the Signal protocol) was not able/willing to hand over message data to a Brazilian court. That is the feature that Signal users are choosing that FB Messenger does not have.
> I think you could make a convincing argument that Whisper could be strong-armed by the US government, but for me it seems unlikely that they could be compelled to install a back door by Turkey, Russia, China, or some other such illiberal regime (at least, less likely than Google/Facebook).
> For example, see https://www.cultofmac.com/426440/whatsapp-wins-encryption-vi..., where WhatsApp (which uses the Signal protocol) was not able/willing to hand over message data to a Brazilian court. That is the feature that Signal users are choosing that FB Messenger does not have.
Actually I'd say it's a feature that FB Messenger has and Signal doesn't, since the salient fact is that Facebook inc. refused to turn over private messages. Facebook has the resources to play hardball with governments; they could afford to have their service shut off for 3 days in Brazil. Does Signal have that kind of warchest?
I'm not sure if they need a warchest; my point was that Whisper don't have a presence in Brazil and so they probably couldn't be compelled to do anything by the government there, whereas FB has employees and execs there, and directly do business there, so there are all sorts of levers that the Brazilian government can (and have tried to) pull to compel them. Frankly I suspect it would be good press for Moxie if he had an arrest warrant outstanding for not turning over customer messages to a government.
Also note that FB Messenger doesn't have e2e encryption, and I'm fairly sure that FB would hand over any data that they do have to any government that asked. They certainly hand such information over to the NSA.
The reason I brought WhatsApp in as an example was because even Facebook, a company well-known for sharing its users' data with government security agencies, was not able to share Signal messages. That is fairly strong evidence that their protocol implementation does not have a secret backdoor; if there was such a backdoor, there would be no story of an FB exec in jail, since FB would have quietly handed over the messages that Brazil asked for.
To add to this, I believe Signal is open source and has reproducible builds so its chances of getting away with mischief on a large scale are much lower than Facebook's / WhatsApp's. Even if you (weirdly IMO) think Whisper Systems is less trustworthy than Facebook.
As usual, I'll add that GPG was Snowden's tool of choice because it was one of only things hampering mass collection at NSA. If it stops NSA, it can probably handle other attackers that don't have a budget of $200+ million a year for bypassing security. Definitely worthwhile to start with a known-good tool to do UI or other improvements.
Moxie's point was that GPG doesn't hamper mass collection at NSA because nobody uses it! GPG is definitely more secure than Signal. Signal has probably encrypted more messages than GPG, despite being around for only a fraction of the time.
Well, he's definitely discouraging using it in the post. He also strawmans the usability with his power, flexibility, and huge man page argument. Here's how easy it is to use after you swap keys with someone:
1. Type message in a text file.
2. Use one command to encrypt that.
3. Send the encrypted file to the other party using what medium you deem convenient or necessary.
4. Other person uses one command to decrypt it.
That's all. There's people in police states that communicate with me regularly with that method. Non-technical people I've shown find it simple but tedious. So, that's what we should recommend if we want to avoid the complexity. If he's being fair, that's what Moxie should be comparing any new solution against when assessing how easy it can be (or isn't) to use GPG.
Further, we can either modify the program and/or put a front end in to remove what little complexity it has. Especially knock out the ridiculous delay on randomness, pick good ciphers by default, and eliminate putting the sender/receiver full name in there. Just click a person's name for the latter. I'd have already done the stuff myself if I could stomach learning C++ plus whatever the author's style is. Maybe add SaferCPlusPlus or something like that to further reduce likelihood of code injection. If preventing injection and using isolation mechanisms, one could just freeze the forked codebase not adding anything else to it past protocol-level fixes that are required over time for just the features one uses to encrypt or decrypt a text file. Then, slowly rewrite and/or subtract pieces from it to make it simpler over time.
That should've been the response a long time ago. It would've saved cryptographers and security professionals that know C++ a lot of criticism. They could've just posted a link to the simplified program I just described that's a two-step process for each party when sending messages.
I intentionally left out key exchange to see if anyone would ignore my points on ease of messaging to focus on something else. Nice taking the bait. ;) Yes, we can do a front end improvement on that part, too.
What you think about my greater claim that one can use it effectively exchanging text files after learning a handful of commands? It's more important because it refutes the GPG is too hard argument.
Not that I use GPG, but that is exactly how I would. write text, encrypt, paste base64 nonsense into email, verify I'm sending nonsense, send. So many failures result from trying to make things "easy" and so you get people full quoting in plaintext, cc to the wrong person (transparently encrypted with their key, so they can read it, etc.).
I disagree that GPG is easy, and I think telling people to use it will mean they screw it up. But I also think efforts to make it easier are likely to automate failure.
Why would people paste the text into the composer rather than attaching the file?
> I disagree that GPG is easy, and I think telling people to use it will mean they screw it up.
We can tell people to zip up files (possibly encrypting them with a password) and attach them to an email, but I've never heard anyone argue that telling people to do that would mean that they would screw it up. What makes GPG different (other than the public/private key thing)?
Maybe one way to introduce people to GPG would be to have them use symmetric encryption at first to send messages and files (as an alternative to a password protected zip or other archive format).
Then tell them that if they create keypairs, they only need to give the other person their public key and the other person does not need to tell them the password of the day anymore to securely send the message.
Note that Im telling them to attach a text file they encrypted rather than mess with encodings and stuff. They just encrypt a file, attach it, done. Alternatively, the front end has a built in editor that outputs an encrypted file with the name they pick.
Far as failure automation, you could say that about anything. Ive reduced the problem of communicating to two steps. Most things aren't that easy centralized or decentralized.
The closed and centralized nature of their backend in combination with them being a very small team makes them especially vulnerable to being compromised.
Are we sure no single employee can be pressured by the government they operate under or the company as a whole?
Are we sure none of them are compromised and perhaps don't even know it?
Who holds the signing keys for the mobile apps? How have they been handled?
Are their internal CI servers secure? Do they do reproducible builds? How can we verify no last minute changes were slipped in by an employee or an NSA operative that has broken into their systems?
Considering Moxie has been openly opposed to third parties wanting to do externally verified reproducible builds such as f-droid... I simply can't have much confidence here.
On their website signal says they "...design open protocols, develop Open Source software, and give it away for free."
In spite of this, they do not allow spinning up your own clients and servers to validate their work without forking their client and re-implementing portions of their server.
I would challenge that we should not run from a situation where we have too much trust in one entity only to put complete trust in another.
I don't totally understand why you can't just swap public keys and just send GPG-encrypted messages.
I also don't fully understand why Signal needs to be centralized. What if it were a generic chat server that could, optionally, receive messages via SMS?
> An open source infrastructure for a centralized network now provides almost the same level of control as federated protocols, without giving up the ability to adapt. If a centralized provider with an open source infrastructure ever makes horrible changes, those that disagree have the software they need to run their own alternative instead. It may not be as beautiful as federation, but at this point it seems that it will have to do.
That's fair, but it still entails additional trust in the host. On, e.g. Matrix, I can run my own homeserver, so if something evil happens on another homeserver it's not really a big deal for me, unless there's a protocol vulnerability that allows them to mess with my own homeserver. Whereas on Signal, I might not even know if the centralized host has been compromised, and then as a casual user I have to wait around until a non-compromised host has appeared.
I get it, but I don't really get it. The argument that "federation does freeze protocols in time" doens't make a ton of sense to me. Just look at Bitcoin: people want to keep participating, so they upgrade. It's probably easier to get a bunch of scattered servers to upgrade than a few centralized ones.
Absolutely, it's a trade-off, and is probably strictly worse for power users.
As a counterpoint to Bitcoin (which is still quite a young and under-adopted protocol), consider how hard it has proven to upgrade the IP protocol from version 4 to 6 (20 years and still not complete?)
Ip works at a much deeper level which is why it's harder to change. Everything uses ip, including hardware and software that's no longer getting updated but is still in use.
Which supports my point -- the quote "federation does freeze protocols in time" was being questioned, and IPv4 is the textbook example of a federated protocol that was frozen in time.
I have a lot of respect for moxie helping create the signal protocol. I think the problem is many extend that respect to take his word as gospel for everything else, including stuff like this that is total nonsense.
1) We -can't- just take the backend of signal and deploy our own because all clients are hardcoded to use Signal central servers. You currently -must- trust central Signal servers to not store metadata and the government their servers live under. You totally can have end to end encryption -and- have federation as Matrix.org and Riot.im have well demonstrated.
2) There is no reason at all you need to be centralized to encrypt SMS via the signal protocol. The Silence project has already demonstrated this https://silence.im/
tbf, decentralisation + e2e crypto is hard, as we've discovered at Matrix & Riot. You can have some wonderfully nasty situations if you don't know which devices (or even users) are in a given room, because the room is by definition not globally consistent due to being decentralised. Although we're doggedly working through addressing all the edge cases which result; my guess is that it's about 6x more work than the equivalent centralised service.
If you like minimalism, try trojita (http://trojita.flaska.net/). It's basically an IMAP explorer with lots of rfcs implemented and gpg support. Takes 1 minute to configure. It might have some rough edges, but I always find its lightness welcome when I'm using other bloated apps.
It seems nice, but for some reason I can only set a global username for imap, rather than a per-email one. How can I log in to multiple gmail imap accounts?
There are threat models where TLS is good enough. There are (mostly quite paranoid) threat models where GPG, for all its usability issues, makes sense. There is no threat model where Signal makes sense.
Finally, GPG's usability issues are contingent and fixable. Probably in GPG-the-program, and certainly without abandoning OpenPGP-the-protocol. Throw a bit of money at it, get an actual UX designer to spend a couple of months on a nice UI, and who knows where that would take us? Whereas Signals flaws are there by design.