Yep, okay, welcome here. I can hear myself. So hi, my name is Hubert, you might know me
online as you are egg. I'm on the crypto team at Eleman, where crypto means encryption,
and I'm also on the matrix spec core team. But my talk isn't going to be about matrix,
so if you're came here trying to find out what we're going to do about MOS on matrix, sorry,
I'll talk a little bit about it, but not much. I did some investigation into decentralizing
MOS for matrix, and I wrote a partial experimental MOS implementation in TypeScript,
which was not very fun. So what is MOS for messaging layer security? So it is an ITF standard.
It's RFC 9420 for enter and encryption in instant messaging.
And it can be it's intended to apply to many different systems, so
so any or many different messaging platforms can use it. It encrypts messages, obviously,
if it's intended for messaging. And also handshake messages, which are the messages used for
controlling the MOS group, can be either encrypted or in clear text, although the sensitive
parts are always encrypted. So that means that for example, you have the option of either hiding
the group membership from the server, or the server can see the group membership, so that it
can apply its own access controls or whatnot. It ensure its consistent group state, so it
controls the group membership. So everyone in the room can be assured that they
that everyone knows who's in the room. And then there is also this concept of group context,
which is sort of you can shove arbitrary data into the group, and then everyone in the group agrees
what's in the group context. It provides sort of the normal things that you expect from
and turned encryption in messaging. So forward, you can see post compromise security.
The one thing it does not provide is deniability. So there is some work on trying to do that,
but it's not in the standard. And updates are intended to be fast. So order log n,
work where n is the number of members in the group. On average, there's a big
asterisk there because it really depends on how the group is managed. You can get into a
really bad state where there's lots of holes in the tree and you end up having to do order and
work anyways. But the intention is that the common case is that it's order log n. Though
inviting someone still requires a linear time work. So how does MLS work? So I am only going to
focus on a very tiny part of MLS because I don't have two days to talk about it.
So the part I'm going to talk about is the MLS epochs. And so an MLS group goes through
different epochs and each epoch has a secret associated, which is called an epoch secret.
From the epoch secret, you derive other secrets. For example, encryption keys.
I believe a message authentication code keys are all sorts of things.
And the epoch secret, each epoch secret is derived from the previous epoch secret and
a secret that you get from the commit message that created the epoch. And then you sort of
when you get a new epoch, then you throw away the old epochs. So this is a diagram that comes from the
RFC. So this sort of shows that you have the epoch secret. You derive, well, this just shows
the encryption secret. But you derive a bunch of other secrets from it. You use the encryption secret
to derive keys from the secret. The secret key you use to decrypt messages. So when you get in
a message that creates a new epoch, you decrypt it. And then that gives you the commit secret.
You combine it with the previous epochs secret. And then you get the next epochs secret.
So in normal MLS, commit messages are ordered. So you have epoch number zero and then epoch
number one. And then epoch number two. And you only apply one commit to each epoch.
And they're all in a linear order. You have a delivery service that enforces the order.
So that everyone agrees that this is the commit that came, that modifies epoch zero.
And then I get epoch one. So everyone is in sync. But what happens if you don't have a single
delivery service to order them. And so you can't ensure that everyone sees the commit messages
in the same order. So there are two different approaches that have been published as ITF drafts.
There's decentralized MLS, also called DMLS. And this was written by people from
Phoenix R&D. And it was based on work by people from Amazon who were
formerly wicker people, but they got bought out by Amazon. And then there's also distributed MLS,
also known as DMLS. And this was written by people from German at work and researchers from the
US Naval Postgraduate School. So I'm going to give a brief introduction for both of them and then do
some comparisons. Decentralized MLS. So instead of having a linear order of epochs,
it allows you to have multiple descendants. So you can have multiple senders modifying the same
epoch. And then so you get sort of a tree of epochs rather than lying. I use it some fancy
cryptography called puncturable pseudo random functions. So you can't redevive an epoch secret
to preserve forward secrecy. So here's a little diagram that I drew up. The circles are epochs.
The labels on the lines are the people who created the epochs. So we start off with a single epoch.
And then L.S. and Bob try to do something to the group at the same time. So maybe they want to
update the wrong keys in the group. They happen at the same time. So it's not like Alice sends
her commit and then Bob sees Alice's commit and then sends his own. They happen at the same time.
So they both modify the same epoch. So then there's a fork in the tree. And then Carol wants to
send her own commit. She has to decide which epoch to base her commit off of, say she decides to
base it off of Alice's epoch and then so she creates her commit based on that. So yeah, when Alice sends
her commit, then she will show send it to the group. Everyone will see the group. And then so
everyone won't drive of these the three new epochs. So one of the problems with just doing this
with MLS is that so say after Alice drives for epoch, then she still needs to keep around
the epochs secret for the original commit because after Bob sends his commit, then she needs
the epochs secret from the original commit to drive Bob's commit. And that poses a problem for
forward secrecy because you're holding on to chemotherapy for longer than you need to or longer
than you should. And so if someone compromises Alice's client, then they can get the epochs secret
and then replay Alice's commit and then re-derive this whole epoch and then decrypt
all messages using the secret. So that's where this puncturable pseudo random functions comes in.
So if you know pseudo random function is sort of function, you give it some input and then it
spits out some pseudo random data, the puncturable. So if you give it the same data, it'll give you
the same pseudo random data. The puncturable part is once you've given it the input data once,
then you can't give it the same data again. So it can only derive the pseudo random data once
and it's a bit of cryptomagic. I'm not going to try to explain it because I don't understand it
either. It just works. So with this approach, there are a few open questions. So how do you manage
the forks? So if you remember here, we had Alice and Bob's commits. So Carol needs to decide which
commit to use. So Carol uses Alice's, she decided to use Alice's commit, you know,
woods that the best choice. And then what are we going to do about Bob's commit? And then another
question is, now that we have, now that we have multiple epochs that we need to worry about,
how do we make sure that everything's consistent for example membership. So say if on the left
Alice invited her friend Dan and Bob invited Emily, you know, so then on one side of the tree,
we have different memberships. How do we combine them? So this sort of goes into my, the work
that I did, which I also called decentralized MLS, another DMLS, but I spelled it with an S instead
of a Z. So if you get confused, yeah. So it was just a way to decide which epoch to use, how to copy
updates from one epoch to another. It sort of assumes that we have some sort of algorithm to
determine membership in group state. So in matrix, we have the state resolution algorithms
that we run in matrix currently that's done on the server side. And when I was doing my experimentation,
I just used, I just used what the server had told the client to use for the membership,
but there's no reason, well, other than complexity that we couldn't also run the state resolution
algorithm on the client. So some downsides to decentralized, decentralized with a ZMLS.
So it potentially requires a lot of storage because you need to keep all the previous epochs
or information about the previous epochs in order to handle forks. So there may be ways of
cleaning things up if you have sort of a time window that you accept old epochs from, but it's
that's something that would need to be figured out. Managing forks can be complicated. So if you
have a lot of forks, then you sort of have to look at all of them, figure out what information
you need to take from each of them and so forth. And it's sort of an open question. The decentralized
MLS draft, the ITF draft doesn't really deal with any of these issues. It just describes
what messages and modifications you need in MLS in order to do those things, but it doesn't
describe how to do all this management. So the other DMLS distributed MLS takes a completely different
approach where it says that each sender will maintain their own MLS group.
And so each sender sort of acts as their own delivery service because they're the only person
who can commit to make commits to their own group. But you can also look at other people's groups
and pulling information from their group. So for example, if Alice updates her key in her group,
then Bob can look at that update and then update Alice's key in his group so that
the cryptographic information is up to date. It sort of sidesteps the question of how do
maintain consistent membership by saying that each sender decides on their own who's going to
be a member of their group. So there is less of a need to have a consistent membership between groups.
So downsides to this approach is that you lose the log-and performance of MLS.
So remember at the beginning I said that the log-and performance depends on how you manage
your group. So distributed MLS basically the way it uses MLS you just lose the log-and performance.
It's always linear time. And you lose the shared group context and the shared membership.
So yeah, depending on your application that may or may not be important. So even though you
lose shared membership, you can still see the group membership from everyone else's sender group.
So that you can tell who they've sent the message to.
So now I'll do some comparisons between the two. So the first question is which one is more MLS
like? And this is possibly a bit controversial because it is very subjective.
And so I will say that they're both more MLS like than the other in different ways.
So decentralized MLS it tries to keep more of the MLS semantics in my opinion. So you get like the
it tries to keep the shared membership. The group context and the
order log-and performance. But it requires more modifications to the protocol. So it requires this
new way of storing the epoch secret as a punctual bone pseudo random function.
And so that's some requires some cryptography analysis that hasn't been done yet.
So distributed MLS it requires fewer changes to the MLS group because you can basically just use
MLS as it is. But you lose the semantics such as the shared group context.
Which one is faster? So decentralized MLS by itself can be word of log-and.
Although again it depends on how you manage your how you manage your group.
But managing forks can be expensive and it depends on how many forks you have. So if
you know most of the time everything looks linear then it'll basically be the same performance as
MLS. If you have you know a few forks here and there then it'll quickly resolve. But if you get a lot
of forking in your tree then it can get expensive because you have to look at a whole lot of different
epochs and try to merge things together. And distributed MLS as I mentioned before is always
linear time. What about storage requirements? So decentralized MLS is potentially unbounded.
But you know if you add in some way of pruning old forks then you know it may be only need to store
a few different epochs at a time. So it might be closer to or linear space like MLSs.
Distributed MLS if you just do a naive implementation you store you have end-different
centers each MLS group is linear space. So that's you know quadratic space in total which isn't that great.
But the way distributed MLS works a lot of that information is irrelevant to you as a receiver
because like in each MLS group every node has a signing key so you can verify that yes this
person actually sent the message. But if you know that this group is only going to have one
center then you only need to keep the signing key for that one center. You also don't need to keep
any information about how do you encrypt things to other people in that group because you're not
going to use that group for encryption. So you can throw away a lot of information. I think that you
can get away with storing a constant amount of information per receiving group. I haven't actually
gone through to figure it out but I believe it's constant at worst I think it's logarithmic.
So you of course need to keep your own MLS tree for sending which will be linear
and you have a linear number of receiving groups. So in total it'll just be linear or I think that
worse log n log n which isn't too bad. So which one should you use if you're designing a distributed
or decentralized protocol? So distributed MLS I think is in my opinion it's more ready to use
because there's fewer open questions you don't need to worry about. So distributed MLS is the
one where each person has their own sending group. So you don't have to worry about managing the
forks. Things like that it's and yeah decentralized MLS has more details to work out
such as the group management and the state resolution and sort of things but they have different
trade-offs and it also depends on the underlying message messaging protocol. So for example
in matrix I believe that decentralized MLS would be a better fit. So in matrix servers are usually
available in the common case servers are mostly up and in contact with each other.
It's designed to be able to handle net splits but most of the time if a server is up
then it can it can contact all the other servers. So in the common case I believe that decentralized
MLS is a better fit for MLS sorry for matrix for peer to peer messaging systems such as
rain talks or briar. I believe that distributed MLS is a better fit for XMPP. So
most of you they're chatting XMPP for the purposes of this talk only I would consider them centralized.
XMPP is obviously not centralized but each room individually has its server that every message
goes through and it can act as a centralized delivery service. So for multi user chats you can just use
plain MLS you don't need to worry about this stuff. One on one chats are different in XMPP though.
One on one chats you send your message to your server it relays the message to the other person
server and then sends it on. So there are a couple different approaches one of them is you could
you could just use plain MLS but just designate one server as the delivery service because if you're
doing a one on one chat and the other person's server is down then you're not going to have
much success chatting anyways. If you don't want to do that then my suspicion is that distributed
MLS would be a better fit for one on one chats in XMPP. So there are other approaches to
doing MLS on decentralized platforms. One of them is that you can centralize at handshake messages
but decentralize the application messages. So when you're just sending like a chat message
you can do that normally as you would over your decentralize network but then when you're trying
to do an update to the MLS group then you would have a single server that handles the ordering of
those things. So the downside to that of course is that if this single point of failure fails
then you can still send messages but you can't make any changes to the group which means that
we would lose for example post-conformized security. So if someone's client gets compromised then you
can update the MLS group and then the attacker can still keep reading messages.
You could go a bit further and have a pool of delivery services and you pick one of them to be
the delivery service and if that one goes down then you pick a different one. There's a bunch
of literature out there on later elections. Most of them they pretty much require that most of the
candidates are online so that they can come through consensus so this might not work for
some situations. For example peer peer where you have a bunch of things and the most people
won't be online at the same time and then there's completely different algorithms that can be used.
There's this thing distributed continuous group key agreement which was written by widener
and gluttonin and a few other people. There's this thing called bechem from ink and switch.
Both of those are on my reading list. I'm not very familiar with them but they're both
intended for decentralized situations or we can just keep doing what most people have been
doing which is using the signal protocol and variance of the signal protocol such as omin
megong in matrix and omemo in x and pp. So that's it. Any questions?
For the folks to color less down the line. Part in the future can you see the opportunities for
where the e-box of folks do them? Yes. There are opportunities for them to color less later on in
time. Right so the question is if I'm in the diagram so the question is when you have the
forking is there opportunity for the forks to color less later on. So the way the decentralized
ITF draft is written it just handles the forking. Part of the work that I was doing was sort of
it was so pulling in information from from the different forks and then adding information
to say that yes I've so Carol would say I'm basing it off of Alice's e-poc but I've also seen
Bob's e-poc and I've merged in information from there and then so there isn't sort of a formal
merge operation but it sort of assumes that after Carol sends the e-poc then Bob's e-poc
will sort of be ignored for the rest of time and everyone will sort of base it off of there.
Yep. To me it sounds like this will pop here. Thank the scalability of the chat so if you have
a chat with many people they would have many different forks to get together is there any
or not about this or how it could be solved. Yeah so the question was about scalability if you have
a lot of people and you have a lot of forks yeah so this is an open question we haven't really
figured it out yet but yeah so the forking only happens when you do an update to the group
so that's if you need to change your key material or if you invite someone or someone leaves the group
so it's not something that happens all the time. It's something that happens occasionally so
if you have something that happens even in a big group I wouldn't expect people to be sending
commits more than more often than say like once a minute so in a situation like in matrix where
servers are mostly connected I would not expect there to be much forking even in large rooms but
it's it's it's an open question no it's yeah it's it's it's not on every message that you send it's only
on certain certain group operations. Yep. Did you already compare this video to MLS with
sender keys like the approach signal users in terms of performance and security because it seems
right as a consumer because it uses something with his key from the school. Yeah so the question is
about comparing distributed MLS with sender keys because they they seem kind of similar. I personally
don't have much experience with distributed MLS so yeah and I don't know if the group
who's worked on that has done comparisons with with sender keys.
Yeah so the question was about
distributed MLS on a federated service whether you can do a group per server rather than
per sender and yeah that that might be possible it would be something we would have to explore
we haven't really there's there's a lot of possibilities that we could we could look into and we
haven't really looked into it that much okay I guess that's it