We've already covered Signal, WhatsApp, Facebook private messages, these kind of things.
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