Same. It's tough when the name of your company/product has the same name as the producer of one of the largest and most successful multiplayer games ever built. 0_0
For those who check comments before following through to the story Riot is the main web interface for the Matrix project, the opensouce IRC and slack alternative. And Riot was formerly named Vector.From the look of it the project is going great.
I believe it has been implemented in the web interface for some time now, but now it's available in the mobile apps as well, so for mobile-to-web or mobile-to-mobile chats or other cross-device implementations you can use encrypted chat.
It had been implemented already but (and this was made quite clear in the docs and on the site) it hasn't been production quality (it took a while to implement, and then they were some cryptographers to check it over, IIRC). Several of the matrix devs are HN regulars, so they ought to show up soon-ish, and will hopefully let us know if I got that wrong.
You got it right :) It was on the web, but hadn't been audited yet (and lacked encrypted attachments and VoIP signalling and other good stuff). Now it's been audited (https://www.nccgroup.trust/us/our-research/matrix-olm-crypto...), is available on Android & iOS too, and we have encrypted VoIP & attachments too!
Matrix.org is a non-profit open source project that publishes an open standard for decentralised interoperable communications (IM, VoIP, etc), an example server implementation and a bunch of example client SDKs, bridges, bots, etc. 'Matrix' is the name of the resulting ecosystem on the 'net.
Riot.im is one of the various client apps for Matrix, supporting iOS & Android, and is probably the most advanced at this point.
EDIT: clarify org structure: Matrix.org is being set up as a non-profit UK company owned by the various individuals running it. The business model is to create a new ecosystem for interoperable comms that everyone can benefit from.
Riot is a for-profit company (technically called Vector Creations Ltd) which is a subsiduary of Amdocs (a big telco supplier company). The business model is to offer paid hosted services in future for users wanting commercial-grade hosting and hosting private bots/bridges/etc.
Since you are UK-based and Snooper's Charter is a thing now, how will that affect Riot/Matrix? Will you be moving the official base to some countries with greater respect for privacy?
Well, you can always use Riot with a Matrix server in whatever country you like (or run by a company HQ'd in whatever country). And the code is all open, so you can always check for backdoors or build your own copy. For folks worried about the security of the default hosted service for Riot I guess we could set up a canary or something but I really hope we won't get to that :(
(Also, in practice Riot is half UK and half French - although France has its own fair share of crypto confusion).
I'll start right off the bat: I'm not affiliated with the riot chat or matrix crew, however, I am an enthusiastic user of both technologies. So any of the following is what I've learned, and not any official communications...
Matrix is a protocol for decentralized communication. Plenty more info can be gained from their FAQ: http://matrix.org/docs/guides/faq.html The gist: the protocol can theoretically be used for decentralized chat, WebRTC, and comms between internet of things...With decentralized chat so far appearing to be the most popular. As to your question on the "Who is behind" this? See: http://matrix.org/docs/guides/faq.html#who-is-funding-matrix...
Also, the folks who created Riot/Vector, manage a public matrix homeserver that anyone can join. See https://riot.im Naturally, the point of this being a decentralized effort (and shying away from silos), you don't have to create an account on the riot.im homeserver, but in fact can setup/manage your own (matrix) homeserver! You know...like email used to be more decentralized ;-)
IMO Riot is a late beta - pretty much all the features are there, but performance needs work and the UX needs work (this is next on the plate now E2E is done). HN and Powerusers are fine. Right now typical end users require a little handholding to get started.
I have a private homeserver set up and I tell my (nontechnical) wife to fall back to using Riot on her phone to talk to me if / when hangouts doesn't seem to work.
We end up talking on Riot instead of hangouts roughly 1x / month, and I've had no troubles with it so far (except that the matrix server seems to want to use way more memory than I think it "should", so I have it running in a loop that restarts the server whenever the OOM killer kills it. It gets killed fairly regularly (>1x / hour) and I don't really notice it while using Riot).
edit: I don't use the e2e encryption stuff. I have an SSL cert and if chat messages are encrypted as far as the server (which I control), that's fine with me.
thanks for trying to help out. just checked, this is how I'm running it:
while : ; do SYNAPSE_CACHE_FACTOR=0.01 python -B -m synapse.app.homeserver -c homeserver.yaml ; sleep 20 ; done
I'm not even using runit or anything; I set it up like this several months ago and haven't bothered touching it since because it's been relatively solid and reliable.
Even at a "cache factor" of 0.01, my tiny DO droplet is still swapping and eventually the homeserver gets OOM killed.
I need to tear into this later, but I really hope they're not implementing multi-party ECDH (which is perilous even if you're using X25519; if anyone thinks about going down this route, please hire a cryptographer).
I'm working on publishing some research in this specific slice of cryptography in the next couple of weeks, but briefly.
Alice, Bob, and Charlie are chatting securely. Using the notation where lowercase indicates secret key and uppercase indicates public keys:
s0 = aBC = bAC = cAB
Debora joins the conversation.
s1 = aBCD = bACD = cABD = dABC
What does Debora see? In naive implementations, the output of the previous handshake (s0) is given to Debora to mix with her secret key. This isn't a good design (and you can't do this with the implementations of X25519 I've reviewed, e.g. libsodium's), but that's not obvious to someone who's never studied these kind of protocols before.
Now they decide to oust Charlie from the group. How do you handle revocation safely and efficiently?
If you combine the two issues above, you create a join-slurp-leave loop that gives you the secret keys of conversations that take place while you are absent. (This is an active attack, of course.)
Let's say Bob's laptop is stolen. Does mpECDH have forward security-baked in? No. (Protocols like Signal's do.)
So you add forward secrecy. Great, now how do you know the server isn't replacing public keys since they're changing frequently?
These are just a sample of the kind of challenges one faces when they venture down this road. If you ask almost any cryptographer, they'll have a somewhat reasonable answer for these challenges. But a non-crypto dev would, with all likelihood, not think to even ask.
yeah, this was a tricky one. Many of the problems NCC found are concerned with using the library correctly. For instance, if an app wants to turn off PFS for instance, it can. Technically this means that the library has a PFS vulnerability. However, sometimes this is a feature - e.g. if I want to be able to deliberately decrypt history to sync it to a new device.
We're looking at ways to try to better split the higher level crypto stuff into another library (which we'll then get NCC to audit) - but until then matrix-{js,ios,react}-sdk have implemented it separately.
Threema does not provide individual message level forward secrecy. From their whitepaper [1]:
> "Due to the inherently asynchronous nature of mobile messengers, providing reliable Forward Secrecy on the end-to-end layer is difficult. Key negotiation for a new chat session would require the other party to be online before the first message can be sent. Experimental schemes like caching pre-generated temporary keys from the clients on the servers increase the server and protocol complexity, leading to lower reliability and more potential for mistakes that impact security. The user experience can also be diminished by events that are not under the control of the sender, for example when the recipient loses their phone's data, and along with it the ephemeral keys. Due to these and the following considerations, Threema has implemented Forward Secrecy on the transport layer only"
Moxie writing about forward secrecy and key derivation ratcheting in November 2003 [2]:
> "it's not clear why individual message level forward secrecy is necessary. Instant messaging sessions tend to be ephemeral, and the messages themselves tend to be in memory for the duration of the session, so it's not entirely obvious what immediate value a ratcheting forward secrecy protocol provides in that context. Simply doing an ephemeral Diffie-Hellman key exchange at the beginning of every session would probably be enough."
He then goes on to lay out why individual message level forward secrecy is nonetheless desirable; this is not quoted.
Moxie writing about forward secrecy and async messaging in August 2013 [3]:
> "On the other hand, iOS apps like Threema and the proposed Heml.is support asynchronous messaging, but do not provide forward secrecy. Users have static public keys that are maintained by a server, which anyone else can query and encrypt to without having to engage in a key exchange round trip to the user. This allows for the frictionless asynchronous experience that mobile users have come to expect, but unfortunately relies on an undesirable cryptographic protocol model (the PGP model) that is increasingly being seen as an architectural dead end.
unless you have privacy you can't do anything that requires privacy. that eliminates like 95% of everything people who aren't drooling morons want to do.
47 comments
[ 2.6 ms ] story [ 119 ms ] threadhttps://engineering.riotgames.com/news/fixing-internet-real-...
Honestly at this point, this Riot should probably give up and change their name. It didn't occur to me this could be about a different Riot.
It's great to see them implementing this. If you're company is not, please get busy - IMHO it should be the norm now.
https://www.eff.org/deeplinks/2016/11/tech-companies-fix-the...
Riot.im is one of the various client apps for Matrix, supporting iOS & Android, and is probably the most advanced at this point.
EDIT: clarify org structure: Matrix.org is being set up as a non-profit UK company owned by the various individuals running it. The business model is to create a new ecosystem for interoperable comms that everyone can benefit from.
Riot is a for-profit company (technically called Vector Creations Ltd) which is a subsiduary of Amdocs (a big telco supplier company). The business model is to offer paid hosted services in future for users wanting commercial-grade hosting and hosting private bots/bridges/etc.
(Also, in practice Riot is half UK and half French - although France has its own fair share of crypto confusion).
Matrix is a protocol for decentralized communication. Plenty more info can be gained from their FAQ: http://matrix.org/docs/guides/faq.html The gist: the protocol can theoretically be used for decentralized chat, WebRTC, and comms between internet of things...With decentralized chat so far appearing to be the most popular. As to your question on the "Who is behind" this? See: http://matrix.org/docs/guides/faq.html#who-is-funding-matrix...
Riot (aka Riot chat, formerly known as Vector.im) is one of a number of client applications for interacting with Matrix servers. More clients can be found here: http://matrix.org/docs/projects/try-matrix-now.html#clients
Also, the folks who created Riot/Vector, manage a public matrix homeserver that anyone can join. See https://riot.im Naturally, the point of this being a decentralized effort (and shying away from silos), you don't have to create an account on the riot.im homeserver, but in fact can setup/manage your own (matrix) homeserver! You know...like email used to be more decentralized ;-)
Cheers!
We end up talking on Riot instead of hangouts roughly 1x / month, and I've had no troubles with it so far (except that the matrix server seems to want to use way more memory than I think it "should", so I have it running in a loop that restarts the server whenever the OOM killer kills it. It gets killed fairly regularly (>1x / hour) and I don't really notice it while using Riot).
edit: I don't use the e2e encryption stuff. I have an SSL cert and if chat messages are encrypted as far as the server (which I control), that's fine with me.
I launch my instance like this: SYNAPSE_CACHE_FACTOR=0.01 synctl restart /etc/matrix-synapse/homeserver.yaml
I run synapse on a machine with 1.5GB of total RAM and have had zero memory issues since limiting the memory usage with the above command.
Even at a "cache factor" of 0.01, my tiny DO droplet is still swapping and eventually the homeserver gets OOM killed.
I need to tear into this later, but I really hope they're not implementing multi-party ECDH (which is perilous even if you're using X25519; if anyone thinks about going down this route, please hire a cryptographer).
Alice, Bob, and Charlie are chatting securely. Using the notation where lowercase indicates secret key and uppercase indicates public keys:
Debora joins the conversation. What does Debora see? In naive implementations, the output of the previous handshake (s0) is given to Debora to mix with her secret key. This isn't a good design (and you can't do this with the implementations of X25519 I've reviewed, e.g. libsodium's), but that's not obvious to someone who's never studied these kind of protocols before.Now they decide to oust Charlie from the group. How do you handle revocation safely and efficiently?
If you combine the two issues above, you create a join-slurp-leave loop that gives you the secret keys of conversations that take place while you are absent. (This is an active attack, of course.)
Let's say Bob's laptop is stolen. Does mpECDH have forward security-baked in? No. (Protocols like Signal's do.)
So you add forward secrecy. Great, now how do you know the server isn't replacing public keys since they're changing frequently?
These are just a sample of the kind of challenges one faces when they venture down this road. If you ask almost any cryptographer, they'll have a somewhat reasonable answer for these challenges. But a non-crypto dev would, with all likelihood, not think to even ask.
https://whispersystems.org/docs/specifications/doubleratchet...
A critical thing is that the crypto library (olm) has had an independent security assessment from NCC Group: you can see their report at https://www.nccgroup.trust/us/our-research/matrix-olm-crypto...
From a quick scan of the PDF, it looks like their higher-level Matrix library mitigates attacks that Olm itself does not.
I'm not sure how I feel about that.
We're looking at ways to try to better split the higher level crypto stuff into another library (which we'll then get NCC to audit) - but until then matrix-{js,ios,react}-sdk have implemented it separately.
> "Due to the inherently asynchronous nature of mobile messengers, providing reliable Forward Secrecy on the end-to-end layer is difficult. Key negotiation for a new chat session would require the other party to be online before the first message can be sent. Experimental schemes like caching pre-generated temporary keys from the clients on the servers increase the server and protocol complexity, leading to lower reliability and more potential for mistakes that impact security. The user experience can also be diminished by events that are not under the control of the sender, for example when the recipient loses their phone's data, and along with it the ephemeral keys. Due to these and the following considerations, Threema has implemented Forward Secrecy on the transport layer only"
Moxie writing about forward secrecy and key derivation ratcheting in November 2003 [2]:
> "it's not clear why individual message level forward secrecy is necessary. Instant messaging sessions tend to be ephemeral, and the messages themselves tend to be in memory for the duration of the session, so it's not entirely obvious what immediate value a ratcheting forward secrecy protocol provides in that context. Simply doing an ephemeral Diffie-Hellman key exchange at the beginning of every session would probably be enough."
He then goes on to lay out why individual message level forward secrecy is nonetheless desirable; this is not quoted.
Moxie writing about forward secrecy and async messaging in August 2013 [3]:
> "On the other hand, iOS apps like Threema and the proposed Heml.is support asynchronous messaging, but do not provide forward secrecy. Users have static public keys that are maintained by a server, which anyone else can query and encrypt to without having to engage in a key exchange round trip to the user. This allows for the frictionless asynchronous experience that mobile users have come to expect, but unfortunately relies on an undesirable cryptographic protocol model (the PGP model) that is increasingly being seen as an architectural dead end.
[1] https://threema.ch/press-files/cryptography_whitepaper.pdf [2] https://whispersystems.org/blog/advanced-ratcheting/ [3] https://whispersystems.org/blog/asynchronous-security/