 Hi, this is Chong from Ruggles University, and next I will give the talk about my recent work which is Indefinitability for Public Key Crypto Systems. And this is the joint work with Moxentry. And let's start. In the real world, when we design a crypto primitive, it would be very hard to predicate how it would be used. For instance, here we design a PKE. For some systems, maybe the software developer just wanted to be CCA, and for some other systems, it might use the one wanted to be liquid resilient, or they related K attack secure, and so forth. And the fact is that the games that achieve different security models are quite different. And even worse, the software developer even doesn't know what kind of security model it want to achieve, and maybe they just plug our primitives into their systems, and in fact they see it very dangerous for security. So another question is the following. Can we design a magic scheme that capture all the security models to rule them all? And to answer this question, the typical solution is that we can think about the idealized model, and let's have a recap of the recent work. For that function, the idealized model is random oracle, and for block cipher, the idealized model is random K documentation, and for groups, of course, it is generic group model. And there is a recent interesting paper by Bobosa and Fashim. They formalized the ideal secret encryption as the random K injection. And the question is that what's the idealized model for public encryption, or any primitives in public siting? This is quite unknown yet, and this is what our work is going to do. In our work, we can think about three primitives in public siting, which are NEC, non-integrative K exchange, public key, and digital signature, and we propose three ideal notions for them, which are ideal NEC, ideal PKE, and ideal signature. And due to time limits, we would only focus on the first one, ideal NEC. What is ideal NEC? As we discussed above, we know that it would be idealized model for NEC, and how can we interpret it properly and firstly simplify the NEC as follows. Here it only consists of two algorithms, KG and shared key. KG takes the secret key as input and out-puts the public key, and the shared key takes the public key and the secret key as input and out-puts the corresponding shared key. And the correctness requires that the shared key of PKE1 as K2 is identical to the shared key of PKE2 and SK1. And next, let's apply the Bobosa and Fashim's idea. Here we just formalized the KG as a random injection, and the shared key here is a random function. Does it work? Unfortunately, no, because we call that for NEC there is additional correctness requirement for this. So we have to make sure this sentence works. And to do that, we need to define as follows. Ideal NEC here is a random tuple of functions subject to x, y, z, where NKG is an injection such that maps x to y and SK is a function that maps x times y to z. And for the correctness, we require that for any x1, x2 in x, this equation holds. OK, here, this is actually the definition of the ideal NEC. And next, we go to the construction. We see that the ideal NEC is an idealized model, and of course, it does not exist in the real world. So when we talk about the construction, we need to construct it in another idealized model, say random molecule model. And to do that, we have to apply the indifatibility framework, which was proposed by Merrill, Renner, and Holliston in 2004. And in the indifatibility framework, they say that the construction is as good as ideal NEC, NKG, and SK. And more detail, indifatibility involves two worlds, the real world and the ideal world. The real world, it consists about the construction and the random molecule, and where the random construction has access to the random molecule. And in the ideal world, it consists of the ideal NEC and the simulator, where the simulator has access to NKG and SK. And for any adversary, the adversary has access to all of this. And the security of indifatibility is to show that these two worlds are close to each other. And one thing I want to emphasize is the framework of indifatibility. Everything is under-controlled by the adversary, which means the secret key, the randomness, the nonce, everything is controlled by the adversary, and they can be chosen in any related version. And the next question is why we choose indifatibility. According to the theorem, we know that if our construction is indefensible from ideal NEC, the construction is secure in many adversarial environments in the random molecule model. And those environments include the shared key, the unpredicated shared key against the active attacker, liquid resilient, KDM, RKA, and you will more combined secure. Which means that we ask game can be both liquid resilient and KDM. And it also covers some unknown yet security. As a last, the security game can be represented by a single state game, or the indifatibility framework covers that. Okay, next question is what's the hardness of this work, and what's the barrier? We know that the thing we are concerned about is in the public setting, and due to the famous separation is out by impact is as though and the RUDIC, we know that random molecule itself can never be sufficient, and we have to add a new nutrition. And here we add a standard model NEC as the additional nutrition, and we try to combine these two together. However, the barrier is falling. I do like has no structures. Well, the standard model like always, not always often has structures that when it applies like groups or LWB, they have some structures, and those are the barrier, and that's the different, and that's the barrier. So we need to combine these two things together to make sure that our indifatibility model NEC has no structures from the outer layer, but in the inner layer, they still can use the struct things to run the public setting computation, and that's the main barrier and the strategy. We combine these two things together, and here is the summary of our work. We firstly bring in the indifatibility to the public setting and propose the three notions, which are ideal NEC, ideal PKE, and ideal digital signature. And then we built an indifatigable NEC from random molecule plus double-strand CDH assumption. Here double-strand CDH assumption is the CDH assumption associated with the DDH oracle. And then we built indifatigable NEC, PKE from ideal NEC plus random molecules, and then apparently we built indifatigable NEC from random molecule plus binary CDH assumption. And again, due to time limit, we would only focus on the NEC result. Okay, here's the outline of this talk. Firstly, we gave the NEC construction, and then gave the intuition of the simulator, and then we conclude for the construction. Now the NEC consists of two algorithms, KGIN and SHEDKIN, and firstly, let's make the KGIN indifatigable. Again, the strategy is that we try to combine random molecule and the standard model into an indifatigable NEC. And we denote this lower case, KGIN, SHEDKIN to be the standard model NEC, and for the upper case, we denote the ideal case. And to, and recall that the main barrier is that the KGIN has no structure, has structures, and the NKGIN has no structures. How can we do that? The one trivial attempt is we just hash it, we just hash it just like this. And does this work? Let's see. Here's the attacker which choose the SKS, SKSTAR itself, and it generates the KGIN SK. It generates the KGIN SKSTAR and asks the simulator what's the hash value of this KGIN SKSTAR. And we see that the simulator at this stage. It knows nothing about this SKSTAR. It only knows KGIN SKSTAR. And by the security of the NEC, we know that it gave the public KGIN knows nothing about the SKSTAR, so the simulator with the files. And the reason why the files is that the simulator knows nothing about the SKSTAR. And how can we fix it? We add a new hash function in the inner case. We hash the SK first. And why this helps? Let's see, when the adversary wants to do this again, it enforces the adversary to make this query before the H1 query. And once the adversary makes this query to the simulator, then the simulator has the SKSTAR information and would answer this query with a KG SKSTAR, which is a proper answer. Does this work? Seems to. The thing is that once we hash this KGIN, then we destroy the group structure. And once we use the hash of H1, then we can never use the KGIN values anymore. And again, we are concerned about the primitive thing in the public exciting. And the KGIN is the thing we have to use. And to do that, we are going to replace this H1 with a permutation. And in this permutation, from the outer layer, it still looks like a random screen. But there is a inverse that we can help us to get the KGIN value. OK, let's see how could we make the shared key? Indifferentiable. The construction, again, the construction should be the shared key. The shared key also has some structures. And to get rid of the structures, we also hash it. And let's see if we do that, what kind of the potential attack? We see that H0 or SK1 is actually the lowercase SK1. And this is represented in the lowercase of pk2. And we know that in the framework of incompatibility, the adversary can choose everything and control everything. So the adversary can choose SK1 itself and choose another uppercase SK2 and form the following query attack. This one, we see, is represented to the pk2. And once the adversary has the pk2 and SK1, then it can calculate this one itself and make this query. After the query, the attacker makes this query, make it the pkGIN SK1 and which corresponds to the pk1. And the test, whether the answer of the SHK is equal to NSK pk1 and SK2. And we see that in the real world, this equality always passes, always identical. While in the ideal world, we see that the simulator, in this step, knows nothing about all of these things. And we see that the answer of this query should be this value. And there are two ways to get that. One is known as SK1 and another is known as SK2. Of course, it cannot know SK2 because it was chosen by the adversary. So the only possible thing is that the adversary knows SK1. However, if we do that, there is no chance for the adversary to know the SK1 at all. And to do that, we would, and to prevent it, we would enforce the adversary to hand in this pk1 before the hash. What should we do? We add the pk1 into this hash. So this is our solution. We add pk1, pk2 also associated with this one in this hash. Which means that the adversary has to switch the order of these two queries. And once the adversary makes these queries to the simulator, then the simulator would run some trick which we will explain later that how it would know SK1 here. Okay, here is our construction. And next, let's see our simulator. Let's firstly see the goal of the simulator is to simulate h0, p, p in worth and h1 properly. And how can I understand this properly? The response of h0 and h1 should be random strain and the response of p and p in worth must be random permutation. Moreover, these two equations must be held because this equation holds always in the idea in the real world. And to do that, the simulator must be stateful and in fact here it would keep four tables, h0, p in worth and h1 tables with this variable form. And let's see how could the simulator answer these queries by using these four tables. For the h1 query, we see that the input is the up case SK. And firstly, it would check whether it's in the h0 table. If in, then we are happy. And next, we will check the p in worth table and check whether the nkgsk is in the p in worth. And if in, then we would answer this SK as a corresponding result. Why we do that? Because the third equation we need to present is that nkgsk both involves p and h0 and we need to keep the equation consistent always. And that's the reason for the h query it would also check both h0 and p in worth. And if we cannot find anything in these two tables, then it randomly sample SK and insert this part into h0 table and answer SK as the answer. And now for the p in worth table, which takes the up case pk as input. Firstly, it would check p and p in worth table if in, then we are happy. And next, same again, it would also check the h0 table and check whether this one is in the h0 table if in, we are also happy. And next, if nothing found in these three tables, we would sample a random secret key and response the value as the kgsk as the response. We know here is the gap. In the real worth, the answer is a random string. While the ideal worth, this is a random public key and this is the gap. And to make sure these two deductions are closed, I mean a computational close, we need a security requirement which is still the random public key, which means this part is still the random. So it's a computational close to the random string. That's the hello idea of the p in worth query. And next, let's see the p query. And in this p query, so we will show how the simulator tries to prevent the attack we illustrate above. Firstly, again, it would check the p in worth and h0 table if in, then we are very good. And next, if nothing found in these three tables, it would samples as k and insert this thing into the p table and would answer this one as the response. We see that this one is well-formed because NKG is a random injection. And the thing is that why we do that, this technique? How can, why we cannot just use a random string? If we just use a random string and how the SSK gives additional power? We recapped the attack we illustrated before and we see this part represents the pk1 and this part illustrated as the lower pk2 and it would query this one and would test whether the answer of this one is analytical to the nsk pk1 and sk2. And we see that in the answer of this first query, the simulator would choose the upper SK itself and save it as the inner state and would use this one to answer some queries for the filter which is for the query for the third query, it would answer it by skpk2 sk1 and we see that this is pk2 and this is sk1 and of course the simulator can answer it. And this is the technique that the simulator how to prevent this kind of attack. And for the h1 query, firstly check the h1 table and then using h0p and pn were stable to test the validity of this one. And if we cannot use h0p and pn were stable to test the validity, then just replace it with a random string. And now let's see how could we test the validity. For instance, we say pk1 is in h0p, pk2 is in p. And then since pk1 is in h0p, then we know the lower sk1 and pk2 in p, then we know the lower case of pk2. So the simulator can calculate the shared case itself and test whether they are equal. If we pass, then we can answer it by sk sk1pk2 else that's random strings. And the underlying secure requirement for the shared key is that the shared key is unpredictable against an active attacker. Okay, here we gave the intuition for the simulator and by this simulator we can show that our knack is indifferenceable from the ideal knack. Okay, now we come to the conclusion. In this talk we propose three ideal, we bring in the differentiability to the public setting and we propose the three ideal notions which are ideal notions for the three primitives, ideal knack, ideal pke, and ideal signature. And we construct an indifferenceable knack in the random model and then construct an indifferenceable pke in the ideal knack model. And apparently we also construct an indifferenceable signature in the random model. And of course this is the first attempt to try to bring the differentiability into the public setting and we sincerely hope more works about the indifferenceability in public setting coming soon. And that's all, thank you.