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 be made to work for asynchronous secure group messaging. You can get forward and future security with it. It can interoperate with existing email addresses. All of that can be made to work.
But it is the case. Email won't be a secure group communication system. The reason for that is that email is federated and thus permanently mired in the lowest common denominator of mainstream email clients.
I think reasonable people can disagree about whether it's tractable to create a federated secure group messaging system with what we know right now. But I do not think it's reasonable to suggest that the concern (federation = lowest common denominator security) is invalid. And that's what this piece does.
My assumption with Matrix is that if some fatal flaw is found in the Olm/Megolm E2E implementations, we'll work with the major clients/bots/etc to implement a (if necessary) incompatible fix... and fork the community. Folks stuck on old insecure conversations will be isolated and shamed into upgrading - much like insecure HTTPS algorithms get killed off by pressure from browser vendors.
Yes, this process takes longer than a centralised solution which can flip the switch serverside and then worry only about upgrading all the apps, but in exchange you get freedom, as well as some level of security.
Obviously, email is the best case in point. There's been a decade and a half of concerted effort to get some baseline level of crypto security for email, and all of it has run aground on the installed base of dumb email clients.
To believe we should be cavalier about the risk of this happening again is to assert that we know enough now not only about how to design a secure group messaging system, but also how to safely implement it, that we should freeze the current state of the art in amber by standardizing it.
Personally, I can resolve this for myself quickly. I log into my Linux server, type "man 4 random", see that we can't even properly standardize the secure way to generate a random number, and quickly conclude that I'd rather use a single system that Moxie and Trevor are actively designing and evolving than adopt the consensus protocol of a menagerie of different unrelated messaging projects.
This level of oligopoly would not be tolerable to those who want to federate Signal-like apps. The whole point is to make it practical to use a small operator that's not such an easy target for one government's intervention (eg an NSL). But that ecosystem looks much more like email than web browsing - diverse, but fragmented, and impossible to upgrade in this way.
"Riot’s encryption is not yet fully stable and, more importantly, it is not yet enabled by default in chats (you have to enable it manually). This will be changed in the future, but makes it more likely for users to make mistakes until then."
Users "make mistakes"? By using the defaults? I consider it a mistake to promote it to the users with such defaults. A "secure" product which "doesn't encrypt by default"? And "it's not stable"? What does that mean? The encryption either works or not. "Almost working" is still "not working."
Then please don't write
"An alternative to Signal is Riot." It is not. As far as I understand it just "could once be an alternative."
But based on the responses I've received here to my questions about Riot, it's promising: according to them, I will be able to set up my own network of people (e.g. just my family) with which I'd like to communicate. Yay! (thanks to mxuribe and NoGravitas for the answers)
Encryption currently works on Riot Web, iOS and Android, certain bugs excluded - but it's missing a lot of UX work. (Among other things, you have to manually verify each and every device the people you talk to use, there's no way for them to say "these are all my devices, if you trust me, you trust them" yet. You also lose chat history at present if you switch devices or log out.) If you're able to work around the UX, the underlying protocol is fine and has been audited, with certain tradeoffs discussed in the report.
I think the intention of Titus' article is to comment on where things are going in future... hence the title: "Why Riot (and not Signal) is the future".
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...
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-garden-security instead of federation, even though it hurts to admit as a long time FOSS user.
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.
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.
I'm not part of the Matrix or Riot teams, but I'm convinced enough that Matrix is a great way forward for modern messaging. I started my own Matrix homeserver (as well as other Matrix libraries, eventually to include a Matrix client) written in Rust. If you're interested in Matrix, Rust, or both, I encourage you to get involved! https://www.ruma.io/
[1] https://matrix.org/blog/2016/11/21/matrixs-olm-end-to-end-en...
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.
You can run your own private Signal service with OpenWhisperSystems' tools [1].
It's also worth noting that Signal - as a protocol - could easily be federated. (As others have mentioned, Moxie has chimed in on why the app is centralized [2]).
If confederated messaging is important, why not use the existing Signal protocol implementations, (including the X3DH key exchange, ratcheting protocol, etc), which is all F/LOSS, and has already been widely reviewed (as the article mentions)?
[1] https://github.com/WhisperSystems/libsignal-service-java
[2] https://whispersystems.org/blog/the-ecosystem-is-moving/
A distinction without a difference. I use Signal because people use Signal. People do not use 'the Signal service'. They use OWS's app and OWS's servers and moxie has explained he will not federate.
The fact that OWS goes to all the effort of creating this excellent protocol, and then insists on only deploying it to insecure devices (with direct-memory-access baseband radios) baffles me, but I hope that things move in a saner direction with time.
The biggest benefit I think OWS has provided is the ability for other platforms (e.g. Whatsapp) to use their protocols. I daydream about a day when all these competing messaging services realize they would stand to gain a lot by federating, but I know it won't happen in my lifetime.
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?
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.))
* https://matrix.org/docs/guides/faq.html#i-installed-riot-via...
>I installed Riot via F-Droid, why is it draining my battery?
>The F-Droid release of Riot does not use Google Cloud Messaging. This allows users that do not have or want Google Services installed to use Riot.
>The drawback is that Riot has to pull for new messages, which can drain your battery. To counter this, you can change the delay between polls in the settings. Higher delay means better battery life (but may delay receiving messages). You can also disable the background sync entirely (which means that you won’t get any notifications at all).
>If you don’t mind using Google Services, you might be better off installing the Google Play store version.
Can anyone justify why they are necessary?
http://stackoverflow.com/questions/6578051/what-is-an-intent...
Edit: Reading your link now, as I didn't see it before I made my comment. Was that added in as an edit?
https://support.whispersystems.org/hc/en-us/articles/2125358...
> In addition, people are writing alternative clients to access the Matrix/Riot network, implementing their favorite features and workflows. As users can vote with their feet for their own interests and choose providers and apps of their liking
Can I run my own network which is not part of other networks (i.e. not "federated")? Can I tell somebody "call with your Riot client 'acqq at server ip nnnnnn' and we can talk"?
1. You and your friend both use the riot (actually matrix.org) server/network and you both choose any matrix-relevant client (doesn't even have to be the riot client), but only make use of private rooms on that server. This avoids any system setup overhead whatsoever...But the private room(s) that you create would still on a server that is not controlled by you.
2. You can of course setup and run your own little private network; on your own domain name/IP address. This is what I do with my family; and only my wife, and daughter have access (I've even disabled registration). I have not yet connected my little network to the greater matrix network...For 2 reasons: I wanted to beta test this internally so I could leearn; Also, i wanted to be sure my family does not get exposed to any spam (if there is any that is).
Good luck; cheers!
Also, how puringpanda's question fits to your claim?
In both cases you can start chatting with any signal user in your address book in a minute or so, no expertise (other than using an app store) needed.
Tracked down the http://riot.im, it has a "try now button", that just scrolls you to the top. Didn't see any way to actually try it.
I tried the ubuntu app, they make you manually create your own /etc/apt/sources.list.d, from only the base URL. Then you have to know how to add the pgp key. Then apt-get update, apt-get install riot-web. Then... nothing. Nothing called riot or riot-web in the path. Thought maybe there would be a daemon running (it's called riot-web afterall). Can't find any processes running, nothing listening on a new socket. I track down /var/lib/dpkg/info/riot-web.list, look through the list and find they dropped a dir in /opt. So I run /opt/Riot/riot-web.
It worked, not exactly the kind of thing I'd ask random friends/family/colleagues to do though.
In the meantime, it's not like you can migrate your Signal, Telegram, iMessage, or even Gmail/Hotmail accounts. I think Matrix needs a few more client/server implementations before the spec can't truly be set in stone.
MSISDN (phone number) identifiers landed on the backend this afternoon; implementation in the Riot clients will be coming very shortly.
There are broadly two ways of solving it:
1. have a naive implementation where users can configure their accounts to replicate between sets of servers, and clients have primary and fallback servers they can talk to if the primary isn't available.
2. switch to a p2p model where each device has its own server, and so account data is automatically replicated across multiple devices. This has a host of other advantages too (e.g. you can own your data without running your own server; you can adopt metadata-protecting federation transports; you can still use all the existing apps today as the client-server API remains the same; you can still bridge with the Matrix network of today).
#2 is obviously way more work, and is effectively rewriting the federation side of Matrix. However, Matrix is designed to evolve and we're not ruling this out from happening at some point. Meanwhile #1 is more likely to land in the nearer future. We haven't got it scheduled in yet, but it's very much on our minds!
I just hope matrix ends up working better than xmpp.
EDIT: Thank you for the responses! It pretty much confirms what I thought; Apple _could_ access your communication (either through keylogging at the OS level or backdooring Signal) but this solution is better than everyone use plain text communication. I personally would not trust Apple with my life if I needed that level of protection but maybe that's not the main use case for Signal.
We have to trust someone, eventually. This is especially true for the 99% of the population who doesn't have the skill to compile source themselves (nor should they have to).
http://wiki.c2.com/?TheKenThompsonHack
Ken describes how he injected a virus into a compiler. Not only did his compiler know it was compiling the login function and inject a backdoor, but it also knew when it was compiling itself and injected the backdoor generator into the compiler it was creating. The source code for the compiler thereafter contains no evidence of either virus.
That's the exact reason why package signing is decentralized in the Android ecosystem. All apps in the Play Store are signed by their developers.
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"? What if MS/Apple backdoor the entire network stack, including the physical and data link layers? etc. etc.
Which is to say, security-minded users should strive to trust as few parties as possible, but since at the end of the day you have to trust somebody if you don't trust Apple the only really secure move would be to not use iOS devices at all.
But if the user has another OS, then you can believe those who get control of that OS/device can read your messages to that user and record your calls to him/her.
It's turtles all the way around. The more communication the less can you expect to remain "private." Come to think, it is so without computers too.
These aren't high priority problems right now for mass surveillance, as we have people using plain text chat. If you're expecting a wealthy adversary to directly target you, then the only safe move is to avoid technology.
Unless every single part of your platform is open and you build it yourself. But then make sure the parts you use to build it aren't tampered with.
I think somewhere along the conclusion of that train of thought you'll need to build a fab to make sure there aren't silicon level backdoors in your hardware.
"According to Galen, any books found on ships that came into port were taken to the library, and were listed as 'books of the ships'. Official scribes then copied these writings; the originals were kept in the library, and the copies delivered to the owners."
https://en.wikipedia.org/wiki/Library_of_Alexandria
Sounds like Napster, yes? Think about how much harder it would be for Congress to pass laws shutting down the digital equivalent to a library sharing the world's music.
But no. We get names like Riot, and Felony (https://github.com/henryboldi/felony). Congress sends you a "Thank you" every time you put an edgy name on something disruptive.
Is this correct? I've never bothered looking it up, but Signal was connecting me with people in my phone's address-book.
On Matrix/Riot, userids are federated in the same way as emails. So when you change providers, your userid changes, but your contacts' stay the same, and you can still connect with them from your new provider.
Anything else is either much less secure, or much harder to install/use.
Matrix is a generalized protocol for decentralized and federated communications; it's agnostic to the application layer provided by Riot. Something Matrix doesn't have, but is on the issue backlog, is support for email-esque thread contexts. [0]
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.
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, it could start to decrypt E2E communications in secret for governments.
So we need a "mainstream" alternative that's actually trustworthy and can at least protect the security of the communications, if not the relationships between users.
However, I support applications that aim to offer even better privacy and security compared to Signal, that are aimed at more opsec-sensitive targets, such as journalists. Signal may be the best tool journalists have right now, but it's probably not the best one they could have, as it doesn't do a great job at protecting sources. Perhaps Ricochet or the Tor Messenger may be better for that.
What I'm worried about though is that even if these apps offer better security/privacy features, the various federated applications that use an E2EE protocol may not have too much of a security mindset. For instance, sure, Riot may adopt a better protocol, but is Riot itself using all modern security best practices? Can we trust the Riot developers just as much as we do the OWS developers? etc
Finally, I'd much rather see Signal become a P2P application than a federated one, if that would even be possible.
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.
