 Thanks for tuning in. So I'm ready. I'll be talking about leakage-resilient connection and true seed extractors. This is done work with Sydney, Furnima, and Daniel Wittes. So throughout this talk, we'll be interested in connection. We have two parties, Alice and Bum, who'd like to agree on the shared key. But they do not start with such a key to begin with. So they'll have to execute some protocol. And at the end of the key share protocol, Alice and Bum will be able to agree on some uniform key. So we'll be considering some particular cases of key exchange and particular non-interactive key exchange, where the messages that Alice and Bum sent to each other do not depend on the other party's message. So in other words, they do not have to wait for each other's message to send theirs. And they could send them simultaneously if they wanted to. The kind of security we'll consider is secreting against passive adversaries when there's a new dropper, Eve, who has access to the channel Alice and Bum are communicating over. And we want to say that even if Eve sees the messages that Alice and Bum sent to each other, then the key that they agree with should look uniform. And we'll call a protocol that satisfies those two properties a non-interactive key exchange or NEC. So this talk will be dealing with another layer of security called leakage resilience. So in general, Alice and Bum will be using some internal randomness in order to execute the protocol. And the basic question that leakage resilience asks is what happened if this randomness isn't reliable? So that could be caused by several reasons. For instance, Eve could have some kind of backdoor access to Alice and Bum's devices and learn some information about those randomness. Or Alice and Bum cannot reliably produce uniform randomness needed for the protocol execution. So here, what we'll be considering is the bounded leakage ceiling, where Eve only gets a limited amount of information about Alice and Bum's states. So for instance, Eve will be looking at all of Alice's coins, produce a small digest, and do the same for Bum. In general, we want security to hold, even if Eve is given those leakages. So it turns out that this has been a very well-studied problem before, and a generic method called privacy amplification solves this. But the solutions that exist require the use of some additional randomness. So Alice and Bum will have some additional randomness compared to the original protocol. And we can prove that the new scheme would be leakage resilience after privacy amplification, as long as those green coins are leak-free. So as long as Eve does not get any leakage on the green coins, then the protocol would be leakage resilience. But we do not really want to make such an assumption, as it kind of defeats the purpose of leakage resilience in the first place. So what we're considering here is seeing why we don't have this kind of randomness. When we call a leakage resilience, if security holds, if Eve gets some leakage on all of Alice and Bum's states, that is necessary to run the protocol. So notice that if we allow such a leakage, it actually makes sense to consider leakage resilience in a setting where Alice and Bum start security that they share in the first place. So that could be motivating for instance by them sharing a key, but then their states being compromised. So they know that some leakage might have happened, but they might want to refresh their keys somehow. And because this is a weaker setting than the public key one, we can actually hope for information through the constructions. So that's a setting we consider. So in particular, the leakage resilience will here allow Eve to get some leakage on Alice and Bum's entire state to then consist of both SK and their random codes. So now I can describe our contributions. Our first contribution will be to consider this symmetric key setting that I just talked about. And we show that there is a strong connection between such symmetric key exchanges and some random next extractor preview that we call true-seed extractors. And it turns out that those true-seed extractors are in turn intimately connected with communication complexity. And it turns out that using communication complexity or bounds, we can get information in certain constructions in the symmetric key setting. Our second set of contributions will be in the public key setting, where a prototypical example would be the Diffie-Hallman key exchange. So you can think about that when I'm talking about public key Nike. One question you may ask is, for instance, is Diffie-Hallman leakage resilient? So we show a broad black-boxing possibility result, actually, that rules out some class of reductions for any Nike under a large class of assumptions that we call single-stage cryptographic games. When in particular, those cryptographic games include most commonly used cryptographic assumptions, including very powerful ones such as IU. Then, given this black-boxing possibility result, we actually show how to build standard Nike that is leakage resilient in some alternate settings that kind of circumvent this black-boxing possibility result. So I'll detail what does our laser. And so this is for the talk. Focus first on the symmetric key setting and their connection with two CD extractors before turning to the public key. So just to recall, this is the symmetric key setting where you have two parties that is above who share some secret key. What do we want? Well, we want some leakage resilient Nike in-game, but we'll consider a very particular case where Alice and Bob send their entire random tapes to each other as the entire protocol. So the protocol is literally Alice and Bob sending their random tapes. And then there'll be about to compute a secret key using some function F. So F will take as input the secret key and the random tapes that is in to each other. So for security, we want that this final key should look uniformly random given those random tapes and the leakages that the issupper gets. So what we notice is that this has a very strong flavor of random extractors. So you can consider the secret key SK should be the source of an extractor and the random tapes that Alice and Bob use as a seed. So to be more precise, let me define what true seed extractor are. So a true seed extractor will take three inputs as input, a source and true seeds. So compared to before, the source again will be the secret key and the seeds will be the random tapes of the parties. So for security, what we want is that for all leakage functions, then the output of the extractor should be uniform given the seeds that are used and the leakage that the issupper gets. So what it means is that the source is jointly correlated with the seeds, with each of the seeds independently. We would like still the seeds to extract some fresh randomness out of the source. So the question now is, how do we build these extractors? Such extractors. But really, so we rely on communication complexity. So in communication complexity, you have several parties, Alice, Caroline, and Bob says that want to compute some function over the inputs. So they each have some inputs. And they want to compute the outputs of some function over an input so that they'll communicate with each other and try to predict some value. So the question we're asking is, how many bits do they have to communicate to compute this output? So we'll consider a slightly modified version of communication complexity where instead of just having one input, you can imagine that each party has a card on their forehead and cannot see what's written on the card on their forehead but can see all of the other cards. So in particular here, Alice won't be able to see x1, but will be able to see all the other inputs and similarly for the other parts. So we say that a function bigf has communication complexity commf. If in order to compute f, we say some good probability over random inputs, say, then the transcript that is generated by Alice, Bob, and Carol has to be at least commf. And because the f we are considering here only has one bit of outputs, another way to phrase it is that the size of the transcript has to be larger than this communication complexity in order to just distinguish the output of the function from a freshly uniform output. So this actually gives a connection with an extractor. So in particular, such a function bf would be a number on forehead extractor. In the sense that the output of the function looks uniform, even given the transcripts in the number on forehead model, that is smaller than the communication complexity of f. So this is an observation that has already been made before. And we also know how to build efficient functions f with high communication complexity. So how does that help us? The claim is that any such number on forehead extractor is actually directly a weak truthy extractor. And the main reason is I can simply rewrite the inputs so that the leakages that is given to the disengager can actually be seen as a valid number on forehead transcript, where here only Alice and Bob speaks in the picture above. So in particular, again, if the leakage functions have output size smaller than the communication complexity of f, then we have indiscriminately from random. So we are not quite done yet. Because what we wanted in the first place was a strong extractor where the indiscriminately should hold even given the seeds. So that's what we just showed and what we rather have. It's the same, but conditioned also on RNRB. So in the paper, we show that actually the construction above can be directly extended to have strong extractors instead with some parameters. But the intuition behind that is that we can convert any disengager for this strong version into a disengager for the weak version using the fact that the output of the disengager is, in some sense, again, a part can be thought as a part of a number of on forehead transcripts. So let me switch gears and turn to the public. So the basic setting is this, where Alice and Bob show some randomness, each have independent randomness and exponents. And Alice and Eve, sorry, get some leakage over those random gates. So for concreteness, you can think about disengager to be the different exchange, as is written in blue. So the basic question we ask is, what can we hope for in terms of leakage resilience for naked? So can we even get any construction whatsoever? If we're more optimistic, what can we hope out of, say, the different man exchange? Can that be directly leakage resilience? So in order to state or impossibility results, I'll have to define what's a single-stage cryptographic game. And such a game involves two parties, an adversary and a challenger, where the adversary is efficient, where the challenger is not necessary. And at the end of the interaction, the challenger can decide whether the adversary won or lost the experiment. So the assumption that will be underlying is that for all efficient adversaries, the probability that it wins is negligible. So this captures all common assumptions that we use in cryptography, again, including powerful ones such as HIO. If you're looking for a counter-example, well, leakage resilience, at least with respect to black box leakage, is a two-stage game where there are two, in terms of two states of adversaries, one leaker that will generate the leakage and one distinguishable that gets the leakage. And those adversaries cannot communicate with each other. I guess we are not ready to state the black box impossibility result. And the result states that there cannot be any black box reduction from the leakage resilience of an aching to any single-stage cryptography game. But by black box reduction, I mean, a reduction that treats the adversary and the leakage function as black boxes. So it's unfortunately a quite broad impossibility result. So in that look, Steyer, and possibly recovers this leaky version of the Diffielman connection. So in part zero, this shows that we won't be able to prove the leakage resilience of the Diffielman connection based on standard assumptions, at least with respect to black box reductions. But fortunately, there are some limitations to this impossibility result. So we will see what there are, and thankfully, they will give us some ways to build positive results. So the way we prove this black box impossibility result is using the meta-reduction technique that is a beautiful technique to prove those kind of results. Where we first assume the existence of a black box reduction that converts any adversary for leakage resilience into an adversary for the cryptographic game that we assume. So in particular, if we assume, so the proof we go as follows, we will assume that there's such a reduction, in particular, it would be efficient. When you return even an inefficient adversary for leakage resilience, ensure an inefficient adversary for the cryptographic game. So that doesn't contradict anything, this is fine. But the main insight is that if there's such an inefficient adversary for leakage resilience, that is, can it be related to an efficient adversary for leakage resilience, in a way that they are indistinguishable in terms of black box access by the reduction? Then we can also use this reduction to convert this efficient adversary into an efficient one. So that the adversaries for the cryptographic games are indistinguishable. But in particular, this new efficient adversary on the bottom right is actually a generic adversary for the cryptographic game. So in particular, this black box reduction gives a generic attack for the cryptographic game. But notice that this, we did so without breaking generically the leakage resilience of the key exchange. And the reason is that this adversary, efficient adversary for the key exchange, is syntactically not really an adversary. It's cheating somehow. But because the inefficient adversary is not cheating, the black box reduction cannot make the difference between them. In particular, this still gives a good attack to the cryptographic games in the end. Okay, so the only thing we have to show is how to build such adversaries. So in the case of a key exchange, we'll build our adversaries as follows. The inefficient adversary will have some random Morocco hardcoded in its head and will produce the leakage using this random Morocco. Not to distinguish if the leakage matches the initial message, then the adversary simply could force the final key. And in particular, as long as the Nike is perfectly correct, then this gives an inefficient adversary for the Nike. Okay, so how do we simulate such an adversary? The idea will be instead of having a real random Morocco will simply program the random Morocco on the fly and we'll call the chorus. So that's what the efficient adversary will do. And we'll simulate the adversary on the left. Again, by defining and sampling those fresh leakage values H of P on the fly. And then in order to break the leakage resilience, we'll simply look at the chorus made so far. In particular, as long as the leakage is large enough, then this efficient adversary simulates adversary on the left. In a way that is indisputable from the point of view of the black box reduction. Okay, so these gifts are impossibility results. In particular, it deals with black box reductions and schemes that have super rigorous leakage and perfect correctness. So those three points can actually be seen as limitations of the black box impossibility. So one may wonder what happens if we relax any one of these. And actually in the case of small leakage, we can show that any Nike's remain secure if the leakage is sufficient small. However, in terms of black box reductions of perfect correctness, we do not have any constructions and we leave as an open question. The construction of leakage resilience in Nike by just using either non-black box reductions or schemes that are only statistically correct in the first place. So another way we can circumvent this impossibility result is through the use of setups. So such setups may increment their common reference string that the trust party might generate or what do we call a leak-free pre-processing phase. So what is that? At least a moment, we know before starting the execution of the protocol, start with some run-up coins and we'll pre-process them into some states in such a way that the run-up coins that are stored with are leak-free. But that kind of goes at odds with what we wanted in the first place, that is leakage resilience in Nike, that is, that does not use any kind of leak-free run-up coins. But the main point here is that in our model, in the leak-free pre-processing model, at least some of them do not need those coins to execute the protocol. They only need it to pre-process the states and afterwards they can discard it. So as long as front-sensor devices have not been compromised before the execution of this pre-processing, then the protocol would remain secure. And we actually show positive results in that aspect. We first show that assuming pairings, unsymmetric Nike that we build for information theoretically, then we can build a leakage-resonant Nike using both setups, that is both a common reference string and the pre-processing. The techniques that we use are heavily inspired by the so-called geo-system framework. So a natural question that remains is what if we only would only like to use one setup at a time? And we show a prosimplity result that says that assuming IO, unless it functions, one can have a leakage-resonant Nike using either one of those two setups. So in particular, our black box impossibility result only dealt with schemes in the plain model. In terms of that, if we allow setup, we can actually get positive results as well. To sum up, we initiate in this paper a study of leakage-resonant non-interactive key exchange that does not rely on any leak-free randomness of the parties. We first study the symmetric key setting and show that this is closely related to some notion of randomness extractors that we call trussied extractors. And we show how to build those trussied extractors leveraging communication complexity lower bounds in the number of on-forehead model. In the public key setting, we show a quite broad black box impossibility result but also identifies some caveats in this impossibility result that allows us to actually produce construction either in the smaller key settings or using setups that are either a common reference ring or a leak-free preprocessing. So thanks again for tuning in. Thanks for your attention and here's the link for the report.