All right, then I will start with a lecture.

So what did we do two weeks ago?

We started first of all with a motivation, an extended motivation for a wretched key exchange.

Just as a reminder, wretched key exchange is the primitive that allows us to update the key material between sender and receiver,

such that corruptions of senders or receivers do not harm conversations that were long before the corruption or that took place long before the corruption,

or that will happen much after the corruption took place.

So the basic idea is there are many reasons for why secret key material of senders and receivers can be corrupted.

Some are that, I don't know, your phone is stolen, there was an implementation bug in your implementation,

maybe some logging scheme was publishing your key material to a server.

There are many reasons why that can happen, in particular in messaging sessions in which communications, conversations last for a very long time.

It is important to make sure that such corruptions will not affect the entire history of your communication.

And so this is the reason why we look at such update mechanisms for key material.

And wretched key exchange is the most core primitive that achieves these key updates.

There are other components of a messaging scheme like the encryption mechanism, the initial key exchange.

There are reporting schemes, blogging or blocking schemes to make sure that whenever there are abusive users, you can block them, you can report them and so on and so forth.

All these components are not directly connected to the update of key material, but wretched key exchange is.

It is the core component for doing so.

And we looked at different types of wretched key exchange or different notions, different notions of wretched key exchange.

We started with the fully bidirectional communication setting in which Alice and Bob can, whenever they want to, establish new keys and update their secret state material.

Then we looked at something that is called sesquidirectional wretched key exchange in which Alice can, whenever she wants to, send and establish a new symmetric key and also update the key, the state variables that contain the secret key variables of Alice and Bob.

And then the most restricted version was the one that we are looking at in this course, which is unidirectional wretched key exchange.

And for this we defined or we started to define security.

Okay, and what we do today is we finish this definition.

We will then look at a construction for unidirectional wretched key exchange.

We will learn something about the random oracle model.

Because what we eventually want to do is we want to prove security.

And the random oracle model is one of the things that is very widely used in cryptography, but not often taught in courses like this.

But it is once understood, very simple, but we have to understand it in order to prove security of the thing that we want to build here.

Okay, so just as a reminder or continuing a reminder of where we were, wretched key exchange is the primitive in which a user Alice and a user Bob at the beginning share a state that is output by an init algorithm.

This init algorithm can be a randomized algorithm without any input or a deterministic algorithm with a key that then deterministically outputs a state for Alice and for Bob.

And then whenever Alice wants to send, she uses her send algorithm together with the input state.

And that send algorithm outputs a ciphertext that is sent to Bob, a symmetric key that Alice uses for symmetric encryption, and a refreshed or updated state that she can use when she will send the next ciphertext.

Bob uses his state when receiving together with the input ciphertext to output the same key based on correctness and updating the state for the next receive operation.

And so the syntax in total consists of three algorithms, init, send and receive.

Init takes nothing as input and outputs the state of Alice and Bob.

Send takes the state as input and outputs an updated state, a key for some external protocol like message encryption and the output ciphertext that is used by the receive algorithm together with Bob's state to output

the state of Bob and a key.

Okay, and so correctness tells us that the two keys that Alice and Bob compute when they started with the same initial states

And they then use these states comparably by inputting the ciphertext that Alice outputs on Bob's receive algorithm.

Then these keys that are output by the i-th invocation of the send algorithm should equal the keys that are output by the i-th invocation of the receive algorithm.

Of course, by security we at the end want that the key in send and receive operation i is independent of the key that is output by the j-th invocation of send and receive as long as i and j are different.

But at least like for the i-th invocation of send and receive we want that the keys are the same.

We could again write this correctness definition just as a game as we do it here for the security game.

But since this is a very compact notion and we don't need a lot of interaction to be covered in this correctness definition, we can just write it as that.

But of course we could also expand it in a game based fashion.

I could explain now again what the reason is for why we do this with games or with probabilities.

The main difference is just readability and comprehensibility.

And then we started with defining security with such an i and d notion indistinguishability notion.

And the basic idea was that we give the attacker oracles that allow the attacker to control when and what to send and when and what to receive.

In addition to exposure oracles to learn the state of the sender and the receiver whenever the attacker wants to.