Live data from Hacker News

Encrypted messengers: Riot, not Signal, is the future

titus-stahl.de

81–90 of 178 posts

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

#81
post #9

This topic has been beaten to death on HN over the last year (other people can provide links to discussions, with Moxie participating). I think something worth keeping in mind is that almost everyone who works in secure messaging agrees on one thing: that electronic mail is not the future of secure communication. There's no fundamental reason why that should be the case. The store-and-forward model used by SMTP could…

I think you make good points, but I think email works well as a secure group communication system for private organizations, and may improve over time as a federated one.

One important benefit of email is that you're not reliant on any single provider for your communication. Slack and Signal and systems like them are provided by single companies, and the continued function of those systems depends on the companies. Your long-term happiness with those systems could be influenced by how those companies interact with foreign or domestic governments' requests for surveillance, for censorship, etc. What will happen if one of these companies is ordered by a government to, like Lavabit, backdoor their system, or defeat the encryption on a device like Apple? Perhaps it will happen through secret court order and we'll never know, or perhaps the company will decide to shut down like Lavabit - as a user both are bad options.

With email, you can host your own email server, and take the fate of your group's secure communication into your own hands. For anyone to get your data they'll need to come after your devices directly; they can't just send a court order somewhere to obtain information about your communication - not even metadata. Although systems like Signal may not have the preexisting ability to eavesdrop on the substance of your communication centrally, they may be able to eavesdrop on your metadata and contact list, and it's possible that they or any vendor involved in app distribution such as app stores, OS vendors, telecom providers, device manufacturers, could be ordered to collect your data or metadata, or even build and deploy a backdoor.

As far as security, I think email is adequately secure for private group communication for most purposes. Many of us do rely on email for just that purpose within our organizations (e.g. companies). If your organization has a central mail server that authenticates its members, then you can get to a pretty good state fairly easily. Microsoft Exchange and Active Directory are an example of this. Gmail for business. Postfix with an LDAP server.

All modern email clients communicate with mail servers over TLS and will authenticate the server, just like a browser authenticates an HTTPS website. Modern email servers authenticate the client. What important security property do we get from the alternatives that we don't get from email? End-to-end encryption is the only one that occurs to me, and in an organization where we can trust our central server that's OK not to have. I suppose this is an easier proposition for companies than for loose groups of people organizing over the Internet. If you use a hosted email provider then obviously you must trust them, but self-hosted options are available and realistic (Exchange, Postfix).

Now, granted, what I am describing is a private organization rather than a federation. What's really cool though about email is that we get secure group communication within the organization, and also federated communication to other organizations on the Internet.

The security story for communication between organizations is weak, I'll grant. The primary weak link I see is not end user clients, but the communication between servers. Specifically, the lack of support in standards and servers for authentication of receiver by the sender, and for the receiver to declare that all incoming connections should come over TLS with a path-validated certificate. There is an Internet-Draft out for this called SMTP Strict Transport Security [1], but I don't know where it stands as far as support and adoption. DMARC+DKIM already provides authentication of the sender's organization by the receiver, and for declaring that all outbound messages from the sender's organization must carry a signature to be valid.

There's a fair amount of surface area in this model though: in particular, both end users and their mail servers need to be trusted. If in your communication between two organizations, you are willing to trust both organizations' central mail servers, then basic email setups will get you to a pretty good situation.

Some colleagues have recently made the case to me that S/MIME could fill in these gaps, and mentioned that folks in the industry are working to flesh out support for it. There are a number of problems to solve to make S/MIME practical, but with the will of a few major players I think we could get there. Some pieces that are missing include first-class client support, a key exchange/discovery/revocation system, and a scalable certificate issuance system. But solving S/MIME is only necessary to get to end-to-end encryption, and for most purposes it's practical to trust your organization's and partner organizations' email servers.

Even if email is not the secure group communication of choice, it's still used for a lot of secure communication and is worth improving IMO. I'm glad that Google and other have been investing in this: https://blog.google/products/gmail/making-email-safer-for-yo...

[1] https://tools.ietf.org/html/draft-margolis-smtp-sts-00

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

#82
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 does somewhat break Signal's security model..

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

#83
post #8
post #2

