From standardizing Messaging Layer Security to building Air, new private messenger | Raphael Robert

All right. Hi everyone. My name is Raphael and um that looks terribly corporate. Uh the reality is I'm just someone who is deeply passionate about secure messaging. I've been working in that field for the past 15 year.

Hello. Yes. Um So yeah, roughly 15 years ago um a new company came into existence called Wire. Uh maybe some of you remember the Wire messenger. So I was a part of that and I was in charge of security um and and um that is what what sort of wrote me into this uh this world of secure messaging.

And I worked on on open sourcing the source code of Wire, introducing end-to-end encryption, and then finally um I started working along with other people from academia and other companies on a new end-to-end encrypted protocol called MLS. So the first part of the talk is going to be about that. So you've probably heard of some of these um encryption protocols. PGP for emails off-the-record was a thing roughly 20 years ago. Signal of course needs no introduction.

So MLS is uh in in some way the continuation of that. Um just to put it a little bit in in perspective. Um it would take um a longer talk to actually explain how it works. Um there's a lot of information on it online, but I want to give the the highlights here today. Um So one of the reasons we did it was that um there was a very good precedent the signal protocol but it was never fully openly specified how it works.

There were no permissively licensed implementations so it was very hard for other products besides signal to actually use that protocol and another incentive was that um encrypting in larger groups was very expensive. So these are the two things that MLS is is trying to achieve really well. Um So we brought it to the ITF the internet engineering task force and since 2023 it is now RFC 9420 so it's been fully specified over the course of 5 years. Um It supports post quantum encryption which is going to be the norm going forward. But we're in a period where this is um where we see protocols switching to post quantum encryption.

It's the first protocol to also implement post quantum authenticity besides just confidentiality. Um And as I mentioned earlier large group scalability is a lot easier with MLS compared to other protocols. I'm going to go very quickly over the security properties. This is a little little dry so I'm going to try and put this in in simple terms so end-to-end encryption means that messages are encrypted between user A and B and and that gives you confidentiality and and authentication means you know who actually sent the message. And there are two terms forward secrecy and post compromise security and those are a mouthful we're going to get back to that in a second.

Um And finally MLS introduces something that has never been there before and that is that um members of a group chat cryptographically agree on who else is in that group chat. So, if I send a message to you, and you receive that message, and you can decrypt it, then you have some proof that I see the same set of participants in that chat. And also slightly more informal, uh it helps with transcript consistency to a certain degree. So, going back now to forward secrecy and post-compromise security. So, we said earlier end-to-end encryption is um encrypting messages between user A and user B.

Um and such an encrypted session could last for a really long time, uh potentially years uh when you talk to people uh over time. So, um it is not a bad idea to consider that one of the endpoints, one of the devices of the users, could get compromised in that time. And when you get compromised, your key material leaks, um and so for example, for email that means that um if I get my hands on a private key, I can potentially uh decrypt years' worth of encrypted email. Um or in the other direction, I can keep decrypting uh them in the future. So, this this window of compromise should be as small as possible, meaning if key material is going to leak, um then we should actually uh not like limit the effect that that has.

And this is what forward secrecy and post-compromise security means. Um this is what happens before and after this window of compromise. And finally about the efficiency, um this is a graph where the red line indicates what uh efficiency you have in large groups with protocols like the Signal Protocol that is inherently linear. So, the more people you have in a group, the more expensive the encryption is. And here's like an extreme example of a group of 100,000 members.

So, um you would have 100,000 operations uh to do uh if you were to do that linearly uh with MLS. It's logarithmic, so you would only have to do 17. So, that's a lot more efficient. So, these are some of the companies and also academic institutions that have been working on MLS. And to put that in numbers really quickly, we have some large deployment these days.

The most recent one is between Google and Apple. They uh a few weeks ago um they started encrypting the successor of SMS messages called RCS between Android and iOS uh using MLS. Um so, going forward, that is going to be end-to-end encrypted, which is nice. Um Discord is using MLS to end-to-end encrypt calls. And uh Cisco Webex has been one of the first movers uh back in 2021.

Um and and you can enable end-to-end encryption in Webex. And Wire has also um been active in that space and has adopted MLS for its users. And then there is a a much longer list uh of smaller or bigger integrations, um some of which are still ongoing. Uh you might recognize some of these names. Um I suspect some of you have a background in Web3, so there is also um things like the World App and Coinbase App that uh use MLS for end-to-end encryption.

Um so, MLS has been standardized uh since 2023 and uh however, the ecosystem is still active and uh research is still being done to extensions of MLS. Um for example, we've been working on a variant called DMLS, decentralized MLS, um for environments where you don't have uh a central instance necessarily. We've been working on making post-quantum MLS more efficient as well. Um then making MLS more suitable for scenarios where users have several devices. Um that count as ends in an end-to-end encrypted scenario.

And finally, we're also exploring um how MLS can be used for transport encryption. The last slide about MLS, OpenMLS. This is our implementation in Rust. Um of the protocol. So, that's an open-source library permissively licensed.

Uh it's being used in in some of the products you saw earlier on the slide. Um and this is also our building block for Air. So, Air. This is the the very first time that I speak about Air publicly in my talk. So, this is exciting.

It's very early days for Air. It's a new messenger, obviously based on MLS. And so, you might ask why even do a new messenger these days. There are so many already. Um uh but for a while, we've felt that something is still missing.

Uh and and that there's a sweet spot um that is not really covered. And so, we care a lot about privacy. So, this is important. Um we also care about decentralization. It's a vague term.

