 Hello everyone, I am Fatih Baili from EPFL and I will be presenting our work determining the core primitive for optimally secure ratcheting. This work was done in collaboration with Paul Rosler and Serge Woudinay. I would like to start by stating our contribution. In the context of ratcheting, we have recently seen two primitives, unidirectional ratcheted key exchange, or I will refer to this as URKE, and we have seen key-updateable key encapsulation mechanism or QCAM. We extend the security notions for these two primitives, such that we consider the randomness manipulation as a realistic threat in the game scenarios. And in these extended security notions, we show that these two primitives actually imply each other. This informally means that building strongly secure ratcheting in itself is as hard as building key-updateable public key primitives. Then I will first, in this presentation, then I will first talk about URKE and QCAM Star, and then I will talk about how we extend our notion so that we consider randomness manipulation, and then I will give a very brief explanation of how our constructions work for two directions. In the recently published two papers, one by Pertrink and Rezler, we have observed something. In crypto 2018, they have defined the idea of the security notion of strongly secure ratcheting as a mechanism that exchanges keys between two parties. In their construction, the authors had used what they called key-updateable key encapsulation mechanism. And this was, in return, instantiated with the use of hierarchical-identity-based encryption. In the same year, independent from the previous work, Jgrant's Tapanos also looked at the ratcheting more from a data encapsulation type of setting, and then they used key-updateable public key encryption scheme to build their construction. Again, this was built on top of hierarchical-identity-based encryption. Therefore, we wonder whether key-updateable public key cryptography is, in fact, a necessary building block for strong ratcheting, and that is the question we respond affirmatively in this work. So let us briefly talk about ratcheting. So in this figure, you can see actually what a real ratchet looks like. It's a type of wheel which can rotate only in one direction, and there is a device called pole which prevents it going in the reverse direction. In the context of cryptography, it has become popular thanks to the signal messaging application because it promises two things to users. It's post-compromise secrecy and the forward secrecy. And these are important especially nowadays because we generally tend to have our phones for a very long time and then it is quite probable that they contain the same application and then the same state inside those messaging applications. A simple analogy here is that the pole in this figure is the key-updateable public key cryptography and the wheel is the messaging application. Let us look at these two notions very briefly. In a more conventional example, one would first set up a shared key between A and B which would be then used with the symmetric cryptography to exchange messages. However, this comes with this advantage because if one of the parties state is exposed, then all of the past and the future ciphertexts can be decrypted and the messages can be recovered by the adversary. Therefore, we want to have an improvement over this. The post-compromise secrecy means that if a state is exposed by a party and at some point in the future, the communication itself will heal. In return, forward secrecy means in the reverse direction. If the communication happened in the past and if the state is stolen in the future, then the old ciphertexts should not be decrypted by the adversary. From a more formal perspective, ratcheting is actually a tuple of algorithms. It consists of a send and receive. It will create states for two of the parties, SA and SB, as denoted in here. We will give SA to the party A and SB to the party B. In order to establish a key between A and B, A can use the send algorithm during which a key is derived on the fly and then the state is updated and then another ciphertext is passed to the B. From the syntax perspective, the algorithm looks like this and it takes an additional associated data, which is an optional data and it could be empty if the user desires so. On the B part, we can similarly run the receiving algorithm. It would take the state SB, the same associated data, and it would recover the key from given ciphertext. In this case, we call it URKE because we look at the unidirectional case, meaning that the key update operations are only triggered by A, but it doesn't necessarily mean that we cannot send messages to A. That is definitely possible. It just means that B does not initiate these key update operations. In previous work, there has been actually some approach to define the security of this redshitting. First, there was an analysis approach by Cohen and Gordon et al. They tried to extract what security guarantees signal actually gives in the formal setting and then it was followed by simple definitions and then later by bidirectional version, again in crypto 2018, two referred papers in the previous slides. More recently, we have seen more relaxed security notions, meaning that they are not necessarily the strongest and the game definitions contain some arbitrary attack eliminations, so to speak, but then they lend themselves to very efficient constructions. In comparison, in the third bullet, we have only constructions based on hierarchical identity, based encryption. Let us look briefly about what a security game for redshitting looks like to get the idea. Of course, it contains a few oracles with which the adversary can interact. The adversary, for example, at the beginning of the game, A and B both receive and synchronize states and the adversary can use send A to trigger sending operation and then make A generate some ciphertext C1. Similarly, it can run receive B and then it can pass either the real ciphertext or something else, so the channel is controlled by the adversary. The adversary also have the power to expose the state of B. It can ask for some ciphertext keys to be revealed. It can also expose the state of A and eventually at some point it picks some ciphertext and challenges that ciphertext. The game gives either the real key for the ciphertext or the random one and the adversary tries to guess which is the case. The real problem in the actual definition is what defines the trivial attacks in such a complicated setting. In some cases, we see that these not necessarily trivial attacks are prevented from adversary, which means that the games are not necessarily the strongest ones. And in those cases, you can actually employ classical public key cryptography and then you can just make do with those and then have a provable security with respect to their own definitions in these papers. But in this particular cases, what happens is that we don't know a construction without hierarchical identity-based encryption. In fact, all of them are using a tree of them are using a key-updatable public key crypto. This work is actually focusing on this aspect of the wretched thing. I think I have talked quite enough for the wretched thing part and I would like to talk a bit more about the key-updatable part now, key-updatable public key crypto more precisely. So let's start with simple-chem example. In the simple-chem, you would have a tuple of algorithms in it encapsulate and de-capsulate. In it would generate a public key and a secret key and then sender could use the public key to encapsulate some keys. Cypher text would be sent to the receiver and then in the de-capsulation, the receiver could retrieve the original key and then they could use this key and with another symmetric encryption scheme to exchange messages and then similarly they could do multiple encapsulation and de-capsulation invocations. In the key-updatable variant of the scheme, now we will introduce two additional algorithms, update sender and update receiver. Update sender will take the public key and then provide a new public key for the sender and similarly update receive will take the secret key from the receiver and update into a new one. But it is very important to notice that there is actually no interaction between these two algorithms. So these are run separately and independently and the correctness notion of course requires that these two states are synchronized in the sense that they can still encapsulate and de-capsulate. From a syntax perspective, we also include associated data as input to update sender and update receiver, but that is not a part of interaction at all. In one more incremental step, now we can talk about the stateful variant, that is the stateful key-updatable chem. In this one, what we tweak is the encapsulation and then the encapsulation algorithms. In a way that encapsulation also takes the public key and then updates the new public key and similarly the encapsulation takes the secret key and updates the new secret key. Therefore, it seems as if the encapsulation and de-capsulation also do some inherent key updates or state updates on each of the parties and also there is still the separate update state and update receiver, update sender and update receiver algorithms in the definitions. It should be noted that encapsulation and de-capsulation update through some communications, whereas update sender and update receiver is actually without any interaction. And how does one actually define the secret notion for QCAMP star now? It's actually quite similar in the fashion we define for the ratcheting. So again, the adversary has access to a bunch of oracle, which can trigger the parties to update their state and at the same time produce some ciphertext. It can also ask ciphertext to be solved, meaning that the keys given to the adversary updates are also part of the oracles now. And eventually the adversary is supposed to challenge one of the ciphertext and actually guess the key. So this type of notion is not indistinguishability, but it is more of a one-way meaning that it is much weaker. We intentionally made it so, and then we actually have an incentive to make the security notion as weak as possible, because our ultimate goal is to actually make a bridge between something quite so strong, that is the ratcheting, and something possibly easier to build, that is hence the one-way notion here. Now I want to talk about the randomness part of our contribution. So far in the very high level picture of the security notions, I did not really talk about the randomness at all. But we can look at the randomness approach taken by the other two papers. First, Pochring and Rezler in their paper, they had actually considered the naive approach, which means that the encapsulation algorithm was always assumed to be using secure and then the good distribution of randomness in the algorithms. In comparison, Jgrin Stepanoz did a bit of different approach, because they were allowing the state exposures, they also allowed the state exposure similar in the randomness use, so they assumed that the adversary can actually read the randomness used by the algorithm as well. But in this particular work, we want to consider something even more stronger so that it captures multiple realistic scenarios. In this third bullet, which I call inclusive, or as we sometimes refer to it as randomness manipulation, is the case where the adversary can actually control the randomness. This also captures a couple of scenarios. For example, it captures the scenario where the adversary partially picks some bits of the randomness, not necessarily all of them, through some kind of backdoor mechanism. Or it captures the case where the adversary knows some partial information on the entropy pool, but not necessarily the specific invocation random coin of encapsulation. Or maybe there is no malicious intent behind, it's just the library that has a bad distribution for randomness generation. And in that case, it's possible that the library is fixed later, and then this is maybe the update is pushed to the devices, and then maybe devices will eventually have the actual correct implementations. So our approach is again similar to the initial healing property here. So as soon as this attack vector is eliminated, which is disturbing the randomness, we want the communication to heal back to a secure state. I can maybe explain this more simply by this drawing here. Again, let's remember the unidirectional reticent exchange, and it's accompanying security notion. There we had the send A oracle, which was triggering A to produce NIF ciphertext. And at the same time, A was internally updating its own state. Here, the adversary can, in the updated notion, the adversary can either query as before, or the adversary can enforce some random coins to be used. So in this particular example, let's start with a healthy state. If it is healthy state and if A uses good random coins, and then it actually initially arrives to a healthy state. But let us assume at this point, adversary exposes the state and learns what is the information here. And then suppose that the adversary further uses bad random coins, so the adversary actually picks the random coins and therefore knows the random coins, and uses this algorithm. And at that point, of course, this state information is also known by the adversary, because this algorithm could be run by the adversary in parallel. And now we consider the case where the adversary actually lets A run the honest random coins. And at this point, we expect the protocol to recover back to a healthy state, and also the emitted ciphertext we expected to be secure. And at this healthy state, if the adversary now injects random coins, again, we expect to arrive to a healthy state, and we expect to emit a healthy ciphertext. And similarly, regardless of how many times the adversary tries to inject with the bad randomness, as long as the adversary never exposes the state information through an oracle, we expect the communication to be secure as long as it goes. Therefore, this new notion actually captures something so stronger. In that, a ciphertext CI is compromised if two of the conditions are satisfied from the adversarial perspective. If the adversary knows the SA, the previous state that is, for example, in here, the previous state for C2 is known, and also the random coins used to generate C2 is known. And that is the only case that actually leads to vulnerable days in this new setting. I'd like to repeat my contribution statement again. So I said that the building retching is as hard as building key-updateable public key parameters in this randomness manipulation setting. For that, of course, one needs to show that one implies the other and then vice versa. Let us first look at the QCAM start to URK transformation. So here, QCAM start, again, as we've seen before, it consists of five algorithms, encapsulation, decapsulation, update algorithms, and then the initialization algorithm. And in the URK, we actually want to build three algorithms and basically generation, and we want to define the send and receive algorithms. For that, we start by running the generation from the QAM algorithm, public and secret key. On top of that, we embed some shared key, which is uniformly sampled at the beginning, to the state of A and B. In order to send, this is what A does. A first uses this public key and encapsulates, and the ciphertext is the one that will be sent to B, but the key output of the encapsulation will not be used as the key of the receive. Instead, we will use this key KE, and then we will merge it with this shared secret key and then we will query a hash, and then we will take the output of the hash as the key. For the send algorithm, we are done with the KE and the ciphertext. Now we have to think of the state information here. So we will again need some kind of shared key and then the public key. For shared key, we can again take the key as an output from the hash function. For the public key, we can first use the nif state from the encapsulation, and then we make an additional update from here, and then we arrive to this state. And here we pass some AD information to the update as well. On the receiving part, things are just similar in a synchronized fashion. Because our ultimate goal is to derive the key, we have to make sure that the hash function gets the same inputs. KS is already here, so we have to compute KE, which can be done with the encapsulation of the ciphertext. And again, the other state update operations are similar. So we update the secret key by going through the same path. We feed the same AD to the update, and then we obtain a synchronized state with this one. This is actually a simplified version of our construction because I omitted some other details. For example, there is a mechanism which ensures that this ciphertext is authenticated and then B actually checks the authenticity of the ciphertext before feeding it into the encapsulation oracle. Let us look at the reverse direction. How can we construct from URKE to QCAMSTAR? In this case, we want to build four algorithms or five if you consider generation as well. We want to first think about encapsulation. In order to encapsulate, we actually do two send invocations. But the first one with the random coins and the second one is with the fixed random coins. So the second one is actually acting like a deterministic algorithm here. And then the ciphertext information that we pass is actually the ciphertext from the send invocation. Also, we pass the intermediate state SA here. In the receiving part, notice that in the secret key of the receiver, we actually have the SA at the beginning, which is exactly the same with SA here, but we also have the SP, which is synchronized with SP. So we will use the ciphertext and then call the receive and then we will get this SP. This intermediate value is obviously synchronized with this SA. Because we don't have the SA yet, we will actually take it directly from the ciphertext and then simulate this deterministic algorithm and then follow the path accordingly around the matching receive for the simulation and then update the SP accordingly and then update SA accordingly. So that is how encapsulation and then decapsulation would work. For updating, the idea is similar. In the update case, we would actually just use send deterministic by fixing the random coins. Again, on the receiving part this time, we have to self-simulate the sending and then use the output ciphertext to the receive and then update SA and SP accordingly and then obtain this state. Here, an optional AD can be fed to send algorithms as well, but this is another requirement. Therefore, these updates are actually without interaction, whereas this encapsulation decapsulation is with the interaction. Again, I omitted some details which ensure the authenticity of this ciphertext. There is actually some step which runs before this c being fed into receive so that the adversary is prevented to do some malicious ciphertext-feeding attacks. Okay, so the follow-up is this research could be as follows. First, we have so far looked only at the unidirectional case of recited decay exchange because of the complexity introduced with the randomness manipulation. Introducing randomness manipulation takes a bit of toll on the security notions because now we have to rethink of all the trivial cases again and redefine clearly which new cases are introduced into security notion. And then the follow-up work could prove equivalence between QCAM star and this new bidirectional recited decay exchange. Doing so has this benefit of focusing on finding the efficient QCAM star primitive because of the informal statement that we have, we can just focus on the QCAM star primitives which are easier to construct because the notion is much weaker because we only target the one-way security here and the definition is much simpler. If we can build them much more efficiently without resorting to hierarchical identity-based encryption we will eventually have strongly secure reciting and I think that is the takeaway from our paper. With that said, I conclude my presentation. Thank you very much for your time.