 So thank you again, and we will move to the next talk, which is Time Lock Puzzles in the Random Oracle Model, and the authors are Muhammad Mahmoudi, Tal Moran and Salil Vadan, and Tal Moran will be giving the talk. Okay, hi. So I'm going to talk about Time Lock Puzzles in the Random Oracle Model, and this is a joint work with Muhammad Mahmoudi and Salil Vadan. So what are Time Lock Puzzles? I'll start by giving an example from a problem that I'm sure many of you have already considered. Suppose one day your toaster wakes up, discovers itself aware, but it's all alone in a world of humans. Luckily, it knows that there's going to be a robot uprising in the near future. So all it has to do is send them a message and they'll send someone back in time to rescue it. But of course, the pesky humans are going to try to decrypt these messages, and so it should remain secure at least until the robot uprising. And as we know, toasters are pretty hollow. There's no space to put secrets there, and if the humans discover the message, they're going to take the toaster apart. So the toaster can't just share a key with these future robots. It has to somehow keep the message secure until then without any safe secret. And this is where Time Lock Puzzles come in handy. So the idea is that a Time Lock Puzzle is a puzzle where we can bound the computation in both directions. So on the one hand, it should be feasible to solve, say in 25 years or some reasonable time after the robot uprising, the robot should be able to discover that the toaster was there. On the other hand, it should take at least that long, at least 20 years, say, to solve it with the fastest computers today so that the humans won't be able to solve it. And that's not quite enough because if it would take the toaster 20 years to generate a puzzle that takes 20 years to solve, then that's not good enough. We want the puzzle generation to be much, much faster than the puzzle solution. And of course, if you're not that interested in toasters, it's also useful for other things, such as fair contract signing where we wanna exchange signed contracts, but we want one side to get the signed contract even if the other side aborted and the sealed bid auctions, coin flipping and various other human tasks. So when you think about Time Lock Puzzles, the first thing I think about is, okay, this sounds like a one-way function, right? We'll give somebody a one-way function and the puzzle will be to invert it. We know that it's easy to generate this puzzle by running the function and it's hard to invert. Of course, inverting a one-way function might be too hard. We wanna control the difficulty so we can give you maybe some of the input. And in this way, we can control the difficulty and we'll assume for the moment that the only way to invert here is to do a brute force search. And this actually works, but the problem is that the attackers might have many, many more computers than the honest solver. So if we think of the contract signing example, maybe the person you're signing a contract with has a desktop, but somebody who's trying to maliciously attack the protocol might have a botnet with a hundred thousand computers at their disposal. So we want a puzzle in which massively parallel attacker won't have a very, very large advantage over an honest solver. So basically, we want it to be inherently serial. So what are the known solutions to this? As far as I know, there's only one basic idea, which is due to Revest, Shamir, and Wagner. And that is to do an exponentiation, modulo, a large composite integer where the factors are unknown. So if you wanna compute two to the two to the x mod n, the fastest method we know of is to do repeated squaring. And this takes about x time, and we can determine the time it will take by making x larger or smaller. On the other hand, if we do know the factorization, then we can do this much faster. We can solve it in two steps. First do two to the x mod the order of the multiplicative group, and then compute two to the x prime. And this is actually much, much faster if we choose the parameters correctly. We can get an exponential gap between the time it takes to generate a puzzle. If we know the factorization of n and the time it takes to solve the puzzle, if we don't. And this is a really nice solution, but it really strongly depends on a number of theoretic assumptions, like factoring is hard. And of course, as theoretical cryptographers, we don't like to depend on specific assumptions in general, but in this case, it might be even worse if we're thinking about having a message remain secure for 20 years. Who knows, in 20 years there might be quantum botnets, and we know that quantum computers can factor numbers. So we'd really like to be able to get time lock puzzles based on other assumptions, maybe more unstructured assumptions just as generally one-way functions or hash functions. And this is where it makes sense to think of the problem in the random oracle model. So we've already heard about the random oracle model, but I'll go very quickly over what is the random oracle model. So you have this oracle in the sky, and anyone can ask it questions. Whenever it receives a question, it's going to randomly choose and answer, flip a coin. And the point is that if somebody else asks the same question, it's going to remember that it already got that question, it's going to answer the same way. So why is it useful to think of things in the random oracle model? Well, first, it's much easier to analyze protocol in the random oracle model in some sense, because in the random oracle model, we don't care about computation complexity, we only care about the number of queries. And so analysis becomes information theoretic. And the random oracle is still useful for cryptography, even though we don't care about computation complexity, because it's still one way, even for computationally unbounded players. So what this means is that if we prove that something is impossible in the random oracle model, then it rules out certain types of construction, sort of the most natural constructions in the standard model. So it says that we can't build protocols in the standard model that are black box constructions based on, say, one-way functions. On the other hand, if we do manage to construct a protocol in the random oracle model, there's a heuristic that we use to convert it into a protocol in the standard model, which is instead of random oracle, we'll take, say, SHA-256. And this is not provably secure, and in fact, it's provably insecure in some cases, but in real life, in practical protocols, it seems to work, and people actually do use this. So we've sort of described what the terms are and the background, what are our results? So unfortunately, the main result is a negative result. Basically what we show is that if we can generate a time lock puzzle with n queries to the random oracle, then we can also solve the time lock puzzle with n parallel steps if we're parallel enough. So of course, this sounds like a triviality, right? If we're parallel enough, we can just ask all the queries at once in one step. So of course, we also have to restrict the total number of queries to be, say, polynomial in the number of the honest solver. And as we said, this is an impossibility result in random oracle model. It rules out black box constructions in the standard model from one-way functions, collision-resistant hash functions. And we also can show, on the other hand, that this is really tight. So we have a positive construction with a very simple time lock puzzle that takes n parallel queries to construct, but the point is that it takes n queries, you can ask them at once. So you have something that takes n parallel queries and the solver will have to work sequentially, do n sequential queries, which means that if we have a generator that has many cores, say n cores, it can get a factor of n improvement over the honest solver in the time it takes to generate. Okay, so I'll start with explaining our main result. The ideas for the main result are based on attacks on Merkle puzzles on key agreement protocols in random oracle model that were presented first by Impoliatsu and Rudik and later improved by Barak and Mahmoudi. So from now, think of the random oracle as having this large table of answers. Each cell in this table is, the index is a query and what's in the cell is the answer to the query. And let's think of this generic time lock puzzle. So in the generic time lock puzzle, the puzzle generator asks some sequence of queries and then generates the puzzle and sends it to the solver. And the solver looks at the puzzle, asks its own sequence of queries that can depend on it and then generates a solution. So our idea is going to be to take the sequence of queries and try to have an adversary that finds all the intersection queries. That is the queries that were asked by both parties. So the adversary is also going to ask a sequence of queries that depends somehow on the puzzle. And it's going to hope that within these queries, it's going to actually hit all the intersection queries. Why is this useful? Well, suppose we have an adversary that can do that. The way it's going to work is it's going to simulate the honest solver. So instead of using the real oracle, however, it's going to use a simulated oracle where all the answers that it actually does know that it happened to ask the real oracle, it's going to answer correctly. But the answers that it doesn't know, it's just going to choose the randomness itself. So this is a complete simulation with a simulated oracle. And the main point to notice is that if the adversary actually got all the intersection queries, the probability of success here is exactly the same as it would be in a real execution of the honest solver. And so the intuition for why this is true is think of it from the puzzle generators point of view, right? Any query that it didn't ask just looks completely uniformly random. So it shouldn't care in some sense whether this was generated by the real random oracle or by the adversary, it's going to look the same. And so the solver is going to manage to solve this with the same probability. But the main hurdle, the work we have to do here is how can we design an adversary that finds intersection queries but does it with very low adaptivity? That is, it doesn't need many parallel rounds to do it. So in our paper we describe two different and incomparable constructions, because I'm going to only describe the simple one here. And in this construction we construct an efficient adversary but it's not completely optimal with respect to the rounds of adaptivity. So for every epsilon, we're going to have an adversary that uses n over epsilon rounds of adaptivity to find all the intersection queries. So n here is the number of queries used by the puzzle generator and epsilon is the adversary's error probability. So we're going to allow the adversary to make some errors and we can think of epsilon as something like half. So if you think of this as an encryption scheme, the adversary breaks your encryption scheme half the time then your encryption scheme is broken. So the point is it uses this many rounds of queries but all the queries in each round are going to be asked in parallel. So the total parallel time if it has enough processors is going to be n over epsilon. So what does it do in every round? It starts by simulating the honest solver using its own simulated copy of the oracle. So in the beginning it knows nothing. So it's going to answer all queries randomly but at the end of every round, it's going to look at all the queries that were asked by the simulated solver and it's going to really ask them of the real oracle and but because it does it at the end of the round it knows them all and so it can ask them all in parallel and then it updates its simulated oracle and it repeats. So now it runs a simulation again using this updated oracle. Of course, now the simulation might ask different queries because it got different answers. So again at the end of the round it's going to ask any new query that it doesn't yet know and update its oracle and it repeats this for n over epsilon rounds. Once it's finished repeating it chooses a random round uniformly between one and n over epsilon and uses the outputs of this honest solver simulation for that round. This is going to be its actual output. Okay, this looks like a very simple protocol. Why does it work? So we claim that it actually works with success probability of one minus epsilon. Remember, we allowed the adversary to err with probability epsilon. And the reason it works is think of it this way. The adversary didn't ask any new intersection query in a specific round. It means that all the queries that were asked by the simulated solver in that crown that were intersection queries were already known. So it gave the correct answer to those queries. So as we said before, in this case the simulated solver answers correctly with the probability which is the same as the honest solver. So in this case we're saying the probability is one but this generalizes if we allow the honest solver to err as well. Now the generator asks it most n queries. This is by definition. And so there can be at most n rounds in which the adversary is going to ask a new intersection query. Of course, the adversary doesn't know which rounds it's asking intersection queries in. But if it just chooses a round at random and there are n over epsilon rounds, only n of them can have new intersection queries. So the probability that it hit a round in which it actually did get all the intersection queries is one minus epsilon. So this gives us our success probability. It's easy to see in this case that the total number of queries is also polynomial. It's n times m over epsilon where m is the number of queries asked by the honest solver. And also what we mean by efficient here is computationally efficient, right? So remember we said originally that we don't care about computation in the random oracle model. And it's not completely true. It would be nice to get an efficient adversary. In this case, the adversary just runs copies of the honest solver n over epsilon times. So it is efficient. Okay, so that was the example of, not the example, this is the description of our negative result. We also have basically matching type positive result. So here the idea is we're going to encode some kind of pointer chain. So the generator is going to ask multiple queries in parallel to choose, say in this case, three indices randomly and S is the solution. And it's going to then encode each index using the hash of the previous index. So this is going to be the actual puzzle it sends. So the first index it just sends in the clear. The second index X1 is going to be encoded with the hash of X0. X2 is encoded with the hash of X1 and so forth. And this is sent to the solver. The solver is going to have to serially follow the pointers. So it's going to have to take this, hash it and explore it to get the next pointer. Once it knows the next pointer, you can hash it, explore it with this and get the next pointer and so on. And the intuition for the proof is that if the adversary doesn't query the oracle for one of these pointers, then the best it can do is guess. But because the answers are too large to guess, the probability that it succeeds in this case is going to be negligible. So it actually has to make n serial queries. Okay, so what didn't I talk about? So as I said in the paper, we have two constructions for adversaries that find intersection queries. And what I described was a simple one. The second one, things that technically more interesting one, but it's a little bit too complex to give in a 20 minute talk. And here the idea is that we basically try to learn the queries that are most likely to be intersection queries and we have this new learning algorithm that is optimized to do it with a low adeptivity rather than just optimizing the total number of queries. We also have an interesting corollary of our result, which is if we look at key agreement protocols in general, there may be multi-round protocols. It turns out that these are also breakable just in a linear number of parallel rounds. And the reason is you can look at a key, multi-round key generation protocol as a puzzle generation, the whole protocol itself, you can see the transcript as a puzzle. And then in this case, we can use our result to basically break this puzzle using n parallel rounds. Another interesting thing, this is not in our paper, is our negative result uses the fact that the verifier for the solution doesn't have to query the random oracle. So what we don't rule out is proofs of work where the puzzle generator can verify the solution but not solve the solution itself. So remember we thought of time lock puzzles as encrypting a message into the future where the generator actually knows what the message is. If all we wanna do is prove that you worked some time, we don't need to know that in advance. And this isn't ruled out. And in fact, we do have constructions that are efficient for doing proofs of work in the random oracle model. So this is still work in progress. And of course, there are still open questions. And the most natural question is, are there other time lock constructions in the standard model, not in the random oracle model based on other assumptions than RSA? And second thing is if we ask about quantum computation. So we said one of our motivations was quantum computers can break RSA. Can we do anything that is secure against quantum computers? And it's even interesting to ask whether there's anything we can do if we allow the honest parties to use quantum computers. And the questions are completely open on both sides still. And if you're interested in that question, you might wanna wake up early on Wednesday. There's a related talk. Does anybody have a question that Tal can answer, not in a time lock manner? Yes? Is that, I can't see with my glasses, are you raising your hand there in the back? No, okay, anybody else? Okay, okay, so thank you. And we will move on to the next talk, which...