It means different things to different people, but uh the bottom line is probably we can agree that it's the opposite of centralization. Um and what's also important is feature richness in a messenger. People want to not have a steep learning curve or miss certain features um if they switch to another messenger just because it's private. And finally, robustness. And I'll I'll get back to that what that actually means.

So, Air is essentially trying to combine these four things um in a way that we think has not been done before. So, of course, end-to-end encryption is done with MLS. Everything is end-to-end encrypted. That's the baseline these days anyway for secure messengers um the content, the the read receipts, the delivery receipts, um anything that is being transferred. Um and we are in the process of transitioning to post-quantum resistant encryption.

The more interesting part is now about identifiers. So, um this is where we deviate a little bit from other solutions. Um so, with Air, you do not need to have a phone number or an email address to sign up. You don't need anything, in fact. Um we have usernames.

Those can be chosen freely, and you can have more than one, up to five currently. Um and so, the interesting part is that the usernames are actually not directly linked to accounts um because the usernames are potentially the one element that can be identifying if you pick your real name as a username as as many people would do, um it's interesting to not have that associated with the account so that um in the event where um data becomes open because it was hacked or because it was legally required, then you cannot conclude anything from usernames. And more generally, um metadata. So, we try to avoid uh storage layer metadata. Um that that sounds complicated.

What that means is it's very similar to Signal where essentially there is no plain text record of metadata on the servers. At least the kind of metadata that would be problematic. Um So, what do we mean by metadata? That is, for example, who talks to whom in the context of a messenger? Uh and also other stuff like how often do people send messages, at what time do they send messages, etc.

So, aggregating all this data is something in the context of surveillance that that is very powerful because you can draw a lot of conclusions just by looking at metadata, even if you cannot decrypt the actual content of messages. Um so, we're very focused on on protecting metadata. But finally, robustness. So, um protecting metadata to degree, it's not that complicated because um you just don't store them. You make sure that messages, for example, they have enough data attached to them so that you can route them from like user A to user B or in groups.

Um but you don't necessarily need to store that. However, if you don't store it, then you run into the problem that um certain things become a lot harder than they used to be

[clears throat]

uh when you don't have metadata. For example, denying access. If you want to block a user, uh and the server doesn't have a any concept about who's talking to whom, then that becomes hard because the server cannot effectively block users um in in the simple fashion it it could do if there were metadata. And the same is true for rate limiting, for spam, for example. Like how many messages can you send to another user per hour?

If again, if the server or the the the general infrastructure through which the messages go has no concept of that. So, and lastly, recovery. If you lose all of your devices, you want to recover your account, um like how how do we do that if the server doesn't know who you were talking to previously? So, these are the really hard things to solve if you want to get rid of metadata in a way that you do not affect the the basic security functionality that you actually expect from any messenger, meaning blocking people, not receiving too many messages, not receiving too many contact requests, etc. So, this In other words, this took a while to figure out.

And then decentralization, um so it turns out that it's actually great when you don't have a lot of metadata, then it becomes a lot easier because you do not have a lot of data in general on the servers. Uh and in an end-to-end encrypted um messaging system, most of the logic actually happens on the client side. Um so, this this you know, makes it easier if you want to decentralize things, and so um without compromising robustness and security, it is comparatively easy to have something that is federated, for example. Um so, this is um something we are aiming to achieve in Air. So, um we are um in the Apple App Store and the Google Play Store currently uh with an early version of Air.

Um so, we cover mobile platforms already. Soon, um there will be desktop versions for Windows, macOS, and Linux. Um hopefully, it's a matter of of weeks at this point. Uh and um then very important, we are free and open source. The core, which is actually most of the messenger, is written in Rust.

Um and then there is a relatively thin layer of Flutter on top of that for the user interface, and this also allows us to have the same code on all of the platforms, which is important because we are a small team. Um so, we need to be efficient about what we do. Um so, we have a relatively coarse road map at this point. The the next thing is going to be desktop support and then we want to catch up with all of the popular features you know from other messengers, muting chats, share extensions, reactions, etc. There's still quite a few things missing.

This is also going to be driven by um what the community wants and the community needs. Um we want to make self-hosting easier um so that um anyone can actually host a an Air server so that we are not the only operator. This is how we think um we can contribute to decentralizing things. And uh last but not least, calling. This is probably only going to happen next year.

So, audio calling, video calling in one-to-one and groups. Um then we're exploring something that's uh an app called Linear has introduced recently and we thought the concept was super interesting. A zero-bug policy. Of course, that's a lie because we all know that software never has zero bugs, but the idea is that we want Air to be really reliable. It should work well.

And so, if we know about a bug and it's really reproducible, then we want to fix it quickly. Um a little bit about funding. So, I mentioned earlier we're a small team um and so the the company that is working uh on Air is called Phoenix R&D. And uh we did not take up any VC funding. We saw that with other messengers, we think it's fundamentally not really compatible with uh developing something uh private.

So, um that's why we decided to do it differently. Uh instead, we are financed through grants uh from the the usual sources like the Open Tech Fund, uh the Sovereign Tech Fund in Germany, Prototype Fund and NLnet, uh etc. And so, the most important feature last, uh in 2026, any software needs to have a dark So, Air has that as well. And this concludes my talk. So, if um you want to learn more about Air, if you want to try it out, um the domain name is air.

ms. That's where the uh, QR code is going to point you to as well. Uh, it's invite only for now. And um so, I'm happy to hand you invite codes. Also, my colleague Julian who's sitting there in the back with an orange lanyard has some more.

So, thank you for listening.

[applause]