Live data from Hacker News

Encrypted messengers: Riot, not Signal, is the future

titus-stahl.de

141–150 of 178 posts

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

#141
post #19

Earlier quoted context omitted.

Especially dishonest of Riot promoters is to even introduce it at this very moment to the "normal" users, because "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 m…

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.

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

#142
post #111

Earlier quoted context omitted.

As mentioned signal doesn't hide contact discovery. But it does a pretty good job of hiding who you are chatting to from everyone but OWS. OWS received a Grand jury subpoena and was only able to produce "the only information we can produce in response to a request like this is the date and time a user registered with Signal and the last date of a user's connectivity to the Signal service.". Certainly a NSL might comp…

> OWS received a Grand jury subpoena ( ... ) Link please

https://whispersystems.org/bigbrother/eastern-virginia-grand...

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

#143

Earlier quoted context omitted.

They still contain information, though. They say when you're talking on Signal. Matched with someone else's messages at about the right frequency to indicate a conversation, they give a pretty decent idea of who you're talking to.

They give the same information that TCP/IP traffic analysis does.

Perhaps, but we can at least start to explore solutions to that if we can work on the server too.

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

#144

Earlier quoted context omitted.

They give the same information that TCP/IP traffic analysis does.

Perhaps, but we can at least start to explore solutions to that if we can work on the server too.

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

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

#145

Earlier quoted context omitted.

Perhaps, but we can at least start to explore solutions to that if we can work on the server too.

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.

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

#146
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) 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.

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

#147
post #19
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…

Especially dishonest of Riot promoters is to even introduce it at this very moment to the "normal" users, because "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 m…

Just to be clear, the blog post here is not connected to the Matrix.org and Riot teams and is entirely independent of us. We've tried to be crystal clear that E2E is still in beta, as per https://matrix.org/blog/2016/11/21/matrixs-olm-end-to-end-en.... We are not recommending or introducing it yet to normal users.

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".

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

#148
post #111

Earlier quoted context omitted.

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.

As mentioned signal doesn't hide contact discovery. But it does a pretty good job of hiding who you are chatting to from everyone but OWS. OWS received a Grand jury subpoena and was only able to produce "the only information we can produce in response to a request like this is the date and time a user registered with Signal and the last date of a user's connectivity to the Signal service.". Certainly a NSL might comp…

>As mentioned signal doesn't hide contact discovery. But it does a pretty good job of hiding who you are chatting to from everyone but OWS.

Anything that does TLS to connect to a single server can do that. Heck, if you do email to a single email server using secure IMAP and secure SMTP then PGP no longer leaks metadata.

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

#149
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...

Yes. Once the E2E implementation is fully finished and out of beta, and once we have a non-beta homeserver (as Synapse is still technically in beta, albeit very late beta), we'll be going to NCC and working out how to do an audit of the whole enchilada (homeserver + olm + matrix-js-sdk + matrix-react-sdk + riot-{web,ios,android}). This may well end up being broken down into separate components, much as the Olm audit was limited to the Olm component. At the current rate this should happen at some point in 2017.

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

#150

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.

Account migration is Hard, and we deliberately descoped it from the original design of Matrix in a bid to ship stuff sooner than later. https://github.com/matrix-org/GSoC/blob/master/IDEAS.md#dece... is a quick description of the problem.

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!

Post reply on HN