 So, Matthew Hudson will talk to you about the matrix end-to-end encryption. Thank you very much. Welcome. Hi. Can you hear me? Thank you. Can everybody hear me all right? Wonderful. Brilliant. You can ask questions during it if you want. Particularly as we tend to run out of time sometimes at the end for questions. Who doesn't know what matrix is? We've got three, four, five people. Six. Six and a half, seven. Okay. Very quickly, I'll try to give a very rushed explanation of matrix. Apologies to people who came to the earlier talk, because it is identical to trying to bring people up to speed. In this, we're going to be talking about how we have made end-to-end encryption on matrix over the last couple of years and how we are finally turning it on by default like now and also look at how to break it a bit if we have time. So, matrix, it's an open network for secure decentralized real-time communication. Use it for chat, VoIP, VR, AR, IoT. It's basically a big multiplayer Pub-Sub database. Anybody can store data in it of any kind. They can subscribe to it on other servers. It's meant to be, and it is, the missing communication layer of the web itself. So the whole idea is to have a global open coms network, which is standard-based and provides an open platform for real-time coms, just like the web, but for real-time communication. One way to think of it is if you have the silos of the very different proprietary or not proprietary islands of communication today, matrix can sit in the middle. There's this big mesh of servers which are replicating conversations between them. They have native matrix clients here. They have bridges through to other protocols. And so somebody on XMPP could be talking through to somebody on IRC without even realizing that they're being bridged via matrix in the middle. Lots of people use it natively. Other people go and bridge through to other networks too. The unique thing is that no single person owns your conversations. The conversations are shared over everybody. So if I am on my matrix server and I want to talk to somebody on another server, the very act of talking to them has almost subversively decentralized the conversation between us. So their copy is just as valid as my copy. It's just like Git. Anybody who's ever pushed or pulled to a Git repository or cloned one for that matter should understand what's going on. Architecturally, clients, servers, application servers, identity servers, identity servers suck. We want to kill them off. Hopefully we will. What do you get in the spec? You get decentralized conversation history, group messaging as a first-class citizen. Obviously end-to-end encryption. That's why we're here, right? So end-to-end encryption we began in 2015 by implementing OM as the double-ratchet algorithm used by Signal, originally called Lib Axolotl at the time. We implemented our Apache license version of it. And then we added Megom, the next year in 2016, and since then we've been chipping away at it, trying to get it to parity with the non-encrypted flavor of matrix so that we could turn it on by default for private conversations. Worth noting that we are not planning to turn it on by default for public conversations, but if you are having a conversation that is already being indexed by Google, it's in public, it's like anybody can join it, there is very, very little point to encrypting it. Arguably you get a little bit of nice properties in terms of reliability or in terms of the signatures to prove that people said these things, but in the end it also has scalability issues. We have rooms of matrix with over 100,000 users in them. Each user averages about two or three devices and that's 300,000 endpoints and we're focused at the moment of making matrix KCAS for private encrypted rooms with a couple of thousand devices rather than 300,000. Also VoIP signaling, server-side goodies, unread counts, all the stuff that you expect to get from a modern communication app like WhatsApp or Slack or Discord. Ecosystem, you have the SPAC, you have the servers, the bridges, application servers, and then you have the clients. Worth noting that RIA X here is almost at the point of replacing RIA Android. We are entering the 1.0 release basically now with release candidates on the horizon over the coming weeks. I think we just shipped RIA X 014.1 or is it .2? Benoit? 2. And that is hopefully one of the last builds before we go GA 1.0. So if you're not using RIA X on Android, please give it a whirl particularly as it has a lot of the end-to-end encrypting goodies in it which we're talking about today. I've started using it on Android in the last couple of days mainly because there was a double free crash that was killing my account on it but now that's fixed. It's really nice. Unrecognisably better than RIA Android. In terms of uptake, daily active users are following this interesting parabola over the last three years. I'm not much really to say about that other than it puts a lot of pressure on us to make sure that the server implementation scale. And overall community stats 13 mil global MXIDs, about 5 million messages a day that we can see 4.5 million chat rooms that we can see from matrix.org, 20,000 servers actually 40,000 in the real world 3,500 messages a second going out, about 35 hertz coming in and lots of different companies, projects and also governments building on top of matrix, most famously France, also Germany as of the end of last year the US has some servers as well and we're working with the UK as well. If anybody owns a government around here and wants to get more matrix, please come and talk to me afterwards because it's kind of fun to get all the different countries on the same encrypted cons and infrastructure. So sorry for the boring bit, let's get on with the fun stuff. Finishing E2E in matrix. First of all E2E by D4 is obviously really important for various different reasons. First of all we're replicating conversations everywhere on matrix in the first place and so every server that joins a room gets a copy of that data. If it's not end to end encrypted your attack surface just scales linearly and that is obviously bad news. Also we want to protect ourselves from compromised servers in general that might be malicious assessments it might be people who have compromised a given server we also want to be protected by people who have man in the middle of the TLS. End to end encryption is also useful because it asserts the central identity and it also gives us a framework for verifying user's keys and verifying their identity. We actually started this whole final lag of turning on E2E by D4 at 2019 last year. So here's a flashback actually of a flashback, this is a meta flashback of a slide from Fozdom in 2017 where we said this is what we need to do in the next like couple of years to get E2E turned on and as of 2019 we got like that far physically down that list we were literally going through it in turn. The only things we lacked were E2E capable search actually turning it on obviously negotiating it with legacy clients and in retrospect we kind of had a few other things. We need to support non-E2E clients we do not want every random hacker who's written a matrix client or bot to be left out in the cold because they can no longer get at their DMs or their private rooms because we've turned on E2E by D4. We want to obviously be able to search we want to have file indexes really nice to have your file panel in right to show you what's in a room you need to finalize the UI-UX cross-signing absolutely critical as everybody in this room knows it's apart from seven it's really annoying in matrix when somebody joins a conversation with a new device because you have to verify it what if they could attest to their own device so you verify a user once and you don't have to keep verifying their other devices and finally even better verification UX so not just the overall UX but specifically making this as easy and smooth as possible so in turn pantolime who knows what pantolime is okay about half the room so pantolime is obviously Lyra's demon from his dark materials also it's an end-to-end encrypted demon that offloads all of your E2E so the idea is that if you're writing some random little matrix pro way script or new client and you can't be bothered to write an audited, massive, complicated E2E implementation you can just connect via matrix to a local demon that offloads all the hard stuff and it proxies you through to your actual server it's written in Python in async.io using the NoIO style which is basically you abstract all the IO away and then plug it into async.io at the last minute it provides management interface by debus and we ship a command line interface but the idea is that people will hopefully write little system tray pop-ups so you can have little things here saying hey, do you want to verify the new user in this conversation even when you're not using an E2E-capable client it's actually the same stack as WeChat matrix it's written by a chap called Demir, his naked polio on matrix who originally was doing WeChat matrix and it was really really cool, he wrote his own Python implementation of E2E and an entire matrix and SDK and so he said hey, Demir, why not come on matrix full time and come and work on pantalime so that is where pantalime has come from and most excitingly and I didn't ask his permission to reveal this but the case, if you look on GitHub there is busy rewriting first of all WeChat matrix in Rust using rumour as the client framework and structures and also we're using OMRS which is the native Rust implementation of OM that has come from the fractal developer so huge thanks to Brain Blasted and Johannes Hayes for relicensing and the other contributors for relicensing OMRS so that we could use it in the Apache stack of all of the official matrix projects and the idea is to build an official matrix Rust SDK on top of the stack that can be used in pantalime in future and other clients so that's pantalime let me quickly show you it risk a live demo, you know how well these are going to do so here is pantalime, just sitting here in the background it's going and decrypting syncs, it's going and sending device messages around the place and you might wonder what is connected to it well, this client here is what is connected to it anybody know what this is? one person does two, three, four this is a really interesting client it might look very minimal because there is no UI on it really at all and it's called Brawl it's written by Bruno it's written by Riot Web developers and it's an experiment in an entirely new JS SDK this is backed by indexedDB in a really intelligent way unlike JS SDK which predated the existence of indexedDB and we're experimenting with it as a full time as a spare time project just to see how nice a JS SDK you can build such that we might eventually use it in Riot Web or similar and this room here is talking through to me at matheonmatrix.org so Matthew it goes and sends and you can see that it's been sent there and you can see a hello Matthew coming in here and the key thing is that you can see for our new UX this room is actually end-to-end encrypted with the shield here I haven't verified Matthew's test 7 I can respond back with hello and assuming I have enough connectivity and matrix.org server is working there you go, you get the hello back so that is basically what it looks like you've got an experimental client, you haven't bothered with E2E, you pipe it through pantalime and hey presto, it's all E2E and I haven't actually tested this so it probably will go horribly wrong but if I were to go into here and try to verify Matthew 7 test and start verification you can actually see our new UI that is coming together for verification requests I have a horrible feeling that it's going to try to do this via cross-lining voodoo but basically pantalime does support verification pre-cross-signing and obviously in the near future it will support cross-signing too so that's pantalime so that's one of the big missing ingredients now done, it's stable, we use it in production lots of random bots and encrypted rooms particularly for managing the matrix.org home server where we want to pull in a bot we just wedge it through pantalime so it can be in the encrypted room Sasha, also actually done by Demir entirely new solution to full-text search obviously if you're end-to-end encrypting your chat rooms you can't some search server-side on the encrypted messages unless you do very exotic things with homomorphic encryption that we don't have time to figure out right now so what we did instead was to take Tentavie which is a Rust full-text search engine very similar to Lucene except much much much smaller and written in Rust rather than Java or whatever Lucene is written in today and what we've done is to compile it client-side and here it is basically as a bunch of Rust wrapped in a node wrapper and then we have Matrix, Sasha as JavaScript bindings on top of this which means that we can then embed it into the matrix React SDK and in turn into Riot Web and what Tentavie does and Sasha does is to spider all of your messages from your encrypted accounts and build up a full-text search index of it all so interesting things that we can do with Sasha is it's cross-platform in Rust so we could easily integrate it in other clients not just Riot but any matrix client can use this in future we can also potentially incrementally gossip the encrypted indexes between each other and a really fun thing we've done is to pipe all of the data through SQL Cypher before storing it in SQLite as well as adding encryption support to Tentavie so that it's literally decrypting your E2E history indexing it and then storing it to disk locally as in turn encrypted messages and that in turn could be gossiped between different clients so you can leave your laptop on Riot desktop going and spidering away all of your messages building up these indexes and meanwhile you log on on a phone and all it has to do is to perhaps lazy load the indexes on a per room basis and it doesn't have to re-index everything so we can just pick up the indexes being pre-calculated so this is shipped now in the develop branch of Riot desktop the only catch is we need to finish updating our build infrastructure to do Rust native modules on Riot desktop we don't yet have it in Riot Web because Wazm doesn't support threads and Tentavie is very heavily threaded so we can't compile it down to Wazm yet in terms of what it looks like so if I go to some encrypted room which I probably should have picked beforehand NuVac to Limited is where the UK office of NuVac are working on matrix to decide where to go for lunch mainly and you talk about caramel and brownie bites if I go and search an encrypted room like this now and search for I know Duke which is our local pub apparently we haven't been talking about Duke ah, here I'm on the Riot Web I should be on Riot desktop let me go and just set that going not Yarn install, Yarn run, Electron let me go and fire up at Riot desktop so that's what it looks like today few minutes to come back to that and we can look at how it works in Electron right, what next another big thing that was blocking us unashamedly is that we've been plagued by these under-createable messages and it's got better over the years, I hope everybody will agree that's Electron however it's still a bit of a pain in the ass that there are scenarios where you can just get messages and you don't have the keys to decrypt them so I mean the core problem about this is architecturally today keys follow a different transport path than the messages in matrix the messages can be replicated everywhere and you can indirectly get them from random servers and you can have 10 servers in the room and all of them can go down apart from one and you can get the messages because that server has the messages however that is not the path that keys take and if you think about it it's possibly a bit distasteful that just because I'm trying to set up a one-to-one encrypted channel with somebody on their server between theirs and mine why should that get relayed and flooded across all the other servers in a room it's very inefficient, it would be very it would be basically ON squared irrelevant signaling clutter so two solutions you can somehow attach it into the DAG anyway so it does cover the same path but it would flood lots and lots of information everywhere needlessly and slow everything down even more or we could switch tack entirely do something a bit like MLS where you just have a totally different algorithm for distributing keys in MLS you distribute them over a tree or the devices in a room effectively rather than a full mesh however short-term in practice unavoidable key distribution fails where you've had say a net split and the devices joined a room on one side of a net split and you just can't see it and so you're never going to send it the key because you didn't know it existed that sort of unavoidable thing is pretty unlikely and meanwhile we did find a whole bunch of other bugs which were causing failures so in the short term to get you to be turned on by default what we've done is to go through the list of the avoidable failures and try to fix them and it's mainly around keeping track of what devices are in a room so that you know who to encrypt for and everybody knows that there are three hard problems in computer science of cache and validation of by one errors and the idea I guess is that there are all different classes of cache and validation problems that your server knows what devices it thinks are in a room it needs to replicate that data with other ones so we now flush the device lists more aggressively if we do discover a cache fail or a integrity fail and somebody sends us a message from a device we've never heard of before rather than panicking we say well hang on tell us about that device and so we've got a whole bunch of recovery mechanisms in there now also after a federation outage there was a class of failures where device links would not recover properly I think our record so far has been three years of a server that came back and couldn't encrypt messages for me or amundine and it turned out that it got out of sync three years ago and never recovered all of these are now hopefully fixed and they are in the release candidate for 1.10 that we went and cut on Friday and should ship in 1.10 final in the probably earlier next week we've also improved things a lot around the unavoidable failures turns out that one of the most popular reasons for getting an undercryptable message in matrix is somebody a blacklisted you and you couldn't tell because it was the same you don't have the keys and everybody said oh matrix is terrible because I didn't get the keys well it turns out it's because the sender explicitly said don't send him the keys so we've now gone and actually put that in the UI also telling the user various different paths basically if the sender didn't know the client existed then we tell the receiver that was what happened if the on session has got wedged because of weird corruption we tell them to we're getting rid of the useless scary replay attack duplicate message things which just meant it was a duplicate message and also hiding the useless undercryptable messages that predate you joining the room all of that good stuff should ship in riot web 1.6 which happens again in the next week or so so cross-signing cross-signing has been an absolute epic the whole point is to let users vouch for their own devices so you don't have to verify everybody individually every time they dare to log into a new device on their account and we did a very early very very early demo last year which was winged together at the last minute to give a taste of how this could look and it was built on matrix spec change 1680 which was just called cross-signing and this is a really cool idea if you look at the spec it's basically the idea that any device can sign any other device it's a bit like PGP anybody can sign anybody else's key you end up with a great big dag at least of the user's own devices and that's what we implemented however it suddenly became clear that it was a bit too complicated Alice's device A could sign her device B and then her device B could sign C C to signs A you got a loop what happens if B gets lost you end up kind of with a fragmented net split of trust graph and what the hell do you do next also there was just no central way for a user as a person to just manage that mess which is basically the same problem it ends up getting fragmented so basically it's 1680 got retired starting over now MSE 1756 now called cross-signing with device-signing keys now this is a massive change to matrix for the first time we have a per user key it's no longer per device keys in fact we have three of them we have the one that you use to sign your own devices you have one that you use to sign other people's devices and you have the master key that goes and signs both of those we've gone and split for hygiene because they do different things allows you to rotate them separately particularly useful to basically have different trust levels for the different keys signatures get stored on your home server we only expose them to users that they relate to so this is not a big web of trust this is a personal web of trust for your devices and the people that you have signed practically speaking looks like that A for Alice has got a master key she's got self-signing key and her user-signing key she's signed Bob's master key Bob's master key in turn has signed Bob self-signing key and his user-signing key and Bob has a diner book in a VAX which is signed off on Alice as a PDP-11 not to be confused with a VAX and Osborne 2 and most importantly Bob has also mutually verified back to Alice so that's the data structure that we have going on on the server we also need a way though to synchronize these keys between devices and we could gossip between them or we can store them encrypted of course on the server and this is really very similar to how we handled the key backups today if you've got all of your E2E keys what do you do do you store them encrypted on the server or do you go and gossip them key sharing between the different devices so we're playing we're doing both it's called MSE 1946 I always weird how these line up with like years and it's called QoDAS Secure Secret Storage and Sharing and it works by storing your secrets and your account data Ancient Matrix API for storing arbitrary data about yourself and you can also use it for sharing directly via two devices between trusted devices and I'm afraid it is yet another key this time it really is the master-master key it's your QoDAS master key single most important one it replaces the old backup recovery key when you turn on cross-signing the first thing it will do is to migrate or bootstrap your old backup key and instead replace it by the master-master key which now signs the backup key so very similar to keybacker the private half should be stored somewhere secure offline in a trusted protected part of your OS if you have one you only need to ever provide it when you log into new secrets or you go and use it to sign with somebody and this is actually a bit of an annoyance in some ways right now whenever you need to unlock your master secrets in order to write to it you do need to provide that private key but we're looking at ways to improve this so this is particularly annoying on right web because you don't have a safe place to store private keys so right now we are prompting every time it needs for you to enter your passphrase in order to go and sign somebody or to log into a new device on the UX side we've made a fundamental change we've shifted to using shields to try to describe trust and we basically have three different classes here we've got unknown trust which is a black shield it means it's encrypted but you have no reason to particularly trust or distrust any devices then separately you've got the red shield untrusted you've run an explicitly verified somebody in that room but they have now gone added in a device which is not trusted so they've probably been owned this is bad news and then finally trusted which is green which means that you have not only trusted the user but they or you have trusted all of their devices and so you know for sure that they are in control of all of their devices the UX has been an epic this is NADS wireframes for infigma for not even wireframes the actual assets for the whole enchilada if we zoom in just one little bit of it you can see all the various flows being designed there sorry for all of the ugly mugshots on androids and IOS and we basically have really professionally gone through analysing and designing all of the cross-signing flows that we can this has been implemented in RIAX it's also landed in test flight on IOS in the majority of it at least and apart from QR scanning which I'll come to in a minute and it's also there on riot web develop hopefully people all agree it's a massive step up on the UX and visuals from what we've had before finally, better verification we're introducing QR codes as well as emoji this is not killing off emoji we love the emoji verification but sometimes it's easier to go than go tango whatever you know call out emojis to one another the way it works is that you basically produce the QR code with all of the keys you want to verify on it it's not an interactive thing at the moment so it's actually quite a complicated QR code because it has a lot of public keys in it and you show it to the other person if it matches their copy of it then they go and handshake back and say yep I trust that QR code and we do this quite importantly we do this both in band and out of band which allows us to mutually verify the other person if we see them physically say yep my phone says that that QR code is right and you talk about that in person then you've already taken out any malicious man in the middle and can say well okay I better trust it on my side too so it's a single QR scan to mutually verify Alison Bob with respect to one another another big change is that as you saw briefly earlier verification flows are now in your DM they're not random modals that pop up and annoy you instead they are actually in the timeline that you're talking to so what's blocked us lots of things however they're now all solved so it's now enabled as I said on right WebDevelop right X and right iOS so we actually try to demo it and see how well this goes so here is one that I here's one that I made earlier this is already logged on as a user called Bob let me fire up a new incognito window on a different port or different address and see what it looks like to sign up for the first time in this brave new world so I'm going to create an account on my personal server this Bob is called Bob10 so I'm going to create Alice10 with a secret password and totally new UI flow already this is now setting up the SSS master pass rows looks and feels a bit like the old flow and it gives you your recovery key to download or copy I'm going to download it and this is now the thing that wraps both your e2e backup keys as well as the cross signing keys we go and set up the keys there and I'm done my QoDAS storage is now set up and this on Bob's side let me go and try to start chat with Bob10 on arisfer.net there he is and hopefully in comes a DM from Alice you start chatting and everybody notice the end-to-end encryption is enabled by default so I do not have to do anything so obviously I haven't trusted Alice yet so she's coming up with black shields and likewise Bob is trusting Alice so let's go into here and start off with a plain old verification Alice obviously trusts herself which is reassuring and this is the new UI for Bob for verifying Bob you can go and verify there hit start verification like so and look entirely new UI we've got the verification coming in in the timeline here we've also got a toaster pop-up thing in the top left let me go over here and accept it and here are our funky new QR codes now I'm going to have problems trying to scan my right web from my right web with my right web without a mirror and in practice we haven't implemented the webcam scanning yet on right web so I'm going to fall back like the good old days to verifying by emoji and hey presto we've got cloud dog panda blah blah blah blah I'm going to say matches and matches here and now this is something I was mentioning earlier where you have to enter your master passphrase at this point on right web at least to go and persist the data in basically to persist encrypted on the server without storing this passphrase and caching it around the place locally so let me do that and hey presto Alice and Bob trust each other now so far it's not that exciting because there's only one device on Bob and Alice's side and if we click on the one verified session we can say hey there's one on Chrome there and another on Chrome there what would be really fun is if we file up right X so hopefully I've got a right X sitting about here somewhere where's it gone not telegram that's the wrong one so here is right X going to get started there with me whilst I go and log on and if you haven't seen the registration flows I'm going to try to remember how to use Android talk amongst yourselves briefly going to try to get on to Arisfur I'm going to log in as Alice 10 so the left hand user here good job I'm logged out of WhatsApp Alice 10 top secret password and hopefully welcome to the beta verified the session now new UI on Alice's side verified device coming in I'm going to hit verify here on Android and I'm going to say well hang on a second is that me I want to review it now and it says oh okay I can basically I can verify the new login I'm going to click okay and up comes the QR code and Android you can do it either way so Android is giving a QR code that we could scan if we were doing right X to right X in practice I'm going to hit scan the code here give right X access to do its thing that comes the QR code put that there and done that was it so the really really exciting thing is that if you go and look at Alice's devices here there are now two verified devices that's not so surprising because I just self verified myself and hopefully if I go and look on this side Bob can see both devices cross-signed with one another so we've got the mobile thing here as well as the web so cross-signing is here it's pretty young we finished it in the bar at the hotel about 2am and so may still be some minor issues to be resolved on it the most obvious ones are the you really want to initiate cross-signing from Riot Web that's because we haven't implemented SSSS on mobile yet so whilst you can participate in cross-signing you can't store the data on the server so you end up with a slightly brain-damaged world where the device builds up a local store even though it still trusts things which are being advertised also irritatingly it turns out we've got a minor bug on Federation that means if you cross-sign across servers there's some bug we haven't found yet it'll be fixed in the next couple of days so that's where things are at right now let me just show you one other quit thing which is to go back to my real account if I can find it and I was going to try to show that this isn't Snakehall but I went to Nat who designed all of the UX like a year ago on this and it's taken us all year to implement it and vaguely get it to work and so I haven't verified him yet and so I'm going to actually risk going and hitting the verify button for real hit the start verification button and hopefully on right X hopefully he's going to get his verification request coming in yep there it is except except please accept me there we go yep there it is and go and scan the thing and you can do it the camera refusing to focus on the QR code the problem is it's oversensurated and do that ah your camera sucks so I'm going to end up with me breaking my neck going back to the office come on you can do it I don't know what phone is this as we said the QR code is quite complicated at the moment because it has all of those public keys sitting in it probably provides an alternative it basically takes the emoji and puts them in it which would be a lot smaller but it means you have to go back and forth a couple of times but I'm going to blame your phone clear the lens that was it for the cross-signing demo I've got what two minutes or something to try to show how to break this which is going to be ambitious I might just talk even faster breaking matrix our threat model basically went for it earlier we protect our data as well as we can we want our ability and protection from replay attacks we don't protect compromise clients we don't protect metadata yet but if you came to the p2p tour earlier you have seen that we're working on doing that by moving the service client side we don't give you perfect forward secrecy unless you really want it because in practice it's useful to get at your history on a new device sure it means attackers can also get at your history but in practice it's more useful to have a Slack where you can still get at your not what's that, Slack or I know telegram style experience where you can get at your history you also don't get transcript consistency currently which is not generally a massive concern but the decentralized nature of matrix means that it's okay for different people to have different views of a room because of a net split so that could possibly be exploited by people like deliberately taking messages out of context but it comes with the territory at the moment so lots of ways we could attack this we could man in the middle of CSAPI we could steal an access token we could try to add ghost devices and try to get them trusted so fake devices we could try to add malicious backups which is quite an interesting attempt back to given we have these e2e backups a malicious sysmon could say of course you can trust me to go and back up all your mega-aum keys onto my backup you can try to exfiltrate the keys from the clients which I don't have any time to show you but it was basically running MITM proxy as an example with a bad CA to inset all of your HTTPS traffic and start stealing access tokens and the reality is you can see the metadata for sure you can steal an access token but without the AUM keys from the device you're fine you could also try to steal the password and hijack which could be useful for social engineering verification that's probably the nastiest attack that we have there at the moment we're looking at doing what we call cryptographic login where rather than passing the password in plain text in TLS obviously over the CSAPI you instead sign something with your private key probably your SSSS private key but we haven't done that yet mainly because it would be really complicated for developers whereas today it's quite nice that you just post your username and password and you're in we'll probably support both so secure clients can do the more secure approach adding ghost devices yeah, a compromised server can start creating devices and we just saw with cross-signing that it should all come up as a big scary rad shield you can try to then social engineer people and say don't worry about verifying out a ban just go and tell me the emoji or send me a picture of the QR code and it will be fine so there's always a risk of social engineering attacks within that to force the malicious device to be verified and a really interesting one that I've been obsessed with much to everyone's annoyance has been shoulder surfing the QR code whilst I was messing around trying to scan that code what if a malicious system in the room has compromised my server is also scanning the QR code and saying no wait absolutely they would have to inject a malicious device so that you're actually scanning a different device to the one that you thought you were verifying and you would need to go and send the message back to the other guy that you have scanned that code in practice we mitigate this by doing the outer band verification as well as the in-band verification that it was then that scanned the code so every time in future you scan somebody on QR and it says did they actually did you actually scan the right person it's really important that you do look at the other person's phone and see whether it's got a big green shield on it before you say yes of course I signed the person I thought I was signing what else goes back ups we signed them with the creator's own signing key and only trust them if we trust that device so backup trust uses the same trust model that we have elsewhere exfortrating keys probably the worst attack here is brute forcing the passphrase on the server so if you're worried about that either make sure you use secure passphrases and we're looking at ways to enforce that in the client or just don't use it you could also try to exfortrate the message keys you really should be using protected storage but if there isn't protective storage like there basically isn't on the web platform then in the end if you have an XSS and somebody steals the keys you're screwed game over obviously the famous XKCD is all very well going on about these amazing attacks and complicated vulnerabilities but in practice the likelihood is that somebody's going to hit you with a wrench and so they tell you you tell them the password MLS we're experimenting with it if you don't know what MLS is go check it out decentralized MLS is a variation that we're playing with where we go and decentralize the current centralized sequencing function so that it works with matrix it's very early days it looks promising it could be revolutionary in terms of shifting the linear complexity to the logarithmic complexity that you get with MLS other stuff metadata mention that right X1.0 coming up real soon now first time user experience on right web is our big big big thing in the coming months because we've spent a lot of time focusing on E2E now we need to get the rest of the app looking as sexy as the new E2E flows communities have to be reworked that's next on the list after that and then a whole bunch of other things probably the most exciting is the P2P work also dendrite development is running again one of the original dendrite developers Keegan has come back to work full time on matrix as of last week and so we should see both work from him and other folks in the P2P world also reputation work has to be done otherwise we're going to have really interesting social problems like Twitter does today going forwards and that's it, thank you thank you Matthew I hope an essay is scared so now Q&A please again if you want to exit crowd very silently or just better stay in places and one person, one question and please raise your hands in advance so, yeah, I will move around and I will start Hi, first of all I want to thank you very much for all of your hard work on this and it's amazing software and it's come so far I've watched it evolve and it's just amazing but I was curious as just kind of a question about like all this cross-signing stuff is absolutely wonderful I was wondering if you had any thoughts about the admin user of a Synapse instance being able to pre-verify devices so for example, like in an organization or something if you have a company provided devices if you could have the admin user be the only trusted user and sign devices on a device by device basis well, first of all, thank you for kind words about it and I should say also thank you to the whole matrix team who have been killing themselves trying to get this thing out the door, I've had very little to do with basically any of this other than writing some slides at the end of it and screwing up the demos thanks to the matrix guys in terms of the actual question yes, we designed the use case where as a special case you can have a very limited web of trust where if you want to delegate your trust to some other user like assistant man who has provisioned your device then you would at the protocol level today be able to sign well, they would be able to sign off on you and if you chose to sign them rather than having to manually do it you'll be able to do that it's a bit of an edge case we don't have it in the UX today you saw what a nightmare the UX is to get right just for the kind of simple flows without also having on now we've got a new class of user who can sign off on people but from an enterprise from a government perspective I'm sure you can imagine the France who have been end to end encrypted since April of last year quite interested in the idea where when you onboard somebody into a company or department there's just one person who is trusted to go with the QR code rather than everybody having to be a fun thing socially to do got to meet everybody in the company to kind of verify but not always practical if you're five and a half million public sector employees in France hey so you mentioned the really sensitive Quad S key what kind of key is that and is there the potential to store that on a smart card or a Yuba key in the future? so it's a Curve 25519 key pair and the private side of it could absolutely be stored somewhere safe one of the reasons we haven't implemented SSSS on mobile is that we want to do it right we don't want to just chuck the private key on the file system we want to integrate with whatever the correct latest Android and iOS secure API style so that you have to do face ID or touch ID or whatever to get to it and the next step beyond that would be to integrate with web authentication or whatever the web API style so you can put it down onto a smart card or a tracer or whatever you're playing with so yeah we want to but this is pretty new thank you so much for working on the user experience for secure messaging it's such a hard thing to get right and in the free world we've struggled with this for so long my question is sort of similar what are your thoughts about separating the UX for the master key versus the master master key or the QADES key yeah well as you kind of saw the only UX exposed to the user here is the top of the pyramid it's the master QADES key previously it was the next level below the backup key but when you upgrade an existing account to use this there is a bootstrapping flow which is basically hey you need to enter your passphrase again and then you never see the UX for the next layer down but you're so right that we were idiots honestly back in 2015 when we first announced this and we'd gone and got it audited and we got old and mega old we've done the cryptography how hard can this be and it turns out that it's 98% UX and 2% cryptography and nobody seems to literally spell it out that literally but no big give us now for having an amazing smartphone and also for going through the nightmare of designing the UX for it hey thanks to you and the matrix team for making matrix and especially for the crawl sign because I've been waiting for that for years so my question is particularly related to the unable to the crypt messages I saw that in 1.10 you're going to be hiding messages sent before the person joined the room but there is a common use case which is normally at least before you would turn on and to an encryption and then you'll say hey I turned on encryption how's everything what you're doing but the thing is the person hasn't joined the room yet so those messages are all unable to the crypt and now that it's enabled by default if I say hey they're not going to be able to read that message because they're not in here so in theory that should work for the last year or so because I wrote it in practice people sometimes ask this question which makes me wonder whether it doesn't work certainly for the first couple of years matrix it was a very common failure mode you'd DM somebody turn on encryption send some messages they'd join and they'd say hmm and you'd have to copy base it and look awful it really really upset me to the extent that I went and got into the depths of setups and basically it tries to preemptively share your keys when you invite somebody rather than when they join there are a couple of edge cases which can go a bit wrong because basically if the person's on another server you don't know and they're not in any rooms on your server you don't know what devices they have so you can snapshot it but there's no reason why they should continue to tell you device stuff until they've actually joined a room otherwise you have a dust factor where I could invite everybody in this room to my random server and they wouldn't have to accept the invite just the active inviting would be enough to get them to start telling me all of their device data and on the plus side it means I can encrypt messages for all of those people whether they want it or not but in practice I might wait for them to join so basically it should work if it doesn't it's worth filing a bug and I'll go and try to work out what I did wrong okay yeah so you might have hit that edge case honestly to fix that we probably need to fix how device list synchronization works entirely it's back to the original problem that I was talking about is the fundamental mega problem that the device list data and the key replication doesn't follow the path for the messages so you can end up with messages that have gone somewhere but the keys haven't got there yet hi thank you for your work and you mentioned in the beginning that metrics or one of the main goals of metrics is bridging together different protocols and coming from the XMPP community I'm also very interested in that but that kind of is an orthogonal goal to end-to-end encryption so I'm wondering if do you have plans on cross protocol end-to-end encryption like I think MLS kind of touched on that with the federation document in the workgroup but are there plans to I don't know have like a common message format protocol that you can use to send rich content messages from XMPP to metrics for example so the cryptographic layer I really want to be speaking the same language as everybody else it's why we implemented OM as a clone of LibSignal protocol so that we were speaking the same thing that MAMO was that Signal, WhatsApp, Skype all these different projects had adopted the same cryptographic level layer but the problem is the application layer on top is completely orthogonal to the crypto transport belief it and so it's all very well speaking the same dialects the sort of line almost the transport layer or obviously the message layer security in the case of MLS whereas in practice you're going to need to either convert between XMPP stanzas and matrix events and the totally different semantics of the two different protocols or you have a multi-headed approach effectively where the client needs to speak both which is feeling increasingly icky so our solution to this is to look at client side bridging and it's something that the P2P stuff really helps us towards it's not quite a multi-head client it's not a multi-head messenger like game or whatever games called nowadays and Trillion or whatever instead it's that you'd have your matrix fine sitting there and if you want to run a byfrost which is our matrix to XMPP bridge and you want to run it locally on the laptop or even on your phone then you can plug these relatively lightweight bridges in locally and it will go and encrypt over the matrix or it will tool XMPP natively out from that keeping the encryption intact so we've been playing with it a bit and there are people who are actually looking at doing this quite seriously and we also want to federate as well as we can bridge I should say as well as we can with XMPP and at least have the clear text re-encryption domain under the users control rather than some horrific bridge in the sky somewhere which is reading everyone's traffic so thanks for the amazing work and initiative being done on matrix my question is how is the user experience going to be for revoking or untrusting other devices yeah different devices from your own account that you don't recognize anymore as being secure and then what happens if the network partitions is the remote server going to continue encrypting the remote client excellent question so basically where is the untrust button on the UI and the fact is that we haven't implemented it on the new UI we had it on the old UI and there's literally a bug that we still have solved and it will stop us, it's a release blocker before we actually push this out of all the developed ones that we cut yesterday in terms of how that works with federation well that's more for a local question this is a causality thing if a tree gets unverified in the woods and no one is there to see it did it really get unverified likewise if there's a net split and I happen to have verified myself here and you physically can't see it because you're not physically connected to me I'm sorry but matrix is amazing but we haven't quite solved that causality problem yet I'm working on it in VR with ping pong but that's an entirely different story but further on the question about an admin signing people in the room could you have degrees of trust based on how many people that you trust trust someone new the reason we haven't done that is because of metadata leak you start to build a social graph you start to build a PGP style web of trust and if you ever looked at the PGP web of trust A it's terrifying because there are so many completely weird bot light things which have never verified anybody in it and the rest of it is terrifying because it's a really direct social graph of every human on the planet who's a real geek who's gone to a FOSTA PGP signing party in order to shake hands with people and that's quite valuable information so we do not want to build up a big web of trust even with indirect degrees of separation on the reputation side of things totally separately to cross-signing though we are looking at doing stuff like this in a privacy preserving manner using pseudonyms rather than real users and using per room pseudonyms so that you get a different MXID for every conversation your own and so if somebody is a complete jackass in a given room that particular MXID might be marked down but it doesn't necessarily correlate to their activity elsewhere and you basically can have a fuzzy gray list web of trust of sorts which is anonymized like that which is sufficient to allow you to do community analysis to say hey that guy's a complete jackass and hangs out with a lot of other jackasses and I'm going to stick a pin in the middle of the jackass cluster and I'm going to mute it and that is not quite trust but it's a more answer to a different question okay thank you Mathew I think you can reach Mathew on matrix easily so and ask other questions to him thank you very much for a very interesting presentation