Riot releases end-to-end encryption: get ready to chat securely(medium.com)
medium.com
Riot releases end-to-end encryption: get ready to chat securely
https://medium.com/@RiotChat/exciting-new-riot-release-get-ready-for-chatting-securely-acc93ecfe0a#.nrt6p0t6z
11 comments
How does this compare to Threema (which uses NaCl)?
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.
[1] https://threema.ch/press-files/cryptography_whitepaper.pdf [2] https://whispersystems.org/blog/advanced-ratcheting/ [3] https://whispersystems.org/blog/asynchronous-security/
> "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/
This is a good move on their part.
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.
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.
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.
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.
I thought this was about League of Legends at first, and I was terrified that Riot was going to make it harder to chase down toxic chat in their game.
Doesn't help that the first 4 google search results for "riot chat" are League of Legends sites
Same, especially since the gaming Riot has blogged about their very impressive chat infrastructure in the past.
And about making improvements to network architecture.
https://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.
https://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.
They just recently changed their name to Riot... (from "Vector")
Because when someone is calling my mom a fag on the internet, I want that to be encrypted.
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
Same. “Okay, so now hackers and the CIA won’t know that some teenage punk called me a ‘homersexual faglord’, that’s just terrific.”
they should get 2 factor authentication before worrying about having end to end encryption in their chat.
[deleted]
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.
Also, here's the link to the app https://riot.im/. Since it doesn't seem to be anywhere on the blogpost.
Wait, it wasn't already? I never looked into it to closely, but their marketing always suggested encryption was part of it.
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!
Thanks for the clarification!
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.
Would someone kindly explain what Riot and Matrix are, who is behind them, etc.?
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...
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...
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.
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).
(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...
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!
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!
Thank you! How mature is it? How usable is it - usable for the HN crowd? Power users? Typical end users?
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.
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.
https://github.com/matrix-org/synapse#help-synapse-eats-all-...
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.
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.
thanks for trying to help out. just checked, this is how I'm running it:
Even at a "cache factor" of 0.01, my tiny DO droplet is still swapping and eventually the homeserver gets OOM killed.
while : ; do SYNAPSE_CACHE_FACTOR=0.01 python -B -m synapse.app.homeserver -c homeserver.yaml ; sleep 20 ; done
Even at a "cache factor" of 0.01, my tiny DO droplet is still swapping and eventually the homeserver gets OOM killed.
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.
http://matrix.org/docs/guides/e2e_implementation.html
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 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).
we're not. plus we hired cryptographers: https://www.nccgroup.trust/us/our-research/matrix-olm-crypto... :)
Excellent! This should go in a top-level comment so folks can review the audit and study its findings.
They say that their "Olm" library is an implementation of the "Double Ratchet" algorithm:
https://whispersystems.org/docs/specifications/doubleratchet...
https://whispersystems.org/docs/specifications/doubleratchet...
For someone who knows very little about this subject, could you elaborate?
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:
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.
Alice, Bob, and Charlie are chatting securely. Using the notation where lowercase indicates secret key and uppercase indicates public keys:
s0 = aBC = bAC = cAB
s1 = aBCD = bACD = cABD = dABC
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.
That makes a lot more sense. Thank you for the reply.
[deleted]
[deleted]
Turn encryption on by default. Otherwise, it won't be used.
we're pretty confident that the folks we want betaing it (e.g. the HN community) will turn it on. Meanwhile joe public has the option to experiment, but we won't turn it on by default until we're sure we've got the nastiest bugs out.
That doesn't really work when encryption can't be turned off...
Finally. It's been a long time coming. I'm very excited that it's finally here.
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...