Making & Breaking Matrix's End-to-end encryption
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 490 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/47438 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
TelecommunicationData modelMatrix (mathematics)EncryptionEncryptionSpecial unitary groupBitMultiplication signMatrix (mathematics)DatabaseTelecommunicationReal-time operating systemLine (geometry)Right angleSoftwareUniform boundedness principle
01:00
Matrix (mathematics)Real numberOpen setTelecommunicationComputer networkComputing platformTelecommunicationServer (computing)DatabaseInternet der DingeWeb 2.0BitHierarchySoftwareOpen setReal-time operating systemComputing platformStandard deviationMatrix (mathematics)Client (computing)Polygon meshBridging (networking)Data conversionService (economics)Matching (graph theory)Computer animation
02:02
Matrix (mathematics)ArchitectureSanitary sewerIdentity managementServer (computing)Client (computing)Local GroupEncryptionRule of inferenceMotif (narrative)Repository (publishing)Content (media)Data conversionMatrix (mathematics)Server (computing)SoftwareRepository (publishing)Identity managementGroup actionMessage passingSingle-precision floating-point formatCartesian coordinate systemClient (computing)Computer animation
02:44
Matrix (mathematics)Local GroupEncryptionServer (computing)Rule of inferenceMotif (narrative)Content (media)Repository (publishing)Default (computer science)EncryptionGroup actionData conversionRatsche <Physik>Matrix (mathematics)Revision controlParity (mathematics)Doubling the cubeAlgorithmCAN busLine (geometry)Multiplication signSubject indexingRight angleGoogolComputer animation
03:27
Matrix (mathematics)Local GroupEncryptionRule of inferenceServer (computing)Motif (narrative)Content (media)Repository (publishing)Service (economics)Scalable Coherent InterfaceAndroid (robot)Point (geometry)Term (mathematics)BitElectronic signatureMatrix (mathematics)AverageCategory of beingMoment (mathematics)EncryptionScalabilityFocus (optics)Service (economics)Sampling (statistics)TelecommunicationInternettelefonieClient (computing)Android (robot)HorizonCrash (computing)Mobile appCartesian coordinate systemBridging (networking)CountingPhysical systemInsertion lossWritingServer (computing)Computer animation
04:57
Matrix (mathematics)Message passingServer (computing)EncryptionStatisticsDifferent (Kate Ryan album)Server (computing)Android (robot)Message passingPressureImplementationParabolaTerm (mathematics)Set (mathematics)Projective planeScaling (geometry)DreizehnRadio-frequency identificationMatrix (mathematics)Computer animation
05:53
Matrix (mathematics)Default (computer science)Level (video gaming)Server (computing)Transport Layer SecurityIdentity managementFormal verificationSurfaceServer (computing)Identity managementService (economics)Matrix (mathematics)Scaling (geometry)Metropolitan area networkData conversionSurfaceEncryptionKey (cryptography)Software frameworkComputer animation
06:45
Ratsche <Physik>Key (cryptography)Formal verificationData recoveryBackupDefault (computer science)Client (computing)Matrix (mathematics)View (database)Subject indexingError messageSynchronizationIdentity managementFlash memorySlide ruleSign (mathematics)Right angleClient (computing)Direct numerical simulationData conversionPhysical lawMatrix (mathematics)Formal verificationRandomizationHacker (term)RobotComputer fileDocument management systemComputer animation
08:03
Matrix (mathematics)Client (computing)Bus (computing)Data managementInterface (computing)Online chatDemonComponent-based software engineeringCompact spaceDemonServer (computing)Matrix (mathematics)Proxy serverRandomizationScripting languageInterface (computing)Data managementWritingMaterialization (paranormal)Physical systemData conversionGroup actionRight angleUltraviolet photoelectron spectroscopyClient (computing)ImplementationService (economics)Computer animation
09:01
Matrix (mathematics)DemonClient (computing)Bus (computing)Data managementInterface (computing)Online chatComponent-based software engineeringCompact spaceMatrix (mathematics)Client (computing)ImplementationProjective planeSoftware frameworkEntire functionStack (abstract data type)FraktalgeometrieSoftware developerCASE <Informatik>Video gameData structureMultiplication signComputer animation
10:16
Execution unitClient (computing)Message passingSubject indexingWeb-DesignerRight angleSystem callWeb 2.0Software development kitSimilarity (geometry)ExistenceMultiplication signMatrix (mathematics)Projective planeFreewareSoftware testingCASE <Informatik>Computer animationSource code
11:19
AngleMenu (computing)SynchronizationSimulationInclusion mapSalem, IllinoisMatrix (mathematics)Software testingLine (geometry)Point (geometry)Client (computing)Connected spaceMatrix (mathematics)Server (computing)Computer virusFormal verificationSign (mathematics)Source codeComputer animation
12:08
Matrix (mathematics)Client (computing)Bus (computing)Data managementInterface (computing)Online chatDemonComponent-based software engineeringLibrary (computing)Message passingSubject indexingStandard deviationPrice indexMiniDiscEncryptionThread (computing)Data storage deviceWrapper (data mining)Formal verificationWeb 2.0Java appletKeyboard shortcutCross-platformDifferent (Kate Ryan album)Matrix (mathematics)Multiplication signMessage passingServer (computing)EncryptionSubject indexingClient (computing)RandomizationSoftware developerHomomorphismusStability theoryLaptopBuildingProduct (business)Basis <Mathematik>Branch (computer science)Exception handlingModule (mathematics)RobotMiniDiscThread (computing)Structural loadDemosceneWeb crawlerRight angleSequelVideo gameGradientSearch engine (computing)Service (economics)Source codeComputer animation
14:57
Vector spaceMIDIMatrix (mathematics)Office suiteTerm (mathematics)Uniform boundedness principleLocal ringPoint (geometry)Web 2.0Computer animation
15:39
MathematicsMatrix (mathematics)Message passingCore dumpKey (cryptography)SynchronizationComputer networkPartition (number theory)Term (mathematics)Server (computing)Maximum length sequenceDistribution (mathematics)Error messageSeries (mathematics)Right angleMessage passingBijectionTelecommunicationBitDifferent (Kate Ryan album)Key (cryptography)Server (computing)Core dumpEncryptionComputer architectureService (economics)AreaSource codeComputer animation
16:40
Matrix (mathematics)Message passingCore dumpKey (cryptography)SynchronizationComputer networkPartition (number theory)Term (mathematics)Server (computing)Maximum length sequenceDistribution (mathematics)Error messageSeries (mathematics)EncryptionElectronic mailing listSanitary sewerClient (computing)SharewareGraph (mathematics)Sign (mathematics)Complex (psychology)Server (computing)MereologyInformationClosed setDenial-of-service attackNP-hardMechanism designTrailSocial classCache (computing)Client (computing)BitProper mapDifferent (Kate Ryan album)Message passingMatrix (mathematics)Link (knot theory)NeuroinformatikNetwork topologyPolygon meshDistribution (mathematics)Key (cryptography)Row (database)AlgorithmQuicksortSoftware bugINTEGRALElectronic mailing listData recoveryWeb 2.0Point (geometry)Synchronization1 (number)Matching (graph theory)AreaTerm (mathematics)Presentation of a groupHeegaard splittingDigital photographyRational numberComputer scienceFilm editingSign (mathematics)Validity (statistics)Multiplication signSharewareComputer animation
20:07
Matrix (mathematics)SharewareGraph (mathematics)Sign (mathematics)Complex (psychology)BitMultiplication signMathematicsMatrix (mathematics)Sign (mathematics)Key (cryptography)Centralizer and normalizerLoop (music)Computer animation
21:03
Matrix (mathematics)SharewareWhiteboardKey (cryptography)Sign (mathematics)Server (computing)Similarity (geometry)Message passingData storage deviceSynchronizationPublic-key infrastructureSurjective functionDifferent (Kate Ryan album)Key (cryptography)Proxy serverLine (geometry)MathematicsData structureSign (mathematics)Server (computing)Web 2.0BackupElectronic signatureLevel (video gaming)Flow separationSoftware bugInstance (computer science)19 (number)Heegaard splittingMatrix (mathematics)Data storage deviceUsabilityFormal verificationService (economics)Multiplication signComputer animation
22:59
Matrix (mathematics)Data storage deviceData recoveryBackupComputing platformEncryptionKey (cryptography)Matrix (mathematics)Data storage deviceBackupMultiplication signProxy serverData recoveryInformation securitySign (mathematics)Network topologyMereologyPublic-key cryptographyWeb 2.0BitOrder (biology)Computer animation
24:24
Matrix (mathematics)Proof theoryFormal verificationOrder (biology)Social classSuite (music)Game controllerMathematicsLengthComputer animation
25:07
Game controllerAndroid (robot)Figurate numberFrame problemDataflowBitSocial classMetropolitan area networkSound effectWeb-DesignerVisualization (computer graphics)Right angleComputer animationProgram flowchart
25:54
Matrix (mathematics)Formal verificationCodeKey (cryptography)Message passingMathematicsDataflowFormal verificationVisualization (computer graphics)QR codeMetropolitan area networkModal logicPublic-key cryptographyKey (cryptography)Lipschitz-StetigkeitMobile WebCodeMedical imagingMoment (mathematics)Interactive kioskMusical ensembleComputer animation
27:09
Matrix (mathematics)Default (computer science)Client (computing)Subject indexingSynchronizationError messageEncryptionIdentity managementFormal verificationAndroid (robot)Vector spaceChemical equationMenu (computing)Sign (mathematics)Right angleSoftware developeroutputWeb 2.0Random matrixWindowMultiplication signArithmetic meanDifferent (Kate Ryan album)Address spaceCodeServer (computing)Computer animationSource code
28:00
PasswordDataflowMessage passingKey (cryptography)Default (computer science)EncryptionQuadrilateralFormal verificationData recoveryBitBackupData storage deviceLine (geometry)Disk read-and-write headCodeCASE <Informatik>Sign (mathematics)Computer animation
29:38
WebcamWeb 2.0QR codeEvent horizonCoefficient of determinationBranch (computer science)Right angleEncryptionSparse matrixFreezingService (economics)Computer animation
30:23
Hill differential equationGraphical user interfaceMathematical analysisPasswordImage registrationAndroid (robot)Goodness of fitProcess (computing)Cartesian coordinate systemRight angleComputer animationProgram flowchart
31:41
DreizehnBeta functionInformation securityExecution unitEncryptionMaize2 (number)QR codeAndroid (robot)CodeCartesian coordinate systemWritingComputer animationProgram flowchart
32:24
Information securityCodeMultiplication signMobile WebComputer animationProgram flowchart
33:06
Default (computer science)EncryptionAndroid (robot)Matrix (mathematics)Menu (computing)Software bugWeb 2.0Data storage device1 (number)Server (computing)Sign (mathematics)Right angleEvent horizonFormal verificationGoodness of fitComputer animationProgram flowchart
33:47
Formal verificationMatrix (mathematics)QR codeSubsetSharewarePhysicalismReal number
34:59
Multiplication signOffice suiteMoment (mathematics)Public-key cryptographyExterior algebraQR codeSign (mathematics)Endliche ModelltheorieSound effectMatrix (mathematics)Computer animation
35:42
Matrix (mathematics)Model theoryTransport Layer SecurityServer (computing)Client (computing)Perfect groupConsistencyClient (computing)Matrix (mathematics)Natural numberDifferent (Kate Ryan album)ConsistencyControl flowMessage passingHeegaard splittingServer (computing)View (database)Moment (mathematics)Context awarenessArithmetic mean2 (number)Service (economics)Computer animation
36:45
Matrix (mathematics)Transport Layer SecurityToken ringBackupKey (cryptography)Server (computing)Client (computing)PasswordSpywareFormal verificationCodePlastikkarteMusical ensembleDatabaseMessage passingSocial engineering (security)Moment (mathematics)BackupPhysical systemToken ringClient (computing)Key (cryptography)Vector spaceProxy serverSharewarePasswordServer (computing)Social engineering (security)QR codeMultiplication signInformation securityAlgebraField (computer science)WordType theoryImpulse responseSoftware developerSimilarity (geometry)CodeFormal verificationSpywarePublic-key cryptographyMusical ensembleComputer animation
38:52
Matrix (mathematics)Server (computing)CodePlastikkarteFormal verificationMusical ensembleDatabaseMessage passingSocial engineering (security)Key (cryptography)BackupControl flowClient (computing)Data storage deviceGame theoryCodeFormal verificationRight angleMultiplication signQR codeMessage passingKey (cryptography)Sign (mathematics)Shooting methodDressing (medical)Ultraviolet photoelectron spectroscopyEndliche ModelltheorieCASE <Informatik>Data storage deviceClient (computing)Web 2.0Pulse (signal processing)Information securityFreezingTouchscreenForcing (mathematics)Computing platformGame theoryServer (computing)Computer animation
40:12
CryptographyEncryptionMatrix (mathematics)Maximum length sequenceInformation securityKolmogorov complexityNetwork topologyPolygon meshGame theoryLikelihood functionVulnerability (computing)Term (mathematics)Bounded variationComplex (psychology)Matrix (mathematics)Computer animation
40:54
Matrix (mathematics)Canonical ensembleLoginCryptographyWeb 2.0Mobile appComplex (psychology)DataflowMultiplication signSoftware developerRight angleElectronic mailing listMatrix (mathematics)Point (geometry)Suite (music)Computer animation
41:40
Matrix (mathematics)NP-hardSoftwareTwitterFerry CorstenHand fanComputer animation
42:23
Matrix (mathematics)System administratorSelf-organizationInstance (computer science)WordSign (mathematics)Basis <Mathematik>NumberDataflowSocial classCASE <Informatik>Term (mathematics)AuthenticationLevel (video gaming)Web 2.0BitPlastikkartePublic-key cryptographyTouch typingQuadrilateralKey (cryptography)Limit (category theory)CurveComputer fileEnterprise architectureMatrix (mathematics)Sensitivity analysisSlide ruleSharewareCommunications protocolPhysical systemRule of inferenceCodeINTEGRALWhiteboardPerspective (visual)Computer animation
45:05
Matrix (mathematics)Communications protocolSoftware bugCASE <Informatik>Electronic mailing listFundamental theorem of algebraEncryptionMatrix (mathematics)Server (computing)Message passingVector spaceBackupQuadrilateralPlanningComputer networkFile formatFormal languageKey (cryptography)Replication (computing)Metric systemSynchronizationInformation securityPlastikkarteSign (mathematics)Content (media)BootingDataflowTheoryCloningProjective planeLevel (video gaming)Asynchronous Transfer ModeExtension (kinesiology)Line (geometry)Dynamical systemBitWaveCartesian coordinate systemProduct (business)Group actionCryptographySmartphoneInsertion lossTournament (medieval)OvalComputer animation
49:53
Matrix (mathematics)Client (computing)Matrix (mathematics)Semantics (computer science)Communications protocolCryptographyInformation securityDialectMessage passingCASE <Informatik>Event horizonCartesian coordinate systemGame theoryMultiplicationComputer animation
50:43
Matrix (mathematics)Line (geometry)Public domainBridging (networking)Matrix (mathematics)LaptopBitGame theoryBit rateEncryptionWeightComputer animation
51:37
Matrix (mathematics)Software bug1 (number)PseudonymizationDifferent (Kate Ryan album)Data conversionRemote procedure callFuzzy logicDegree (graph theory)Flow separationSign (mathematics)Information privacyElectronic mailing listWeb 2.0Term (mathematics)QuicksortMatrix (mathematics)Partition (number theory)Order (biology)MetadataLeakSystem administratorNetwork topologyServer (computing)CausalityMathematical analysisHeegaard splittingPersonal identification numberFaster-than-lightSoftwareReal numberClient (computing)Graph (mathematics)InformationComplete metric spaceInformation securityDirection (geometry)Cellular automatonOpen sourceArithmetic meanMusical ensembleUniform resource locatorWordPoint (geometry)Formal verificationComputer animation
54:44
Point cloudOpen sourcePresentation of a groupComputer animation
Transcript: English(auto-generated)
00:06
So, Matthew Hudson will talk to you about matrix end-to-end encryption. Thank you very much. Welcome. Hi. Can you hear me? Thank you.
00:21
Can everybody hear me alright? 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.
00:40
Okay. Very quickly, I'll try to give a very rushed explanation of matrix. Apologies to people who came to the earlier talk. It is identical to try 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.
01:04
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.
01:21
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 comms network which is standards-based and provides an open platform for real-time comms, just like the web, but for real-time communication. One way to think of it is if you have the silos of the various different proprietary or not proprietary islands of communication today.
01:44
Matrix can sit in the middle as 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 by matrix in the middle.
02:03
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.
02:24
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.
02:43
What do you get in the spec? You get some decentralized conversation history. Group messaging is 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 LibAxolotl at the time.
03:02
We implemented our Apache license version of it. And then we added MegaOM 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.
03:23
Because 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 the liability or in terms of the signatures to prove that people said these things.
03:40
But in the end, it also has scalability issues that we have room to matrix with over 100,000 users in them. Each user averages about two or three devices, so that's 300,000 endpoints. And we're focused at the moment of making matrix kickass 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
04:04
expect to get from a modern communication app like WhatsApp or Slack or Discord. Ecosystem, you have the spec, you have the servers, the bridges, the application servers, and then you have the clients. Worth noting that Riot X here is almost at the point of replacing Riot Android.
04:21
We are entering the 1.0 release basically now. We have released candidates on the horizon over the coming weeks. I think we just shipped Riot X 0.14.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 Riot X on Android, please give it a whirl, particularly as it
04:45
has a lot of the end-to-end encrypts and 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, like unrecognizably better than Riot Android.
05:02
In terms of uptake, daily active users are following this interesting parabola over the last three years. Not much really to say about that, other than it puts a lot of pressure on us to make sure that the server implementations scale. And overall community stats are 13 mil global MXIDs, about 5 million messages a day that we can see,
05:24
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.
05:44
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 them on 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.
06:02
Finishing E2E and matrix. First of all, E2E by D4 is obviously really important for various different reasons. First of all, we're replicating conversations everywhere in 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.
06:22
Also, we want to protect ourselves from compromised servers in general. That might be malicious specimens, 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.
06:44
And we actually started this whole final leg 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 FOSDEM in 2017, where we said this is what we need to do in the next couple of years to get E2E turned on.
07:02
And as of 2019, we got 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
07:24
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 default. 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.
07:41
Cross-signing, absolutely critical, as everybody in this room knows, apart from 7, it's really annoying in matrix when somebody joins the 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,
08:04
but specifically making this as easy and smooth as possible. So, in turn, Pantalimon, who knows what Pantalimon is? Okay, about half the room. So Pantalimon is obviously Lyra's demon from His Dark Materials. Also, it's an end-to-end encrypted demon that offloads all of your E2EE.
08:25
So the idea is that if you're writing some random little matrix, throwaway script or new client, and you can't be bothered to write an audited, massive, complicated E2EE 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.
08:41
It's written in Python in AsyncIO using the no IO style, which is basically you abstract all the IO away and then plug it into AsyncIO at the last minute. It provides management interface by dbus, 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,
09:02
hey, do you want to verify the new user in this conversation, even when you're not using an E2EE-capable client? It's actually the same stack as WeChat matrix. It's written by a chap called Damir. Nick is Polyar on matrix. He originally was doing WeChat matrix, and it was really, really cool. He wrote his own Python implementation of E2EE and an entire matrix SDK,
09:25
and so he said, hey, Damir, why not come and work on matrix full-time and come and work on Pantalimon? So that is where Pantalimon has come from. And most excitingly, and I didn't ask his permission to reveal this, but it's the case, if you look on GitHub, that he's busy rewriting, first of all, WeChat matrix in Rust
09:43
using rumor as the client's framework and structures, and also we're using OMRS, which is the native Rust implementation of OM that has come from the fractal developer community. Huge thanks to BrainBlasted and Johannes Hayes for re-licensing,
10:02
and the other contributors for re-licensing 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 this stack that can be used in Pantalimon in future and other clients. So that's Pantalimon. Let me quickly show you it.
10:21
Risky live demo. You know how well these are going today. So here is Pantalimon, just sitting here in the background. It's going and decrypting sinks. 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.
10:42
So 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, who's one of 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.
11:03
And we're experimental. He's experimenting with it as a full-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, talking through to me, is at matheonmatrix.org. And if I say, hello Matthew,
11:21
it goes and sends. You can see that it's been sent there. And I go through to here, 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 seven. I can respond back with hello,
11:41
and assuming I have enough connectivity and if matrix.org server is working, yay, there you go, you get the hello. Yay, coming 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 Pantalignment. 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
12:00
and try to verify Matthew's seven 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 gonna try to do this by cross-lining voodoo and not actually make it through to Pantalignment. It hasn't, but basically Pantalignment does support verification pre-cross-signing,
12:20
and obviously in the near future it will support cross-signing too. So that's Pantalignment. 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 kind of managing the matrix.org home server where we want to put in a bot, we just wedge it through Pantalignment so it can be in the encrypted room.
12:41
Cessat, also actually done by Damir, entirely new solution to full text search. Obviously if you're end-to-end encrypting your chat rooms, you can't 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
13:01
Tentaby, 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 has 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
13:21
node wrapper, and then we have matrix Cessat 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 Tentaby does and Cessat does is to spider all of your messages from your encrypted accounts and build up
13:40
a full text search index of it all. So, interesting things that we can do with Cessat is that 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
14:00
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 Tentaby 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 gossip between different
14:20
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 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, it can just pick up the indexes being pre-calculated. So this is shipped now in
14:40
the developed branch of Riot desktop. The only catch is that 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 Wasm doesn't support threads and Tentaby is very heavily threaded, so we can't compile it down to Wasm yet.
15:01
In terms of what it looks like, if I go to some encrypted room, which I probably should have picked beforehand, NuVec limited is where the UK office of NuVec are working on matrix to decide where to go for lunch mainly, and tell each other about caramel and brownie bites. If I go and search an encrypted room like this
15:20
and search for, I don't know, Duke, which is our local pub, apparently we haven't been talking about the Duke. Ah! I'm on Riot web. I should be on Riot desktop. Let me go and just set that going. Not yarn install, run electron. Let me go and fire up Riot desktop. So that's what it looks like today. A few minutes,
15:42
we'll 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 undecryptable messages, and it's got better over the years, I hope everybody will agree.
16:02
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,
16:22
and you can indirectly get them from random servers, and you can have ten servers in the room, and all of them can go down apart from one, and you'll still 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
16:42
on their server between theirs and mine, why should that get relayed and flooded across all the other servers in the room? It's very inefficient. It would be very, it would be basically O n squared, irrelevant signalling clutter. So, two solutions. We could somehow attach it into the DAG anyway, so it does cover the same path,
17:01
but it would flood lots and lots of information everywhere needlessly and slow everything down even more. Or we could switch TAC 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 of the devices in a room, effectively, rather than a full mesh.
17:22
However, short term, in practice, unavoidable key distribution fails where you've had, say, a net split, and the device has 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.
17:41
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 present 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 invalidation,
18:02
of Py1 errors, and the idea, I guess, is that here, they're all different classes of cache invalidation 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 a lot more aggressively.
18:22
If we do discover a cache fail or an 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
18:42
record so far has been three years of a server that came back and couldn't encrypt messages for me or Amandine, 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
19:01
final in probably early next week. We've also improved things a lot around the unavoidable failures. It turns out that one of the most popular reasons for getting an undecryptable message in matrix is somebody had blacklisted you, and you couldn't tell because it was the same, oh, you don't have the keys, and everybody said, oh, matrix is terrible because I didn't get the keys. Well, it turns out
19:21
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 OM session has got wedged because of wig corruption, we tell them
19:41
too. 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 undecryptable 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.
20:02
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, 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
20:21
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 is key. You end up with a great big dag, at least of the user's own devices. And that's what we implemented.
20:42
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 defines A. You've got a loop. What happens if B gets lost? You end up kind of with a fragmented net-splitted trust graph, and what the hell do you do next? Also, there was just no central
21:01
way for a user as a person to just manage that mess, which is basically the same problem. It ends up getting fragmented. So, MSE 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
21:21
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 the 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 them up just for hygiene, because they do different things. It allows you to rotate them separately,
21:41
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, it looks like that.
22:01
A for Alice has got a master key. She's got a self-signing key and a user-signing key. With her user-signing key, she's signed Bob's master key. Bob's master key in turn has signed Bob's self-signing key and his user-signing key, and Bob has a Dynabook and a VAX, which he's signed off on. Alice has a PDP-11, not to be confused with a VAX, and Osborne
22:20
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
22:40
how we handled 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 planning, well, we're doing both. It's called MSC1946. Always weird how these line up with, like, years.
23:01
And it's called QuadS, secure secret storage and sharing. And it works by storing your secrets in 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.
23:20
This time it really is the master-master key. It's your QuadS master key. Single most important one. It replaces the old backup recovery key in passphrase, and in fact, 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.
23:43
So, very similar to key backup, 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
24:02
it to sign with somebody. And this is actually a bit of an annoyance in some ways right now, in that whenever you need to unlock your master secrets in order to write to it, you do need to provide that private key. We're looking at ways to improve this. So, this is particularly annoying on Riot Web because you don't have a safe place to store private keys.
24:20
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.
24:42
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, which means that you went and explicitly verified somebody in that room, but they have now gone and added in a device which is not trusted. So, they're probably being owned. This is bad news.
25:02
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 NAD's wireframes in Figma for, not even wireframes, the actual assets
25:21
in Figma 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 analyzing and designing all of the cross-lining flows that we can.
25:42
This has been implemented in RiotX. It's also landed in TestFlight 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. And hopefully, people will agree, it's a massive step up on the UX and visuals from what we've had before.
26:01
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 bloop than go tango whatever, you know, call out emojis to one another. The way it works is that you basically produce a QR code with all of the keys
26:22
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
26:41
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 Alice and
27:01
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 of the person that you're talking to. So what's blocked us? Lots of things. However, they are now all solved. So, it's now enabled,
27:21
as I said, on Riot Web Develop, Riot X, and Riot 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, B for Bob.
27:41
Let me fire up a new incognito window on a different port or a 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, let me see, Bob 10, so I'm going to create
28:01
Alice 10 with a secret password. And, totally new UI flow already. This is now setting up the SSSS master pass throws. looks and feels a bit like the old
28:20
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. I'm going to set up the keys there, and I'm done. My quad S storage is now set up. I've already done this
28:40
on Bob's side. Let me go and try to start a chat with Bob 10 on arisfer.net. There he is. And, hopefully, in comes a DM from Alice. You start chatting, and everybody notices that this end-to-end encryption is enabled
29:00
by default. I do not have to do anything. So, obviously, I haven't trusted Alice yet, so she's coming up with black shield, and likewise Bob isn't trusting Alice. So, let's go into here, and start off with a
29:21
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 that, 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
29:41
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.
30:00
And, hey presto, we've got Cloud Dog Panda, blah, blah, blah, blah, blah. I'm going to say it matches, and matches here. And, now, this is the thing 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,
30:20
well, basically to persist it, encrypt it 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.
30:40
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, yeah, there's one on Chrome there, there's another one on Chrome there. What would be really fun, is if we fired up Riot X. So, hopefully, I got a Riot X sitting about here, somewhere. Where's it gone? Not Telegram, that's the wrong one.
31:04
So, here is Riot X. Going to get started. Bear with me whilst I go and log on. And, if you haven't seen the registration flows, by the way, on Riot X, it's lovely. I'm going to try to remember how to use Android. Talk amongst yourselves, briefly.
31:22
Going to try to get on to Aerosphere. 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.
31:40
Top secret password. And, hopefully, welcome to the beta, verified the session. Now, new UI on Alice's side. We've got an unverified device coming in. I'm going to hit verify here on Android, and I'm going to say, well, hang on a
32:01
second, is that me? I want to review it now. And it says, oh, okay, I can basically grant this, 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's giving a QR code that we can scan if we were doing Riot X to Riot X. In practice, I'm going to hit scan
32:21
the code here. Give Riot X access to do its thing. Up comes the QR code, put that there, and done. That was it. So, the really, really exciting thing is that if we go and look at
32:42
Alice's devices here, there are now two verified devices. That's not so surprising because I just self-verified myself. But, hopefully, if I go and look on this side, yep, 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
33:00
is here. It's pretty young. We finished it in the bar at the hotel at about 2 AM, and so it may still be some minor issues to be resolved on it. The most obvious ones are that you really want to initiate cross-signing from Riot web. That's because we haven't implemented SSSS on mobile
33:22
yet. So, once 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
33:42
yet. It'll be fixed in the next couple of days. So, that is where things are at right now. Let me just show you one other quick 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 snakehole by going to Nad, who designed all of the UX, like, a year ago on this, and has taken us all year
34:02
to implement it and vaguely get it to work. And, I haven't verified him yet. And so, I'm going to actually risk going and hitting the verify button, for real, on matrix.org. Hit the start verification button. And, hopefully, I'm right, X. Nad, are you out? Oh, there you are. Hopefully, he's going to get his
34:20
verification request coming in. Yep, there it is. Accept. Accept. Please accept me. There we go. So, yep, there it is. And, go and scan the thing.
34:44
Ah, you can do it. The camera refusing to focus on the QR code because it's a live demo. No, the problem is it's oversaturated. If we go and do that. Ah, your camera sucks.
35:03
Yeah, perhaps you should. So, you're going to end up with me breaking my neck going back to his office. Come on, you can do it. Ah, I don't know. What phone is this? Okay, as we said, the QR code is quite complicated at the moment because it has all of those
35:22
public keys sitting in it. And, we're going to probably provide an alternative that basically takes the emoji and puts them in it, which would be a lot, lot smaller, but it means that you have to go back and forth a couple of times. But, I'm going to blame your phone. Clear the lens. Okay, that was it for the cross signing demo. I've got, what,
35:41
two minutes or something to try to show how to break this, which is going to be ambitious. I might just talk even faster. Apologies. Breaking matrix. Our threat model, we basically went for it earlier. We want to protect our data as well as we can. We want our knowability and protection from replay attacks. We don't protect compromised clients. We don't protect metadata yet. But, if
36:00
you came to the P2P tour earlier, you'll have seen that we're working on doing that by moving the server's 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 or WhatsApp
36:20
style experience where you can still get at your, not WhatsApp, 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.
36:40
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 a CS API. We could steal an access token. We can try to add ghost devices and try to get them trusted, so fake devices. We could try to
37:01
add malicious backups, which is quite an interesting attack vector given we have these E2E backups. A malicious system could say, yeah, of course, you can trust me to go and back up all your mega ohm keys onto my backup. You can try to exfiltrate the keys from the clients. I have a whole bunch of demos, which I now don't have any time to show you, but it was basically running
37:20
MITM proxy as an example with a bad CA to intercept all of your HTTPS traffic and start stealing access tokens, and the reality is that you can see the metadata for sure. You can steal an access token, but without the ohm keys from the device, you're fine. You could also try to steal the password and hijack, which could be useful for social
37:40
engineering verification, and 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 CS API, you instead sign something with your private key, probably your SSSS private key, but we
38:00
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, though, 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
38:20
it should all come up as a big, scary, red shield. You can try to then social engineer people and say, oh, 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 the risk of social engineering attacks within that to force the malicious device to be verified. And a really
38:40
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 who has compromised my server is also scanning the QR code and saying, no, wait, absolutely, they would have to inject a malicious device
39:00
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
39:20
that it was then that scanned the code. So every time in the 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 says, yes, of course I signed the person I thought I was signing. What else? Ghost backups, we sign them
39:40
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. Exfiltrating keys, probably the worst attack here is brute forcing the passphrase on the server, so if you're worried about that, make sure you use secure passphrases and we're looking at ways to enforce that in the client or just don't
40:00
use it. You could also try to exfiltrate 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
40:20
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 until they tell you that you told them the passphrase. 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
40:42
playing with where we go and decentralize the current and centralized sequencing function so that it works with matrix. It's very early days, 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.
41:00
What's next? Riot X 1.0, coming up real soon now. First time user experience on Riot 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 a whole bunch of other things. Probably
41:21
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. 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
41:41
really interesting social problems like Twitter does today going forwards. And that's it. Thank you. Thank you, Matthew. I hope NSA is scared. So, now,
42:00
please, again, if you want to exit Crowell Valley 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
42:20
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 this kind of a question about, like, all this crossing stuff is absolutely wonderful. I was wondering if you had any thoughts about the admin user of a Synapse
42:40
instance being able to pre-verify devices. So, for example, like, in an organization or something, if you have company-provided devices, if you could have the admin user be the only trusted user and sign devices on a device-by-device basis. Yeah, for sure. Well, first of all, thank you for kind words about it, and I should say
43:02
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. So, thanks to the Matrix guys. In terms of the actual question, yes, we designed
43:20
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 a sysadmin who has provisioned your device, then you would at the protocol level today be able to sign, or they would be able to sign off on you, and if you chose to sign them, rather than having to manually do it,
43:41
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, oh, now we've got a new class of user who can sign off on people, but from a enterprise and also a government perspective, I'm sure you can imagine, the France, who have been end-to-end encrypted since April of last year, are quite interested
44:02
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, you know, be a fun thing socially to do. You've got to meet everybody in the company to kind of verify, but it's not always practical if you're five and a half million public sector employees in France.
44:23
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 YubiKey in the future? So it's a curve 25519 key pair, and the private side of it could absolutely be stored somewhere safe.
44:42
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 APIs are, so that you have to do face ID or touch ID or whatever to get to it. And the next
45:00
step beyond that would be to integrate with web authentication or whatever the web APIs are, 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
45:21
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 quad S key? well as you probably, as you kind of saw, the only UX exposed to the user here is the top of the pyramid. It's the master
45:41
quad S key. Previously it was the next level below, the backup key, but when you upgrade an existing account to use this, there is a boot strapping 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
46:01
announced this and we'd gone and got it audited and we got OM and 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 kudos to Ned for having an amazing smartphone, and also for going
46:21
through the nightmare of designing the UX for it. Hey, thanks to you and the Matrix team for making Matrix and especially for the cross sign because I've been waiting for that for years. So my question is particularly related to the unable to decrypt messages. I saw that in 1.10 you're
46:42
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 end-to-end encryption and then you'll say, hey I turned on encryption, how's everything and what are you doing? But the thing is the person hasn't joined the room yet, so those messages are all unable to decrypt.
47:01
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 hiding yet. 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 of Matrix it was a very common failure mode.
47:22
You'd DM somebody, turn on encryption, send some messages, they'd join and they'd say and you'd have to copy-paste it and it looked 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
47:42
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 send new device stuff until they've actually joined a room. Otherwise you have a DOS vector where I could invite everybody in this room to my
48:02
random server and they wouldn't have to accept the invite, just the act of 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
48:22
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, it's the fundamental MEGOM problem
48:42
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
49:01
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 and 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
49:21
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 at the cryptographic layer we absolutely want to be speaking the same language
49:42
as everybody else. That's why we implemented Alm as a clone of libsignal protocol so that we were speaking the same thing that AMEMO was, that Signal, Whatsapp, Skype, all these different projects had adopted the same cryptographic layer. But the problem is the application layer on top is completely orthogonal to
50:01
the crypto transport belief and so it's all very well speaking the same dialect of 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
50:22
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
50:40
multi-head client well it's not a multi-head messenger like game or whatever game's called nowadays and trillion or whatever. Instead it's that you'd have your matrix line sitting there and if you want to run a bifrost 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
51:00
bridges in locally and it will go and encrypt over 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 with bridge I should say as well as we can with XMPP and
51:22
at least have the clear text re-encryption domain under the user's control rather than some horrific bridge in the sky somewhere which is reading everyone's traffic. Hi, thanks for the amazing work being an initiative being done on matrix my question is how is the user experience going to be
51:42
for revoking or untrusting other devices 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
52:00
encrypting the remote clients excellent question so basically where is the untrust button on the UI and the fact is 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 will stop us
52:20
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 of a philosophical question I mean 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? I mean likewise if there's a net split and I happen to have verified myself here
52:42
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 but I'm working on it in VR with ping pong but that's an entirely different story hi it's kind of going further on the question
53:00
about an admin signing people in the room could you have like degrees of trust based on how many people that you trust someone knew? 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
53:20
and if you ever looked at the PGP web of trust a. it's terrifying because there are so many completely weird bot-like 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 Fosdom PGP signing party in order to shake hands with people
53:40
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
54:00
so that you get a different MXID for every conversation you're in 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 kind of have a fuzzy grey list web of trust of sorts which is anonymized like that
54:21
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 gonna stick a pin in the middle of the jackass cluster and I'm gonna mute it and that is not quite trust but a similar answer to a different question okay, thank you Matthew I think you can reach Matthew on matrix
54:40
easily, so ask other questions to him thank you very much for a very interesting presentation