Riot releases end-to-end encryption: get ready to chat securely

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.

[1] https://threema.ch/press-files/cryptography_whitepaper.pdf [2] https://whispersystems.org/blog/advanced-ratcheting/ [3] https://whispersystems.org/blog/asynchronous-security/

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.

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.

Excellent! This should go in a top-level comment so folks can review the audit and study its findings.

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?

Thank you! How mature is it? How usable is it - usable for the HN crowd? Power users? Typical end users?

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!