Peer-to-peer, sort of two-person communication, which hopefully is end to end. And it means that no one can get in on that conversation,

Impersonate us, read any messages, put in any messages themselves.

Even the server, and this is a really good thing.

This doesn't work as well in group messages. And maybe people don't actually know this.

Last time we talked about end-to-end encryption in apps like Signal, WhatsApp, Facebook Messenger.

Signal implemented this by default, Facebook Messenger has a private conversations thing you can enable and you definitely should enable

so don't use the default because they'll be reading your messages, but

These things kind of start to break down when we're looking at groups, right? What's true in terms of cryptographic security,

what's true between you and me is not the same as when we bring Steve in. There were a lot of reasons for that.

So let's imagine that we've got three people in a conversation, right or maybe just a couple of people

So I'm here, this is Mike

We're actually using not Alice and Bob this time, they'll be glad to be having a bit of a break

I mean I thought about using it just to keep the trend going

But let's not. So this is Sean and Steve over here

Normally when we're talking about one of these applications I will have some kind of shared key with you

We've got this double ratchet going on where we're sending messages back and forth keys are being updated

So I will have a kind of encrypted communication channel with you

Now, of course this is going through a server, but I'm not drawing a server in this image

There's a few interesting properties that this particular conversation has. The first is obviously it's it's secret, right?

This is encryption. Also, it has something called perfect forward secrecy

Which means that if someone cracks one of our keys they can't use that to go back and crack all the other messages

Previously to this because the keys are constantly updating and you can't go backwards

it also has this kind of self-healing or post compromised security, which means that if you

Let's say someone cracks one of my keys if they sort of look away even for a second,

We can have some more communication and that problem goes away

Essentially, to continually eavesdrop on our conversation, not only do you have to break one of our keys

But you also have to see every single message from then on. If you miss one, you're out

So the question I guess is if we want to do implement group conversations

Which is where I'm sending messages to both you and Steve at the same time

Can we still do these things? And the answer is a little bit but not totally

So, okay. So let's imagine now we've got a three-way conversation.

Now remember I have already got channels, but I've been perhaps talking to you beforehand

And you and Steve have been talking as well separately

Right, if it's the case that you're introduced to a group where you haven't been talking to them

You will form a two-way conversation with that person immediately right as a way as a sort of prerequisite

That's the way it's normally done

Well, I suppose the sort of naive way of doing this would this be: whenever I want to send a message to the group

I send a message to both of you

Using our pairwise channels and then we have the benefits of the security of each of these channels

I send that same message once encrypted using our keypairs and once encrypted using mine and Steve's keypairs

And then kind of up to you and Steve to make sure these messages are in sync

And if you then send a message, you're gonna send it this way. This is how our message works

All right. This is not stupid, right

The benefit you get is that each of the messages has the guaranteed security that we had with this sort of pairwise messaging:

Self-healing, perfect forward secrecy, this kind of stuff.

The problem is the more people you add to this group. So maybe you're a member of some kind of school thing, 50 people in the group, you're sending 50 messages

And if you're not sending a text message

Maybe you're sending a video suddenly the bandwidth becomes actually a bit of a problem

This may not be an issue depending on the application

But Whatsapp, Signal and others have decided that this is a bit of a problem, and this is not how they're going to do it.

The next thing we could do is we could say well, why can't we use the same protocol to establish keys to get a group key?

So you and me and Steve all team up

We do our Diffie-Hellman in some way and that gets us one shared group key that we can then use, right?

So then I encrypt a message to you both with the one group key

Now, of course in practice I would just send the one message to the server and it would spread out

So this will be called server-side fan-out. So a single message for me to the server

The server knows it has to go to the group and it sends it out

Now there are ways to turn Diffie-Hellman into a kind of three- or four- or n-way Diffie-Hellman

They're usually using trees where two of us will do it, exchange, and then someone will do an exchange with that

And and so on all the way up to the top where that's everyone's key

The problem is that this takes time. It involves all the parties

So implementing this in a way where Steve doesn't have to be online at the same time as me

and at the same time as you, that's a problem

And that's another of the things that we get from our pairwise messaging, this asynchronicity

The other problem is that how often do we do this, right?

If I create a group key with you and Steve and we chat for two years using that same key

Maybe someone broke it one month in and has been reading all our messages for nearly two years

Huge problem, right? So there's no self healing really unless we recompute these keys regularly

So how does actually work, right? It's kind of a compromise

