Live data from Hacker News

Encrypted messengers: Riot, not Signal, is the future

titus-stahl.de

101–110 of 178 posts

Re: Encrypted messengers: Riot, not Signal, is the future

#101

I have the impression that Signal by now has such a great brand name that mere technical objections won't affect its growth for a very long time.

It's far from perfect, but it's better than any other option for most. Go to the android/apple store, click instlal, start chatting with anyone in your address book that uses it.

Anything else is either much less secure, or much harder to install/use.

Re: Encrypted messengers: Riot, not Signal, is the future

#102
post #94
post #64

Earlier quoted context omitted.

The scenario I'm imagining is that Google and OWS receive NSLs requiring them to push a modified APK that could do nefarious things.

Google can't push a new Signal APK, it's signed by OWS, not google. 3rd parties can download the signal source and compile it. Not sure if there's enough information available to product a bit identical (and thus verifiable binary). I guess a NSL might compel OWS to push a binary specifically for a targetted user. If that's in your threat model you definitely need to take additional steps.

> I guess a NSL might compel OWS to push a binary specifically for a targetted user.

To my (admittedly fairly limited) knowledge, that's something the courts have yet to rule on. They can definitely ask to you give them any data they store about their users (and force you to keep quiet about it), but whether they could force you to develop a backdoor (and ship it to someone) remains to be seen. That's basically what the FBI vs. Apple case was about, which the FBI sadly pulled before courts got to rule on it.

Re: Encrypted messengers: Riot, not Signal, is the future

#103
post #64
post #54

Earlier quoted context omitted.

Sorry, am I missing something? It's my understanding that Signal is ETE encrypted. All an NSL would get you is ciphertext and metadata.

The scenario I'm imagining is that Google and OWS receive NSLs requiring them to push a modified APK that could do nefarious things.

This is a common misconception: NSLs are a legal tool that can be used to extract certain types of information (such as subscriber information and maybe a little bit of transactional information) that a service provider already has stored on their servers [0]. However, they cannot be used to force a service provider to write and deploy code.

[0] NSLs are not magic - https://www.youtube.com/watch?v=YN_qVqgRlx4&t=20m16s

Re: Encrypted messengers: Riot, not Signal, is the future

#104
post #16

I support good alternatives to Signal that also have other goals in mind. Signal's goal is to become basically as mainstream as Whatsapp is, and to get there it needs to make a few compromises for usability's sake. Whatsapp has already backtracked on some major privacy promises, and who's to say it won't backtrack on the end-to-end encryption support eventually, after everyone is baited and switched to it? Or worse,…

Trick to p2p is that generally you have to accept incoming connections for it to work. In signals case that's the signal servers.

Originally skype did this, skype users with a good network connection, good uptime, and who accepted incoming connections could self promote themselves to a supernode. This allowed async messaging for others, helped introduce peers who couldn't talk directly because of IP Masq/NAT etc.

So it's possible that signal could write a small application that could be a supernode. Ideally it could run on a Raspberry Pi, Plug computer, or even any of the numerous opensource routers. What way your battery sensitive phone wouldn't get run down by participating in a DHT or similar, but your raspberry pi could act like your inbox and facilitate incoming and outgoing messages.

Re: Encrypted messengers: Riot, not Signal, is the future

#105
post #95

Earlier quoted context omitted.

It's all well and good to run your own mail server. The biggest problem is 99% of who you send to/receive from will be in one of the big 3 mail servers.

I just had a quick look at a email list I run for a local sporting organization and it looks like the big 3 are less than 50% of addresses. There were a lot of local ISP addresses, businesses and educational organizations.

2 things to consider. A lot of people use more disposable accounts for mailing lists. And a lot of businesses and educational orgs use Google apps or MS's equivalent with their own domain name.

Re: Encrypted messengers: Riot, not Signal, is the future

#106
post #90
post #74

Earlier quoted context omitted.

The most prominent example would be https://en.wikipedia.org/wiki/Jimmy_Hoffa and then the long, storied history of American strike-breaking &c.

