Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Encrypted messengers: Riot, not Signal, is the future

titus-stahl.de

Post reply on HN
Print view View original

151–160 of 178 posts

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

#151

Post by Arathorn »

uabstraction wrote: post #60
PurgingPanda wrote: post #17

Does anyone know if they are planning to add a way to change home server. If they take your domain (With your Matrix server on it), you have no way of communicating with other people over riot anymore.

There are plans to support 3rd party identification (such as an E-Mail address or a phone number) and use that as a basis for looking up users across the network, but I don't think it is currently useable. Account migration was brought up recently in the chat room, but it is not defined anywhere in the spec or reference implementations AFAIK. I agree that these are both important features, but I wouldn't worry too mu…

Email identifiers work fine today, actually. They don't solve the problem of migrating accounts, but at least they abstract the discovery process away, as you say.

MSISDN (phone number) identifiers landed on the backend this afternoon; implementation in the Riot clients will be coming very shortly.

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

#152

Post by Arathorn »

NoGravitas wrote: post #55
buzzybee wrote: post #20

Earlier quoted context omitted.

Riot is most comparable to Slack or Discord. It has chat rooms. It supports voice, image posts, file transfer, etc. It stores conversation history. You can private message people. 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…

I would love to see an email - like application implemented on top of Matrix.

we're working on it :>

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

#153

Post by kuschku »

ajamesm wrote: post #106
kuschku wrote: post #90

Earlier quoted context omitted.

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 bus…

> like manually compiling and loading Signal, as it's OSS.

Except, I’d have to modify the code, as the current version depends on Google’s proprietary libs, which I can’t inspect. And I lose half of the functionality, as RedPhone is also proprietary.

> by coercing Google or Facebook engineers to run you a Hadoop query or conditionally inject malicious JS.

The same can be done by coercing OWS engineers to backdoor their services.

And in any case, Signal can start collecting metadata any minute now, and there’s nothing we could do against it.

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

#154

Post by Arathorn »

meredydd wrote: post #78
zimbatm wrote: post #33

Earlier quoted context omitted.

If browsers are able to deprecate old encryption layers I don't see a reason why matrix client wouldn't be able to do the same. And as with browsers, if the clients or servers don't get upgraded then at some point they will stop working.

That is only possible at all because web browsers are an oligopoly. There are only four organisations whose opinions matter, so they can coordinate to make breaking changes. (Even so, SHA1 deprecation is happening 1000x slower than, say, Whatsapp's rollout of E2E encryption.) 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…

In the end it's a governance problem. If you create an ecosystem which sets a precedent of taking security seriously and thoroughly excommunicating insecure clients, netsplitting them out of the mainstream, then I think you'd see a lot more interest in client vendors and users routing around obsolescence and upgrading to whatever the current best practices are. This is particularly nice if the protocol is designed to let you enforce this, by ratcheting up to new versions.

Email never had this, and it shows. SHA-1 in HTTPS is a kinda intermediary example; browser and server vendors have been petrified to break legacy systems and generally not accorded that much priority to security updates. In Matrix, we hope to avoid this by setting a precedent that if Olm/Megolm is found broken tomorrow, we'd work with the major client authors to upgrade them, patching their clients ourselves if we have to, or providing a localhost shim or whatever, and then take the biggest community anchor points (e.g. #matrix:matrix.org) and throw the switch to the new protocol, and make it abundantly clear that folks on old clients have been left out in the cold for security reasons and need to get upgraded immediately. If you're a big enterprise with a private deployment who doesn't want to upgrade rapidly, that's fine. But the societal pressure will enormously be to get with the program and upgrade. Let's see how well that works though - we haven't really had to make any backwards incompatible changes yet since we started in Sep 2014.

(p.s. hi! :D)

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

#155

Post by vertex-four »

acqq wrote: post #141
vertex-four wrote: post #115

Earlier quoted context omitted.

Right now, in practice, Matrix is "a better IRC". It provides bouncer-like functionality by default, federation across the whole network so you only have one identity vs having to register with each server on which there's a community you want to talk to, file sharing, voice/video chat, proper message formatting, and more. Encryption currently works on Riot Web, iOS and Android, certain bugs excluded - but it's missi…

Thank you. This is exactly what I wanted to read: clear explanation what works and surely not "it's not stable." What are the current encryption-related bugs, that is, what is their worst consequence? I surely don't have a problem with the manual verification.

The current bugs are basically that occasionally, you can't decrypt a message. Supposedly this has actually been fixed (and wasn't a security issue), but I've seen it once or twice since. And as I say, you lose your chat history if you log out or bring in a new device. This is an important bug to fix, but it requires some UX work.

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

#156

Post by tptacek »

Arathorn wrote: post #146
tptacek wrote: 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…

