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/

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

https://whispersystems.org/docs/specifications/doubleratchet...

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.

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.

    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.