 Everybody so as Kenny already said the title is to what's bi-direction ratchet a key exchange And as he also said this is a collaboration with but I'm perturbing from Roll Holloway So before I go deeper into the details what our title means and what we did in our work I will first give you an idea what ratcheting is and what ratcheting is actually good for So suppose two parties Alice and Bob want to communicate among each other and they for example use instant messaging They usually send their cipher tags over an insecure network Which means that there might be an active adversary who controls this network and who might be able to Manipulate cipher tags on the network drop them and at least read them and In a setting in which Alice and Bob communicates via instant messaging their communications Usually take a very long time because they set up a session as soon as they want to communicate and they reset up and Terminate a session only as soon as one of these two parties buys a new smartphone And this may take a couple of months or even a couple of years And in such a setting it might be reasonable to assume that during the long lifetime of such a session there might be an adversary who obtains access to the local states of one of the communicating participants and one practical example would be that Alice or Bob check in at the airport and Then the police requires them to hand over the smartphone and then they may have to or they make a copy of these secrets And thereby they obtain information on these local states But in such a setting we still maybe want guarantees that previous communication before such an exposure of the local state Stay secure and even further we want that future communication maybe recovers into a secure state again And there are actually practical protocols that aim to provide security in such a setting and the most famous example Here is the signal protocol and the signal protocol also made the term ratcheting Mostly famous. So it was around before and this ratcheting is actually the technique that helps Alice and Bob to Kind of be secure in such an adversary setting So this ratchet is the technique that is Applied to the state of Alice and Bob that mixes into the state new information Such that it cannot be foreseen by an adversary who has the state now Which information will be mixed into the state in the future? And it also invalidates all information such that it cannot be accessed in the future anymore Now what signal signal simply does is it lets Alice and Bob send Diffie-Hammond shares over the network over and over again And then both of them use these Diffie-Hammond shares to compute Diffie-Hammond key Exchanges and then these keys update the local state of Alice and Bob What they also do is they use hash chains to update the state forward securely as long as the other party does not respond So in an in non-interactive setting But the question that we might ask in such a setting or with the respect to this technique is this technique actually sufficiently secure or What the security of ratcheting actually mean and this is the question? We are looking at in our paper and that we want to answer So what is a natural security notion for ratcheting and by natural? We mean that we provide an adversary full control over the network let him Adaptively over and over again expose the local states of Alice and Bob and we require a full security Except from only these cases in which we know that by the behavior of the adversary the adversary can trivially break The security so the adversary doesn't have to break any Anything of the the construction and we call this the trivial attacks Now there has actually been success in providing such a natural security notion for ratcheting before which was presented by a balleriet I'll last year a crypto and they looked at Restricted variant of ratcheting in which only Alice is able to send and Bob is only able to receive but Bob cannot respond in this setting What they were not looking at was the exposure of Bob So they allowed in their security notion the adversary only to expose the state of Alice so in contrast to previous work and also previous practical construction our models require and our Constructions provide full security in an azoncronus communication setting with respect to the exposure of both parties local states Now there in the remaining talk I will first give you ideas on how the primitive ratcheted key exchange looks like and that there are actually different variants of Ratcheted key exchange that are sensible to look at I will then provide more details on the general Adversary model and afterwards look at two of these variants of ratcheting for which I will give ideas on how to model and how to define security and I will then Provide ideas on how we construct a provably secure design for these variants of ratcheting at the end. I will shortly provide Summary on our results. So if we talk about the primitive of ratcheting We first need to define what the syntax of ratcheted key exchange is and what I didn't mention so far is of course that Alice and Bob need to have some way to initialize their session and What they could do is they could use an authenticated key exchange to derive shared secrets, but since we want to keep this primitive Abstract and generic we just define that there is an initialization algorithm that provides both Alice and Bob with Their respective state to start communicating What Alice and Bob then also need is an algorithm or are algorithms for sending and for receiving and These algorithms take the state the previous state and then either output a cybertext or take aside for text from the other party And then update the state respectively for the next invocation of this algorithm Now what we are looking at in our work is not the security of the actual communication But rather we are looking at keys that are output by these algorithms That then might be used to establish channels or encrypt between Alice and Bob so we are looking at the consecutive establishment of keys between Alice and Bob and this within one session and this makes Ratcheting distinct from authenticated key exchange in which we have multiple parties Communicating in multiple sessions and then outputting only one key Now we can look at the security of keys because we know by the results from last year's crypto by Belaried That there is a composition that says if you have ratcheted key exchange plus authenticated encryption you derive ratcheted encryption Now the problem that we are faced with when looking at this primitive and defining security And then finding provably secure designs for these for this notion of bi-directional ratcheting is That it becomes very complicated since Alice and Bob can Interactively concurrently send and receive and the adversary can adaptively multiple times exposed to the state and therefore We are looking at the single components of the bi-directional ratcheting setting and therefore We are looking at different variants of ratcheting and the first one that we consider here is the the unidirectional key establishment So in this setting Alice is only able to initiate the the computation of keys And thereby sends the ciphertext to Bob and Bob then unreceived can comprehend and compute these keys But Bob cannot respond and we call this the unidirectional ratcheting key exchange Which is very related to what Belaried Al did last year, but we will see the differences in a couple of slides The the second variant of ratcheting that we consider is the sesquidirectional ratcheting key exchange And in this setting Bob is also able to respond and thereby contribute information to the session and thereby Alice is able to receive this information and The ciphertext from Bob to Alice do not have the same functionality as the ciphertext from Alice to Bob have they only have The idea that this adds security and provides stronger security guarantees for the session between Alice and Bob And we call this the sesquidirectional ratcheting key exchange because sesquidirectional means one and a half And we consider these ciphertexts from Bob to Alice to have only half of the functionality And finally if we allow both Alice and Bob to establish keys, which makes them being in symmetric rows We call this the bidirectional ratcheting key exchange and this bidirectional ratcheting key exchange can actually be generically composed from two instantiations of the sesquidirectional one, which you can see in our extended version now what we have as contributions of our paper and what I'm looking at during this talk are models and security notions for unidirectional ratcheting key exchange and sesquidirectional Ratcheting key exchange plus in our extended version the bidirectional one and we also have provably secure Constructions and as I said before the former variant of ratcheting is related to what Bellarie et al did last year But what we also allow the adversary in this setting is to expose the state of Bob Which then requires stronger security guarantees from the construction Now when defining security we have to define what the adversary is actually capable to do and how he can behave So as I said before the adversary controls the network between Alice and Bob which means that the adversary can control the ciphertext Modify them and trigger sending and receiving of Alice and Bob And we are looking at the security of keys Which means that we require the indistinguishability of the real established keys from random elements from the key space and thereby the adversary can challenge multiple keys in this in the session and thereby either obtains the real keys or random keys And at the end has to guess whether it always obtained the real keys or random keys now finally in Order to model what we are actually looking for which is the exposure of states is the adversary is now able to Adaptively in multiple times expose the local states of Alice and Bob We are looking in our in our environment at single sessions And this can be done since we abstracted the initialization away And thereby we do not have any long-term secrets for Alice and Bob anymore And therefore we do not have to look at more than these two parties can communicating in a single session Sorry, so now to define the security for the unidirectional Ratchet thing we look at the primitive that allows Alice to send and Bob to receive and we exclude these trivial attacks Which we know of that the adversary can trivially win the challenge that is embedded which is the security of the keys and The first trivial attack that we need to consider our impersonations of Alice towards Bob So if Alice is exposed by the adversary the adversary can use this state of Alice to invoke the scent algorithm itself And then of course know which keys Bob after receiving these own made cypher text from the adversary Which keys Bob will compute in the future and therefore keys that are computed after such an Impersonation by Bob will not be challengeable by the adversary anymore Another sort of trivial attacks that we need to consider since we allow the exposure of Bob are the the trivial attacks that result from this exposure and What the adversary can do after exposing Bob is the adversary can take the state of Bob and then invoke the receive algorithm on the Ciphertext that are sent by Alice and thereby the adversary can compute the same keys as Alice and Bob will do in the future after such an exposure, but there is one exception for this trivial attack, which is that if The adversary previously manipulated a cypher text from Alice to Bob then due to this manipulation the state of Bob Might be diverged and we require actually that the state of Bob is diverged from Alice's one To obtain full security and therefore the state of Bob is not compatible with Alice's anymore And as a result in exposure after such a many manipulation Does not result in a harm of security of keys established by Alice anymore There is one final observation that we make in this setting which is if Alice's state is only exposed But then the adversary does not use it for impersonating her towards Bob Then this does not harm security of any keys at all So when constructing this primitive we need to consider both this trivial attack and the latter observation Now in the construction if an exposure of Alice Soleil is okay Then we need some kind of public key cryptography Because the state of Alice must not reveal information on keys computed in the future directly and what we use here Is simply a key encapsulation mechanism with which Alice encapsulates towards a public key of Bob and then sends the Cypher text and Bob then decapsulates with his secret key What we need since after an exposure of Bob only future keys are Leaked to the adversary we need that previous keys stay secure Which means that we need an update of Bob's state that is forward secure What we also need as I said before is a mechanism that diverges the states of Alice and Bob after manipulation of a cypher text from Alice to Bob and What we simply or what Bob simply does is he uses a random oracle on the input of the previous Transcript plus the key that was the symmetric key that was recently Decapsulated from the chem and the output of this random oracle is then the actual established key between Alice and Bob Plus a new secret key for the next invocation of the decapsulation of the chem And one can think of the secret key being the random coins that are used for generating a new key new chem key pair now in order to comprehend and Yeah, obtain the public key that is compatible with Bob's secret key Alice simply uses the generation algorithm that uses these random coins or the secret key to obtain the public key and This is what our construction for the unidirectional setting actually more or less looks like so Alice encapsulates I use the random oracle and Jen generates the public key and Bob decapsulates and also uses the random oracle to update the state Now to define security for the cesspey direction or agitating We again have to adapt the model. So what we need to do is we need to add the sending algorithm for Bob and the receiving algorithm for Alice and We also need to adapt the trivial attacks and the first trivial attack that we need to add is the impersonation of Bob towards Alice so no of yeah of impersonating Bob towards Alice Since Bob can now be exposed and the adversary can use the state of Bob To create an own ciphertext from Bob to Alice This simply impersonates him and this is a rather simple adaption What is more evolved is that an exposure of Bob can now be recovered. So as soon as Bob sends after such an exposure Bob is able to contribute new information to the setting which means that After sending after an exposure Future keys will be required to be secure again So only the keys that are immediately Established after an exposure are again treated to be not challengeable for the adversary But after receiving new information after such an exposure K a 3 in the lower left corner and the lower right corner For example is required to be secure again and This trivial attack then requires from our construction stronger security Guarantees for the building blocks for sets pre-directional ratcheted key exchange now When looking at this construction, we see that due to this recovery of Bob's Bob's state we need an update of Bob's state that is both forward secure and also helps him to recover from such an Exposure and what Bob simply does is Soon as he sends he just simply generates a new cam key pair and sends the respective public key Back to Alice which she will then in the future use to encapsulate towards with the next send invocation What we still need is the divergence of states between Alice and Bob But this becomes now very much more complicated because Alice and Bob can send concurrently at the same time and Therefore as soon as the adversary manipulates a cipher text This still needs to result in a divergence of states, but this needs to be handled a bit more complicated So the requirements here and which I think is interesting for this construction are That the divergence of states needs to be computed independently forward securely and with respect to this asynchronous bi-directional setting Now what Alice and Bob need to do is they need to update their part of their key pair So Bob needs to update his secret key with respect to a transcript to a new secret key and Alice needs to update Her public key to with respect to maybe the same or another transcript to a new public key And the update of Alice essentially must not leak the secret key that would be updated Similarly and as a result we cannot use this construction with a random oracle anymore But what we can use is something that is related to hierarchical identity-based encryption And the secret key update is then similar to the delegation of a secret key in the HIB e to a new hierarchy So in which the ID is something like the transcript And this is more or less what our construction for the set speed direction is setting looks like So we have generation of new key pairs as soon as Bob sends and the update of the part of the key pairs as soon as Alice or Bob receive Now finally Providing you a summary of the results the unidirectional ratchety key exchange requires a cam plus the random oracle and Also message authentication codes to authenticate the ciphertext from Alice to Bob, which I didn't mention during the talk What I also didn't say is that in the set speed direction is setting the public keys from Bob to Alice need to be signed Plus we need this key updates the book key encapsulation mechanism Which allows Alice and Bob to update their part of the key pair? And it may sound very inefficient to use something that is related to HIB e to construct this Primitive but actually the number of updates of a key pair equals the number of ciphertexts that cross on the network So if Bob sends a public key and at the same time Alice sends to ciphertext Then the public key and the secret key only need to be updated twice and therefore the depth of the HIB e is Yeah, actually not too impractical What I also didn't mention is that Alice and Bob need to encapsulate No, sorry Alice needs to encapsulate multiple times if she recently received multiple public keys But for example, if there is a central server that enforces a ping-pong pattern between Alice and Bob Then this can yeah, this is not a huge problem anymore And we will see that there is an alternative for this in the next talk in which we will see a comparable construction, but they use instead key-updatable signatures and Finally as I mentioned before one can construct the practically relevant bi-direction and tragedy key exchange from two instantiations of the sets we direction a tragedy key exchange Generically plus using one-time signatures and we highly recommend to do so because understanding the the bi-directional ratchety key exchange security notion and What it requires from this primitive is very complicated and therefore we think that the construction The generic construction which you will see in our extended version that is linked there Is actually sensible, so thank you very much for your attention