"lowest common denominator" security is not necessarily that bad, as long as that denominator ends up being a relatively high value and there's a way to ratchet it upwards overtime (by excommunicating obsolete/broken implementations). 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) incompatibl…

That's the problem: there isn't a way to ratchet it up over time. It stays anchored at the lowest common denominator. It's tough to find counterexamples; see, for instance, the waking nightmare that is the XMPP ecosystem.

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.

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

#157

Post by tptacek »

Sir_Cmpwn wrote: post #145
tptacek wrote: post #144

Earlier quoted context omitted.

You're ping-ponging all over the place. Which is it? "Glaring security problems", or impediments to fully exploring the solutions space?

Why can't it be both? You're a real difficult person to have a rational discussion with, you know.

Because it's clearly not both.

If I say "your house is on fire!" and you rebut "no it isn't" and I respond "well, your shoelace is untied", any reasonable observer will conclude that you've conceded the house fire.

If my house was really on fire, you'd say "no, really, look at it! Flames are shooting out of the bedroom window!". If your strong argument was valid, you'd restate it, perhaps with additional evidence.

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

#158

Post by x0x0 »

vertex-four wrote: post #133
x0x0 wrote: post #129

Earlier quoted context omitted.

This is remarkably contrary to how people actually use software. What people see is "click this button to make annoying red flashing shit stop so I can do what I want to do". ala http://i.imgur.com/H0uVqFe.jpg

There's a reason web browsers just don't allow users to easily get past the annoying pages when there is a chance they're being attacked. I see no reason that Matrix clients would be required to allow users to break security without having a persistent banner saying "this room is insecure".

Which they will ignore.

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

#159

Post by Arathorn »

tptacek wrote: post #156
Arathorn wrote: post #146

Earlier quoted context omitted.

"lowest common denominator" security is not necessarily that bad, as long as that denominator ends up being a relatively high value and there's a way to ratchet it upwards overtime (by excommunicating obsolete/broken implementations). 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) incompatibl…

That's the problem: there isn't a way to ratchet it up over time. It stays anchored at the lowest common denominator. It's tough to find counterexamples; see, for instance, the waking nightmare that is the XMPP ecosystem. 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 install…

Firstly, I completely agree that it's easier to flip a centralised switch, make an incompatible change to fix a security issue, and force all their clients to upgrade to continue working.

However, I don't think that decentralised solutions have to end up in the worst-case scenario we see with SMTP (or even random(4)), or the medium-case nightmare of (say) phasing out SHA-1 TLS certs. There's a spectrum of nightmare here, and you can engineer both the tech and the governance to enforce a culture of security awareness and aggressive upgrading until things move fast enough. In practice, this means:

* Set a cultural precedent that obsolete clients are a bug, not a feature, and should be killed off or upgraded.

* Ensure that the most popular clients are actively supported to implement security features. If necessary, the standards body itself should get off its ass to do the work in order to protect the integrity of the ecosystem.

* Set a cultural norm of shaming users and developers who don't upgrade for security features - the same societal pressure that generally stops people wandering around in public if they're covered with chickenpox.

* Enforce it in the largest public communities of the ecosystem - in Matrix, this would be #matrix:matrix.org and a bunch of other huge >5000 user rooms, where if one day we had to make an incompatible protocol change, it'd suddenly be abundantly clear that folks on old clients would be excommunicated until they upgraded. We believe that users would rapidly find a way to switch client or encourage their developers to upgrade if it meant they were no longer able to participate in the biggest rooms!

* It's obvious, but: layer the protocol so that functions can be swapped out easily, just as Matrix allows arbitrary future E2E protocols in addition to today's m.megolm.v1.aes-sha2.

SMTP's woes stem from innocently trying for backwards-compatibility at all costs; not layering the protocol; having no governance model or culture which shamed ancient or obnoxious MUAs into being abandoned or fixed.

Slowness of SHA-1 phase-out in HTTPS is more the community again being conservative about backwards-compatibility, and a rather cautious attitude from the browser vendors in deploying the upgrade due to fear of upsetting everyone's expectations that The Web Never Breaks. Again, if you had more of a willing attitude that sometimes there's a security disaster and everyone has to upgrade (assuming that the software mechanisms are in place to upgrade and you haven't baked into hardware etc), perhaps people would be more willing to move faster.

So, with Matrix, we're trying to instil that attitude from the outset, whilst ensuring that the tech can support it. Time will tell whether it will work :) Better worth trying than to give up on federation and decentralisation entirely, though: privacy has no value without freedom.

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

#160

Post by Forbo »

haffenloher wrote: post #103
Forbo wrote: 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.

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=20m16…

He mentions "technical assistance orders" but doesn't really elaborate any more on them. I'm having a difficult time finding any information on these orders, does anyone else have information on the capability of these orders?
Post reply on HN