Are there any plans to do a security audit on Riot? The useful report by NCC [1] looks at libolm (which implements the end-to-end encryption) but of course that's only part of the whole product. [1] https://matrix.org/blog/2016/11/21/matrixs-olm-end-to-end-en...

Note that that report explains that the Double Ratchet E2E algorithm is used in Matrix, in large part because of the Open Whisper Systems implementation in Signal and subsequent licensing. So we're looking at an apples-to-apples comparison, at least with respect to this one piece.

Yes, it seems like a good choice of algorithm. And it seems like the implementation is also decent - they looked at that as well. It's a useful report and kudos to Open Technology Fund for funding it and to Matrix for making it public!

Still, this is only one piece of the overall security of Riot, so I'm still interested in knowing if there's any work going on looking at the bigger picture.

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

#84
post #15

A question I've had about Signal is what is stopping Apple from modifying and rebuilding the source with a backdoor in it? Is this technically possible (seems like it would be since they control distribution of the binary to devices)? The article is correct in stating that web based chat is inherently insecure but it seems all iOS apps are also inherently insecure. I'm by no means an expert though so would love to he…

With such a system, you must end up trusting a certain entity; it's turtles all the way down otherwise. No system is independently secure. Similar questions include: What if a CA is compromised? What if Apple/MS bundles unwanted certs with the OS? What if Intel/AMD biases the on-die hardware RNG or other hardware crypto primitives? What if Apple/MS bundles a backdoored compiler a la "Reflections on Trusting Trust"? W…

Does Signal support reproducible builds, at least? Real question, I don't know.

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

#85
post #6

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.

I wonder if the name of Riot will be a hindrance for widespread adoption. Most people don't like riots.

Yeah, it's a bad name. Don't think I could get my parents or colleagues to use it.

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

#86
After a recent discussion of the issues with XMPP on mobile, some obvious questions:

1. How well does Riot deal with changing network connections? Does it have problems when a mobile device switches between, say, WiFi and 4G? How well does it deal with a complete loss of connectivity?

2. How well does Riot deal with power management on mobile devices? Can it spend time in the background while getting message alerts while not running down the battery?

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

#87

Earlier quoted context omitted.

MicroG does not implement GCM.

MicroG does implement the GCM client! I've been getting push notifications through that thing for several months.

No, it implements one half of it.

Signal still has to be linked with a proprietary binary, which contains lots of tracking code.

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

#88
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…

I think signal made the right decisions raising the bar for encryption while maintaining extreme ease of use. Random Joe can click on it on the app store and chat with anyone in his addressbook that runs signal within a minute or so, with no expertise whatsoever.

However I see no reason why a similar p2p app couldn't manage similar without a central server. Trick is cell phones (at least on WAN) do not accept incoming connection. Additionally apple/android push aren't good for a p2p transport.

However adding supernodes (like the original skype) that could run on raspberry pi's, opensource routers, and similar embedded devices might just bright the gap. After all the cpu, bandwidth, and memory needs for instant messaging are pretty modest, even for many people sharing a raspberry pi.

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

#89

After a recent discussion of the issues with XMPP on mobile, some obvious questions: 1. How well does Riot deal with changing network connections? Does it have problems when a mobile device switches between, say, WiFi and 4G? How well does it deal with a complete loss of connectivity? 2. How well does Riot deal with power management on mobile devices? Can it spend time in the background while getting message alerts w…

It's really good. I'll vouch for it as someone who has been using the mobile apps on both platforms, and the web application(s) on the desktop for over a year now. They're great. Battery isn't a problem; messages NEVER get lost.

I actually came to matrix after trying to write an XMPP client, believe it or not. The matrix protocol is WAY better equipped for the future than XMPP is: it simply has the core designs necessary to make it federate well and do message sync without losses. (XMPP doesn't. (Unless you count a half-dozen XEPs, none of which are reliably implemented in all clients. But we're getting increasingly parenthetical here; by comparison, matrix Just Works.))

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

#90
post #74

Earlier quoted context omitted.

Who's the likely threat to union organisers? I suspect a pair-locked iPhone with Signal or Whatsapp would be more than secure enough.

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.

Post reply on HN