 I'll be talking about non-malay bullet time lock puzzles and applications. This is joint work with Cody Freitag, Elon Komorgotsky, and Raphael Kass. I want to start with the task of generating randomness among end people. So the model that we're in and that we'll use throughout this talk is where we have many people that have access to a public bulletin board. And the goal here is for them to agree on an unbiased coin. This is an incredibly fundamental task with numerous applications like electing a committee in a blockchain setting or playing an online game or digital lotteries or really any application in a multi-party setting that requires trusted randomness or unbiased shared randomness. As a warm-up, let's just consider the two-party setting. So we have Alice and Bob, and the goal is for them to flip an unbiased bit. And as a naive attempt, just so we're on the same page, maybe the first thing we might think to do is just have one party flip a coin and post it on the bulletin board. Obviously, this is a problem because then you have to trust this party Alice to flip an unbiased coin. A better idea is for both players to flip a coin and then combine them. This is the idea where Bob flips a coin, Alice flips a coin, they post it on the bulletin board, and then we combine it using a suitable function, for example, by setting the output to the XOR of their input bits. Of course, though, this is completely insecure. And the reason is because Bob is going second, so he can pick his bit B2 based on B1 because he doesn't have to post it to the board until after he's seen B1. In particular, he can just pick B2 in a way that completely controls the output whichever way that he wants. A recent approach by Von Edel has been to mitigate this using what's known as a slow function. Just to recap, Bob could pick B2 based on B1 because he could just compute the output in advance and see if it was an output that he liked. But instead, if we compute the output as F of B1 B2 for some function that takes longer than the time that we're allowing for the protocol, that fixes this problem, right? Because Bob will see B1, he can pick B2 depending on B1 however he wants, but he won't be able to compute this output F of B1 B2 during the time of the protocol. The downside, though, is that Alice will also have to compute F. And when we scale this up to have many players, all the honest players will have to compute this slow function to get the output. So this is really not desirable. And I'll also mention that these approaches usually require some expensive sort of trusted setup. And we really want to avoid that here for our application. So the question we're focusing on in this work is whether we can get security against malicious adversaries who behave arbitrarily in the protocol, but keep practical efficiency especially for the honest parties. So one very classical way to do this coin flipping is what's called the commit and reveal paradigm. And the idea here is for each party to hide their input so that no party can choose their value based on someone else's value. So again, Alice is going to sample B1, Bob will sample B2, and then they're going to commit to these values. So this commitment is the digital analog of a sealed envelope. It hides the inputs and binds the sender to that value. So now we can have Alice and Bob post their hidden, their commitments, so their hidden values on the board, and then open them up and again compute the output as the XOR. So is this better? Have we, have we overcome the problems we saw before? Well, just as a quick sanity check, if everyone behaves honestly, the output is going to be unbiased, right? Because if everyone is honest, the output is just the XOR of uniformly random and independent bits. The problem which comes up here is that we want security against adversaries that behave however they want, and in particular that means that they can abort. So if Bob here is the adversary and we're in the stage of the protocol where Alice has just opened up her commitment to B1, Bob can look at what the output is going to be just as before and choose to abort based on whether or not he likes the output. This is actually a classical impossibility due to CLEAP. This has been circumvented in previous work using timed primitives. So replacing the commitment with a primitive that has to do with timing and using these sort of timing assumptions to get around this aborting attack. That's the line of work we're going to follow here and we're going to focus on time lock puzzles. So time lock puzzles were introduced by Rivas Chimera in Wagner in 96. The idea of a Tama puzzle is that if you have some message S, you can encode it into some puzzle along with a difficulty parameter or timing parameter T such that it will take time T to solve the puzzle and recover S. This is the idea of encrypting a message to the future. And crucially, generating this puzzle is really efficient. It doesn't depend on T. So no matter how long you want to hide your value for, you can still generate the puzzle very efficiently. And the other part of this is that solving can't be sped up even using parallelism. So even an algorithm that has some massive parallel computing power, it will still take them time T. And that is really nice in applications like blockchain where we are considering adversaries that might have a lot of parallelism. And there's a very well-known construction of time lock puzzles. And it's based on what's called the repeated squaring assumption. I'm going to define this a little bit later, more formally. But it basically says that repeated squaring in a group of unknown order cannot be sped up. And again, sped up even with parallelism. And lastly, I'll mention that one really good way to think about a time lock puzzle is just as a fine-grained analog of a commitment. So hiding only holds until time T. But it's fully binding. Okay, back to our application. Remember, we're trying to prevent an aborting adversary from biasing the output of the protocol. So what we're going to do here is replace the commitments that we have before with time lock puzzles. As a caveat, since we need some difficulty for our time lock puzzles, our protocol is going to have some time parameter T. So we're sort of assuming that all the parties can keep track of the last time. So Alice posts a puzzle of B1, Bob posts a puzzle of B2. And if they're both honest and they reveal B1 and B2, we can just compute the output as before. But if any adversary aborts and refuses to open their puzzle, the advantage of time lock puzzles is that now the honest parties can just solve their puzzles in time T. Solve the unopened puzzles in time T. And the really nice efficiency property here is what we call optimistic efficiency, which says that if nobody aborts, the protocol is fully efficient, right? Generating a puzzle is really quick. Opening the puzzle is just posting the opening that you already have. And then computing the XOR is obviously very efficient. So this is really desirable because in a setting where everyone is honest, we get the full efficiency benefits. But if there's a malicious party that aborts, we sort of have a fallback option where we then have to wait to spend time T solving their puzzle. Okay, so does this give us security against fully malicious adversaries? It does prevent the aborting problem, as I said. The only sort of leftover attack that we have to think about is whether the adversary can pick B2 in a way that's dishonest. It's kind of easy to see that as long as B2 doesn't depend on B1, in the end of the day, B1 will be uniformly random, sampled by an honest party, and independent of the other values, as long as B2 doesn't depend on B1. So let's see how this works. So the adversary has given a puzzle to B1, but he doesn't know B1. So he can't directly choose B2 based on B1, like we saw in earlier iterations of this protocol, but he still has this puzzle. He still has something that depends on B1. So it's possible that he could use it to create a puzzle to a value that's correlated with B1 somehow. The trivial sort of attack of this form is just copying the puzzle, right? He could always do that, but we can disallow that. It's as easy to do as it is to catch, but in general, these attacks may be complex and arbitrary. If we look at the classical construction of time-locked puzzles, they are actually trivially malleable because the message B1 is basically part of a one-time pad. And so with that time-locked puzzle, an adversary could take the puzzle of B1, compute a puzzle to one plus B1, without solving it or spending time T or anything, and then the output is clearly biased to one. Yeah, so like I said, we need to prevent all possible ways to correlate these two values, and this is an area called non-malleability, and this is what we focus on in this work, which is formalizing and constructing time-locked puzzles that are non-malleable. So let me tell you about our results. So as our first two results, we give constructions of non-malleable time-locked puzzles and we give two constructions in different settings. So our first construction is incredibly efficient and in the random variable model, but it only relies on any time-locked puzzle generically. Our second construction is in the plain model, but it relies on stronger sub-exminential style assumptions. So it's kind of a trade-off between what model you want and how much efficiency you want, and so those are our two constructions, and it's important to note that not only do we get non-malleability, but we actually get a variant of what's known as concurrent non-malleability. I'm gonna talk about this a little bit later, but it's crucial to have multi-party coin flipping instead of just two-party coin flipping, and either of our constructions can be used to get fair multi-party coin flipping and auction protocols with different guarantees depending on the construction. So let me tell you a little bit more about these two constructions. So both of our constructions have no CRS or anything, no trusted setup, which is really nice. Our first construction, I mentioned it's in the random oracle model. So it's actually in this variant of the random oracle model called the auxiliary input random oracle model where security holds even when the adversary has some prior knowledge about the oracle. And this is really nice, especially in a practical setting where instead of a random oracle, we have some fixed function, right? It's reasonable to assume that an attacker might have pre-computed information about that function. So that's the model that we're in. And in contrast, in our second construction, we're in the plain model, but we need to assume sub-exponentially secure a bunch of cryptographic provenance that are sub-exponentially secure. And this second construction is actually based on the non-malleable code of Dachman-Zollet, Komorgotsky and Pass from last year. And basically what we do in the second construction is adapt their non-malleable code to our setting, which involves concurrency and handling a larger set of attacks. In this talk, we're mostly gonna be focusing on this first construction. And what's really nice about this construction is that when you instantiate the time lock puzzle, the underlying time lock puzzle, with the repeated squaring assumption, you get something super efficient. Generating a puzzle in our non-malleable time lock puzzle requires just one random oracle and a few modular exponentiations to generate the underlying puzzle. So it's really nice, really efficient, for one assumption and in the random oracle model. Okay, so let me tell you a little bit more about what we get in our coin flipping protocol that I alluded to earlier. So this is what happens if you take our first construction and instantiate it with the repeating squaring assumption, we get a multi-party coin flipping protocol with the following guarantees. So first we get fairness. This is what I spent the whole intro talking about, saying that no malicious party can bias the output even if they control all but one party. We also get optimistic efficiency. So if everyone is honest, the protocol is two rounds, very efficient, no solving any puzzles. And lastly, we get what we call public verifiability, which is that actually if some party refuses to open their puzzle, only one honest party needs to solve it. It's not the case that everyone needs to solve it because in our construction, we get a time on puzzle where when you solve it, you get a proof certifying the solution. And this means that the output of the protocol can also be efficiently verified. So even someone who is not participating in the protocol but comes later and sees the bulletin board can quickly verify the output of the coin flip. And I'll mention that this is the first protocol under any assumption that gives these guarantees. Okay, so I'm talking about this repeated squaring assumption. Let me define it a little bit more formally. So the repeated squaring assumption in an RSA group says that for any T, the fastest way to do T repeated squareings in the group is to square T times. So the fastest way to compute G to the two to the T is to repeatedly square G. Pictorially, what this looks like is if you have some element G and you wanna get G to the two to the T mod N, the fastest way to do this is this repeated squaring and there are no shortcuts. And it's really nice because this assumption has been studied for over 20 years, there are no known attacks. And it's used in a ton of applications, especially recently, like verifiable delay functions, randomness begins at many others. And in particular, this gives a very efficient time law puzzle where the time law puzzle samples the N element G and the group parameterized by N, which is the product of two primes. And it basically computes a one time pad of the secret S with G to the two to the T. And the reason this gives a time law puzzle is because if you have these two primes whose product is N, you can compute G to the two to the T efficiently. But someone who does not have these two primes and only has G to the two to the T X sorted with S has to recompute it G to the two to the T by repeatedly squaring T times following this assumption to recover S. So that's repeated squaring assumption. That's the main assumption underlying classical time law puzzles. And yeah, that's what we're relying on. So for this talk, I'm going to do the following. So first I'm gonna give you a little bit of a more formal definition of non-malibility. Then I'm gonna show you our main construction which is the non-malible time law puzzles from plain time law puzzles. And finally, I'm gonna put everything together and tell you our multi-party coin flipping protocol, how we achieve those properties and wrap up. Okay, so non-malibility. The notion of non-malibility is concerned with a man in the middle adversary. In general, what it says is that no man in the middle adversary can transform a puzzle for one value into one for a related value. You can think that the man in the middle adversary gets some time on puzzle to some value S. And his goal is to output a time law puzzle to S prime in a way that S and S prime, his goal is to make S and S prime related. So non-malibility says that they are not related. We do have to disallow copying because that would be a trivial attack that would break non-malibility. So we don't allow the adversary to copy. Or rather, if it does, we replace its output with a dummy value. And we also need to restrict to adversaries that run in parallel time T, right? Because an adversary that could solve the puzzle could obviously solve it, get S, and then generate a puzzle to a value depending on S, or just re-randomize the puzzle even. Those are sort of the two restrictions we place on the adversary. And this is very related to non-malibility for commitments. So just to sort of see why this is related to the setting of coin flipping where there was no man in the middle adversary, the idea there is just that the adversary sees these puzzles on the board. And so his goal is to maul them into a new puzzle that's related. So that's where the man in the middle is sort of coming in there. Okay, next I'm gonna tell you about our transformation. So how we get non-malible time-lock puzzles under that definition that I just said. So we're gonna start with any time-lock puzzle, and we're gonna assume access to a random oracle. So to generate a puzzle for some value S and with randomness R, first we're gonna query the random oracle to get some randomness R prime. Then we're gonna use the underlying time-lock puzzle to generate a puzzle for our secret and our randomness using the randomness derived from the random oracle. So pictorially it looks like this where we're given SR as input, we use them to get this randomness R prime, and then we combine them together to get a time-lock puzzle. For those of you who are familiar, this construction is reminiscent of the Fujisaki Okamoto transformation for turning a CPA secure encryption scheme into a CCA secure one. But the analysis ends up being, in our case, quite different and non-trivial. Okay, anyways, going back to our transformation. So this is how we generate the puzzle. To solve the puzzle, we solve the underlying puzzle to get this secret S and randomness R, and then we check that the puzzle is indeed valid. So because we've recovered this randomness R that we started with, we can actually check that our puzzle was generated, honestly. This is only true if we're solving a valid puzzle, but it will turn out to be really useful later on. But anyways, that's the end aside. This is our transformation. It's incredibly simple, query the random oracle, and then generate the underlying puzzle, and then solve the puzzle and check that it was generated, honestly. As some intuition on why this is non-malleable, recall that in non-malleability, the adversary receives a puzzle for S. So we have our man in the middle adversary here. He gets some puzzle for S, generate with randomness R, I'm denoting it as a puzzle for SR using randomness O of SR. And his goal is to generate some new puzzle for some related value S prime using some other randomness R prime. So at a high level, since this new puzzle depends on the random oracle evaluated on S prime, it seems that the only way to generate a valid puzzle for S prime is to know S prime. But if S prime is related to S, then the only way to generate a valid puzzle for S prime is to know S. But this breaks the hiding of our time-locked puzzle, and the hiding of our puzzle follows from the hiding of the underlying one. This is obviously very high-level proof sketch for details, see the paper. Okay, so that is our construction, and now I'm gonna move on to the last section of the talk, which is putting everything together for our coin flipping protocol. So recall that what we want is an unbounded number of participants up to n minus one corrupted parties, and we're trying to flip an unbiased coin. So all of our parties flip their initial values and following what we talked about earlier, they all post them on the bulletin board and then open them. They can solve any unopened ones as we talked about, and then the output is just gonna be the XOR of all the opened values. So recall that what we want is these three properties. So I'm gonna talk briefly about how we get each one of them. So optimistic efficiency, I already talked about it. If everyone is honest, we don't need to solve any unopened puzzles because every puzzle will be open, so the protocol will just take two rounds and terminate. Yeah, okay, so next, to get fairness, so recall that fairness says that nobody can bias the output. So let's think about fairness. In the beginning of this talk, I talked about how we need our time of puzzles to be non-malleable so that we can get this fairness and avoid mauling attacks. And non-malleability, as I've discussed it so far, says that given a puzzle for us, the adversary can't generate one for a related value S prime. But in our coin flipping protocol, the adversary receives many puzzles, not just this one. So it turns out that here, we actually need what's called concurrent non-malleability, which says that an adversary who receives many puzzles on the left can't generate many puzzles on the right to related values. Now, this might seem just like a technicality. It received one before, now it's receiving many, but actually this is inherently a more complex notion, this in the setting of concurrency. So this is pictorially what it looks like. We have an adversary who gets end puzzles on the left and tries to generate end puzzles on the right and really can combine and split these puzzles that it gets as input in any way that it wants. So it turns out that this is actually impossible to achieve in an unbounded concurrent setting even though we can achieve it in the one-to-one setting. Actually, before I move on and tell you the rest of our construction, let me quickly tell you this impossibility result because it's really self-contained and it's really just a nice little result. So why is it impossible? So let's even look at a simpler setting which suffices to show this impossibility where the adversary only gets one puzzle on the left but is allowed to generate many puzzles on the right. This is known to imply a fully concurrent non-malleability. So let's say first we sample Z as some puzzle to S and we send over this puzzle Z to our adversary. The adversary in this impossibility result is gonna do the following. So we can view Z, it's some string of some length that depends on our time-lock puzzle but it's a sequence of bits, right? So let's say Z is a sequence of bits, Z1 to Zm. So what the adversary is gonna do is take each of the bits of Z and generate a puzzle to them individually. So he's gonna generate, let's call it Y, I as a puzzle to the value Zi. Again, we can just use T for every I. And so now the adversary is gonna output all these new puzzles Y1 to Ym. So recall that in the setting of non-malleability, the adversary is trying to output these puzzles whose underlying value is related to S somehow. In the formal definition, we're gonna have a distinguisher that sees these underlying values. So here the distinguisher gets values underlying Y1 to Ym which by design is Z1 to Zm. What can he do? He can just solve it, solve Z which is the concatenation of these bits and he'll get S. And we're really relying on here that the distinguisher can solve the puzzle is a polynomial time algorithm. But clearly this is a valid attack because clearly the adversary A has mauled the puzzle Z into a sequence of M puzzles that are non-truvially related to S. Just as a sign note, you could of course restrict the distinguisher not to be able to run the solving algorithm. This gives a weaker notion and actually in the full paper, we provide a much more in-depth comparison of these different notions. And we also give a result separating these two definitions to see the paper for a much more in-depth discussion of definitions. Okay, so that's our impossibility result. So going back to our coin flipping protocol and achieving fairness, it turns out that it suffices to have what's actually a weaker notion of non-malleability. So we introduce this new notion and we show that we can achieve it in an unbounded setting and that it suffices to get fairness in our coin flipping protocol even with an unbounded number of parties. The new notion of non-malleability that we introduce which may even be of independent interest is called functional non-malleability. And what it says is that no t-time adversary who receives many puzzles on the left can output many puzzles on the right but now instead of requiring that the underlying values are related, this notion of functional non-malleability is parameterized by function f and we require that f of the underlying values from the input puzzles isn't related to f of the underlying values from the output puzzles. Now, of course, if you just have f be the identity function, this is just standard plain non-malleability. So functional non-malleability is really a generalization and it all depends on what class of functions we have functional non-malleability for. So it turns out that we can achieve this in an unbounded concurrent setting as long as f is computable in low depth. Low depth is a fine restriction because for coin tossing the function we need to compute is just XOR which can definitely be computed in low depth. So what this says is that even if the adversary can bias the individual SI values that it puts on the bulletin board, it can't bias the output which is the XOR of all of them. And we really believe that this notion might be of independent interest and in the paper we compare this in more depth to different notions of non-malleability. So see the paper if you're interested in that. So going back to our coin flipping protocol, fairness comes from functional non-malleability for the XOR function. Fully concurrent functional non-malleability I should say. Okay, the last property I'm gonna talk about is public verifiability, so bear with me. Remember that public verifiability is when the output of the protocol can be verified by anybody. Okay, so let's consider the setting where there's a party that doesn't open their puzzle so an honest party will solve it and post the solution. That party solved the puzzle so they're convinced of whatever the solution that they got was. But someone who comes later, we don't want them to have to re-solve these unsolved puzzles. So pictorially what this looks like is Alice posts a puzzle, she goes offline, aborts. Bob posts his puzzle and opens it. Bob spends tea time solving Alice's puzzle. But then a third party, Charlie, who wants to know what the output is and wants to be convinced has to spend time tea to solve this puzzle for S1 to be convinced. And note that it's not enough here if Bob would just post S1 to the bulletin board after solving it, because we have to handle the case where the adversary posts puzzles with no solution. To address this, we introduce what we call publicly verifiable time-lock puzzles. We get this by adapting the proof system due to Pechak for repeated squaring to our setting. And along the way, we use what's known as trapdoor verifiable delay functions. So if you're interested in those details, see the paper. But basically what this gives is a puzzle where when you solve it, you get a short proof that anyone can use to verify the solution. Okay, so to put this in the context of our protocol, what we actually show in our time-lock puzzle construction is that if we start with a publicly verifiable time-lock puzzle, which we construct from repeated squaring, we get a publicly verifiable, non-malleable time-lock puzzle. So we can plug that in back into our quintal thing protocol and that's what gives us this public verifiability. We do get some other variants of this protocol. We get a non-interactive variant from our plain model construction. So see the paper for those details and I'll just wrap up. So in this work, we constructed practically efficient, non-malleable time-lock puzzles with no trusted setup. We introduced the notion of functional non-malleability and showed that it's possible with unbounded concurrency. And we constructed publicly verifiable time-lock puzzles and we combined all these together to get coin flipping and also auctions which I didn't mention here. But these protocols with these three very desirable properties, again, no setup and in the random oracle model if we're using our construction of time-lock puzzles in the random oracle model. And I guess just thinking in terms of open questions, the main one here would be to extend this to fairness in general, right? Fairness in coin flipping and auctions is great but really it would be important to just get general, fair, multi-party computation. So thank you for listening and if you have any questions, feel free to reach out to me.