What we do is we use our pairwise channels to establish a key and then we use group keys

Kind of the big problem with this group key idea is that the Diffie-Hellman key exchange is complex

and if people haven't got their phone switched on that's a huge problem

one of the nice things would be if you and me could add Steve to a group when his phone's turned off

And then a month later he remembers, turns his phone on it gets all the previous messages

That would be really good. The way we do this is something called sender keys. So I'm going to write sender keys here

A bit like our sending and receiving chains in a normal protocol,

Each person comes up with a sending key, right? This is iterated for every message. So we have this perfect forward secrecy

So, how do I give this to you? Well, I use the two-way communication we already have

So I have a sender key for me. You have a sender key for Sean. This is not going to work

And this is — yeah, I've not thought this through — This is a sender key for Steve

I mean, this is a shambles and now I was only one letter, okay?

Uh, anyway

So at the very beginning we'd established a group

So I send you a message which says this is my sender key for this group

I send Steve a message. It says this is my sender key for this group

You will do the same. It's a few initial messages, but it doesn't have to happen online

I can send the messages and you can pick it up later. So that might sit on the server waiting for you

Just like a normal WhatsApp message the server can't read it because it's protected using our end-to-end encryption

From then on, when either I send a message I send it encrypted using my sender key and then I ratchet my sender key one tick

If you are sending to someone you perhaps haven't had that before

Someone said hey add this person to the group because they've joined the school or something

In your previous season then presumably that then starts to use the stubs that we had in the previous thing?

No, so what will happen: Yes, you mean the three keys?

Yes, so what will happen is let's imagine, that we add a fourth person to the group

Dave. Does Dave use WhatsApp?

He does now, so Dave turns up. I've never spoken to Dave before on a mobile phone, right?

So I will then perform a quick triple Diffie-Hellman handshake with Dave using the standard pairwise protocol we have

And then I'll use that to distribute my sender key for this group

And have a good thing is everyone can do this asynchronously

There's an initial burst of messages you have to send which kind of increases linearly with the the amount of people you have

20 people means 20 sender keys I have to send out but the server will handle most of that workload for me

Everyone will know what key I'm going to be using because they just keep their receiving chains in sync with my sending chain

but the disadvantage, and this is the key problem with group messaging like this

Is that we've lost our self-healing property because these sender keys don't change

They just ratchet along. We can't go back and find out a previous one

But if anyone gets my key

They can then intercept any message I ever send into this group and they can impersonate me by encrypting a message

With that same key and there's no way of detecting this

Now no one mentioned this in group conversation, but this is true of most group protocols at the moment

It's not an absolute disaster because you know breaking these keys is not easy

But essentially if we have a pairwise conversation

And we invite Steve, what we've done is we've decreased security on our communication without realizing it

We've gone from a double ratchet to a single ratchet. Is that right? Pretty much? Yeah, right

So we've lost our Diffie-Hellman on the top that keeps things sort of self-healing, right, this post-compromise security

There are papers out there now that have solutions to this that maybe will be implemented

They'll be obviously have to be verified that they you know, they work and stuff that people will eventually solve this problem

But at the moment it is not solved

There's another problem: who's in this conversation, right? And do we trust everyone in this conversation?

Remember that we looked at our safety numbers

This was essentially your identity combined with my identity

In a sort of hash form and if we have both have the same, we know we're the only two in this conversation

As an aside for people who get interested

I've gone through two different phones since then and so therefore you've no idea who yeah

We haven't verified our public numbers this since you changed your phone. I'm kind of taking it on trust and I'm a bit skeptical

So this is all this is all very nice for two person conversation, but for a multiple person conversation

There isn't really a mechanism for doing this, right?

You have to you could kind of go and verify all of your individual safety numbers of each pair, right? That would help

It's a lot of work, especially if someone you don't know gets added to the group

Maybe you're not in contact with that person sort of physically

This is another drawback

and actually there was an essay produced by someone from GCHQ recently that suggested have a quite a nice way for the government to

Get access to some of these conversations for crime purposes would be just to be added as - as a silent party

To this conversation right? Maybe the app could just whenever you create a group of three people

It's actually a group of four people where one of them is the government

I'll leave it to the comments to decide what they think of this

Other video: Now I've got the token so I can load a value in, add the register into it and

Store it back and hand the token and now I've got the token again

I can load something into it

into my register

add something onto it so it back and pass the token on and I've got it so I can load the value in add the

value from a register story back