Well, either the threat is a private group, then WhatsApp or even Google Hangouts is secure enough. Or the threat is a government, then Signal is not secure enough either, because the US govt can just force Google and OWS to ship modified APKs.

conflating the specific binary instantiation with the general cryptosystem. Regardless, depending on your threat model, you can take increasingly { reasonable | paranoid } precautions like manually compiling and loading Signal, as it's OSS.

edit: "private group" can encompass a lot, especially in other ecosystems like Google and FB. If said "private group" adversary is, say, a prominent and wealthy Silicon Valley businessman and enterprising vampire who collaborates with fascists, then you can see the potential of compromising someone's security by coercing Google or Facebook engineers to run you a Hadoop query or conditionally inject malicious JS.

Re: Encrypted messengers: Riot, not Signal, is the future

#107

Earlier quoted context omitted.

PGP can be used to encrypt at the ends, in which case it is end-to-end encryption. So that's not a different feature. Care to share what you mean by PGP leaks a lot of metadata? You might be right, I'm just not aware of such details.

None of the email headers are protected in any way for a PGP-encrypted email. All the same metadata is that collected from plaintext email is still available on "encrypted" email. You literally can only protect the body of the email. In surveillance, that is often the least interesting or valuable piece of information.

Signal does not solve the meta data problem either. Discovery is an open problem [0]. Signal messages leak the recipient, which is the most important meta data. You would have to use Tor/Onion routing, which is inefficient.

[0] https://whispersystems.org/blog/contact-discovery/

Re: Encrypted messengers: Riot, not Signal, is the future

#108

Earlier quoted context omitted.

End-to-end encryption. Even if you encrypt email with PGP, which no one has come up with a satisfactorily easy interface for, it leaks a lot of metadata. Riot gives essentially the same privacy guarantees as Signal, but with email-like federation.

PGP can be used to encrypt at the ends, in which case it is end-to-end encryption. So that's not a different feature. Care to share what you mean by PGP leaks a lot of metadata? You might be right, I'm just not aware of such details.

If two users PGP email to each other, anyone who's monitoring either mail server or the network in between can tell A) when they are talking, B) who they are talking to, C) what the subject of the email is, and D) how big the email is.

With signal this is much harder, for instance google/apple do not know who you are chatting to. They also don't handle the encrypted message transport/delivery.

Re: Encrypted messengers: Riot, not Signal, is the future

#109
post #50

Nothing against Signal, But I sure hope matrix-based platforms and clients (like riot.im) keeping growing. The folks who work on both matrix.org and riot.im have done so much work in such a short time...not just in developing the protocol/server/apps...but also in education. They really have helped people like me to setup our own little home servers (i.e. private networks)...which ultimately helps the entire federate…

> Signal - while certainly can be setup/hosted by anyone else separate of OpenWhisper - leaves some to be desired in the actual self-implementation details; just not enough tutorials out there. That is the problem at hand, that Signal _does_not_federate_. You could modify your Signal app to connect to your own server, but then you would not be able to talk to anybody else. For the record I prefer usability and walled…

The Signal server software _does_ federate. It has had federation support since the first commit in the git history. Whisper Systems' server federated with Cyanogen's server for a while. Moxie has said it was a disaster and that is part of why the official Signal server won't federate.

You can, right now, run your own server and get other people to also run their own servers. Fork the Signal app, modify to ask for a server to use, and try and get people to use it instead of (or as well as) Signal itself.

Re: Encrypted messengers: Riot, not Signal, is the future

#110

I believe Riot is the future not because of its security(its attention to such is a great, great bonus) but because it's positioned itself so well as a credible successor to IRC.

And an open replacement for Slack.

Yes. I don't see Signal and Matrix in direct competition, just like WhatsApp and Slack are not in direct competition. The technology is very similar (main difference seems to be the size of chat rooms), but the use case and marketing is very different. Signal/WhatsApp is for casual mobile texting, while Matrix/Slack is for working.
Post reply on HN