 Key schedule security for the TLS-103 handshake. Let us start with the TLS handshake. The TLS-103 handshake protocol is a key exchange protocol which allows the client and the server to agree on a symmetric key K, which they can then use to build a secure channel to authenticate and encrypt their communication. And I will now focus on the handshake protocol, so let me remove the secure channel. At the core of the TLS-103 handshake protocol is a one-sided authenticated Divi Helman protocol, so the client sends G to the X, the server sends G to the Y, and then additionally the server sends a signature over G to the X and G to the Y, and then both parties authenticate the transcript with a MAC. Additionally, the client and the server might have a pre-shared key, and if so, then the client sends over the ID of this pre-shared key and a binder value that binds the pre-shared key to the transcript. And then the resulting session key should be secure if the PSK was honest or the Divi Helman secret was honest. So how does this work? We first feed the PSK into some deterministic function indicated by this pink error, and then we run an extract function to get a new key value on which we apply the deterministic blue function. And then additionally, using a label and a transcript, we derive the session key. Now the pre-shared key can either come from some external application or it can be a resumption key which was derived in private session. So in addition to the session key, we also derive a resumption key. And in fact, we derive many other keys, but I'll skip these in this overview. So in our security analysis of the TLS 103 key schedule, we model the key schedule, so we model key derivations, not the protocol flow. And the adversary chooses its own corrupted keys and Divi Helman shares, and it can instruct the model to sample honest keys. So this model is a strong version of selective corruption. And additionally, the adversary instructs the model to perform key derivations with adversarily chosen transcripts that have to satisfy some restrictions. And in this model, we prove that the session keys are pseudorandom and unique. Pseudorandomness holds if the last PSK or Divi Helman's secret were honest, and uniqueness also holds for all dishonest keys, which follows from the restrictions on the transcript. In our security analysis, we assume that the expand function is a pseudorandom function, that the extract function is a dual pseudorandom function. And additionally, we assume collision resistant on the expand function, the extract function, and the hash function involved in the protocol. And additionally, what our analysis brought to light was the need for the salted oracle Divi Helman assumption, which is an assumption where the adversary can choose the salt, because here in this protocol, the pink function is a deterministic function of the pre-shared key. So if the pre-shared key is dishonest, then the adversary has a lot of control over the salt that is used in this extraction step here. For the PRF assumptions and the collision resistance, we did not need to make agile assumptions that talk about relations between different algorithms. But for the salted oracle Divi Helman's, we did need to make an agile assumption because potentially from the same Divi Helman secret, one might extract with pre-shared keys that use different algorithms. I would like to conclude my presentation with a couple of afterthoughts on protocol modifications, which would have made the analysis considerably easier and would have allowed us to rely on a weaker oracle Divi Helman assumption. Firstly, it's very nice for the analysis to include the context early, here by context I refer particularly to the resumption level and the Divi Helman shares. Secondly, it would be a good idea to extract from the Divi Helman secret first before mixing it with other secrets. Including the resumption level explicitly early on in the PSK evaluation prevents collision attacks between resumption PSKs and external PSKs more directly than currently done in TLS. Similarly, extracting from Divi Helman first and then including the Divi Helman shares into the derivation allows us to prevent collision attacks for this kind of Divi Helman key. Additionally, it would allow the analysis to rely on a less strong Divi Helman assumption.