 Thanks for giving me thanks for the introduction. So I'm David, I'll be talking about watermarking cryptographic functionalities. This is joint work with Sam Kim. When we think about digital watermarking, the first example that usually comes to mind is watermarking for images, where a photographer or a content creator wants to embed their logo or their name within an image in order to both identify the owner of the content as well as prevent unauthorized distribution of that content. There are two main properties that we might desire from such a watermarking scheme. First, after the watermark has been embedded inside an image, the content should still be mostly viewable. However, an adversary that then tries to remove the watermark will necessarily destroy the image in order to remove the watermark, and it should visually alter the appearance of that image. Just as we can define watermarking for images, we can also consider watermarking for pieces of software or pieces of code. Here, the input is a description of a program. And our objective is to embed a watermark within that program. This could be a pick the form of a product ID. It could be a manufacturer's name. It could be the licensee's name. And after the watermark has been embedded inside the program, the program should still be executable. You should still be able to run the program on impulse of your choosing. Moreover, the security requirement basically says that now if an adversary comes along and gets a hold of your watermark program, they should not be able to remove the watermark from the program without essentially destroying the functionality of that program. More abstractly, there are two main algorithms that we use to describe a watermarking algorithm. First, there's a marking algorithm that takes as input a description of a program. And in this work, we will model our programs as Boolean circuits. And the output of the watermarking algorithm is itself a new circuit that should roughly implement the original functionality. There is also an additional algorithm, the verification algorithm, that itself takes in another description of a circuit and decides whether that circuit is considered to be watermarked or not. In this work, we will consider the secretly verifiable version of watermarking, where we assume that both the marking and verification algorithms take as input a watermarking secret key, denoted WSK here. And moreover, in the simplified description here, where I am only considering the case where the watermark consists essentially of a Boolean flag, either a program is marked or it's well unknockmarked. However, all of our notions naturally generalize to the setting where the watermark can be an arbitrary string, such as a name or product ID or something of that form. But for simplicity in this talk, I will try and I will just consider the scenario where the watermark consists of a simple flag. I will refer you to the paper for the details on how we extend it to the more general notion. Now let me define more concretely what the properties we desire are. The first property is that the watermark program should preserve the functionality of the original program. Basically, when we watermark a circuit C, it should produce a new circuit C prime, such that almost all inputs, C prime and C, agree. Now, one might ask, why don't we ask for perfect functionality preserving? Why can't we have a watermarking scheme where the mark program perfectly implements the original program? Unfortunately, if we require strong security properties, which I will define shortly, perfect functionality preserving watermarking is actually not possible assuming the existence of indistinguishability obfuscation. So as a compromise, we settle for something slightly weaker, which is approximate functionality preserving, on all but a negligible fraction of the inputs, the watermark program and the original program implement the same function. The second property is the more interesting one, the security requirement of unremovability, which basically says that if an adversary is given access to a watermark program, that adversary should not be able to remove the watermark from the program without destroying the functionality of the program. Namely, the adversary cannot produce a new circuit C prime that implements the same function and yet is considered to be un-watermarked from the perspective of the watermarking algorithm. I would like to emphasize here that the adversary here has complete flexibility in crafting C prime. We are not restricting the kinds of adversarial strategies the adversary is able to employ. It's given a description of a piece of code and is able to output any arbitrary Boolean circuit that tries to implement the same functionality and yet does not contain the watermark. Moreover, this property should hold even if the adversary is given access to the marking oracle as part of the security game. So basically, the adversary is allowed to request mark programs of its choosing and then try and defeat the watermarking scheme by removing the watermark from a new program. There is a third property that we require called unforgeability. In the interest of time, I will not define this precisely and I'll refer you to the paper if you're interested in that additional property. So the natural next question to ask then is does watermarking schemes exist? Can we watermark arbitrary programs? Unfortunately here, there is a negative result and in fact, for any class of learnable functions, it's very easy to see that watermarking cannot possibly exist because you can simply learn the function and if remove the watermark. As a result, the study of watermarking for functionalities have focused on cryptographic functionalities, a natural class of learnable functions. As such, a focus of this work will also focus on watermarking a natural class of cryptographic primitives. Here, we're going to focus on pseudo random functions. Why pseudo random functions? Well, pseudo random functions are basically the workhorses of symmetric cryptography. Once we can watermark pseudo random functions, we can watermark the decryption functionalities of say a DVD player. We can watermark the authentication functionalities of a car key, for instance. Those PRFs are sort of a natural target for the first step in realizing watermarking for cryptographic functionalities. Just to make sure the model is clear, what I mean when I say we watermark a pseudo random function, what I mean is we have a program and inside the program is a pseudo key for a PRF and all the program does is it implements the PRF evaluation on input X, it evaluates the PRF at X and that's the output of the program. Our objective is to watermark this kind of program. So now I will give you a high level blueprint for how we construct, oh, and the main result in this work is that we show under standard lattice assumptions there exists a watermarkable family of PRFs. Now I will give you start by giving you a blueprint of how our construction proceeds. This roughly follows the schema outlined in a work of Kohen et al who first introduced crypt strong security notions for watermarking crypto functionalities. The blueprint works as follows. Remember our target is the watermark of PRF. So the first thing that we're going to do is we're going to take our pseudo random function and we're going to evaluate it at a bunch of test points and these test points are going to be embedded as part of the master secret key of the watermarking scheme. So based on this output behavior of the pseudo random function we're going to then derive a new point X star, Y star. So we evaluate the PRF at a bunch of points based on the outputs of the PRF at those points we derive a special point X star and Y star. Let me emphasize here that we actually need the X star to depend on the output functionality and the reason for this will become clear later on in the talk but it is actually critical that X star is derived based on the behavior of the pseudo random function. So now when we want to construct a watermark key I mean first give you an abstract schema of the function we want to capture. The mark key is going to be a program that implements this real PRF evaluation at all points. So everywhere except this special point X star. So the mark key is a new program that implements the same function as the pseudo random function that is on watermark everywhere except the single point X star and we're just going to rewire the value of X star to the value Y star. For now let's defer the implementation details. Let's not worry about how we're actually going to implement this kind of functionality. Let's just reason about this abstract properties. Well how do we verify if we had a mark key that implements this type of functionality? Well it's very simple. All we need to do is evaluate at the same set of test points derive the special point X star, Y star and then evaluate this candidate program at X star and check if we get the value Y star or not. In this essence X star and Y star functions as the watermark. We took the original function, the pseudo random function and we have created a new function that only differs it on a single point X star and X star essentially functions as the watermark in this case. So it's very easy to see that this is functionality preserving the mark program differs from the original program on only a single point. Everywhere else is perfect agreement and it's unremovable essentially as long as the adversary has no idea what point we punctured. As long as X star and Y star is hidden from the perspective of the adversary the adversary really essentially has no hope of removing the watermark without a certain corrupting a large swath of the domain of the pseudo random function. So this is sort of the high level intuition for why this kind of schema can be useful in realizing a cryptographic watermarking scheme. Now let's see how we actually implement this functionality. We have this idealized functionality where we want to essentially tweak the value of the PRF at a one point and we want to be able to secretly hide and embed that point within the PR within the watermark program. All of the prior solutions to this work due to Kohen et al as well as Bonnet et al rely on some kind of obfuscation to hide the special point X star and Y star. Effectively all of these works obfuscate the following program. The program has the key PRF key hardwired inside it and it simply checks if I'm asked to evaluate at the special point X star output the special value Y star otherwise output the real value of the PRF. And so all of these techniques essentially rely on being able to secretly reprogram the value of the PRF at a special point. And the reason we require obfuscation is we need to hide the details of the code. We need to secretly embed this watermark within the program such that it is difficult to remove. And the key technical challenge then at least if we follow this blueprint for realizing watermarking is how do we embed a point X star Y star within the watermark key and without relying on general purpose obfuscation. If you take a step back and look at this problem more abstractly or at a higher level it has a very strong obfuscation flavor to it because the adversary here is given a description of a piece of code and inside this piece of code is a secret point that has been rewired. And we're asking that given the access to this code there's really nothing the adversary can do to learn this point X star and Y star and extract it and remove it from the program. And that's where a lot of the challenge has been in realizing cryptographic watermarking. And then again just to remind you in this work we showed that under standard lattice assumptions it is actually possible to instantiate this general blueprint and achieve watermarking for pseudo random functions. Now I will tell you give you a high level overview of how our construction works. The starting point of our construction is going to be a primitive called private punctrable PRFs. So let me begin by reminding you what these various notions are. Recall first that the watermark key in our construction implements the real pseudo random function at all but a single point. If we look at this abstractly or more structurally they should remind us of another cryptographic primitive that has seen a lot of applications in recent years namely the notion of a punctrable PRF. First let me remind you what a punctrable PRF is. A punctrable PRF is the following it has a PRF key and there's a puncturing algorithm that takes this input a point and it outputs a new punctured key and the special property is that this new punctured key can be used to evaluate the pseudo random function everywhere except the single point x star. So it implements the same key as the original function but at x star the value is something else. So how does puncturing seem to relate to watermarking? Well let's recall our general approach for watermarking again. We're going to derive the special point x star from the output behavior of the PRF and then we're going to generate a key that agrees with the PRF everywhere except at this point x star. Well if you just look at the schema of a punctrable PRF these things almost line up perfectly. We can just construct our watermark key as a punctured key. In fact a watermark key is a punctured key in this case. So why does puncturing not already give us a solution for this problem? There are actually many issues with this. Let me just outline two of them to give you a flavor for what's happening. One problem is in typical punctrable PRF constructions the punctured key does not hide the point that is being punctured. The point x star that we puncture is usually part of the description of the secret key. And if this is the way that we're going to embed the watermark it's trivial for the adversary to remove it. It just does something different at the point x star. And the second problem is actually more difficult to aim more tricky. It's because the punctured keys actually do not provide us much flexibility in choosing the values of pain when the punctured key is used to evaluate at the punctured point. And if you look at our watermarking schema the way that we're going to verify whether a program is watermarked or not we're going to evaluate it at the special point x star and check if it has a precise value. Well if the puncturing algorithm does not give us flexibility in choosing this precise value then we actually am not able to implement this general blueprint. Just to remind you what the problems are. First the punctured keys do not hide the punctured point. It turns out that this is actually fairly easy to address instead of using standard punctrable PRFs. We can use a new notion called private punctrable PRFs introduced by Bonet et al. earlier this year. And in a private punctrable PRF it's the same as a punctrable PRF except the punctured key also hides the punctured point x star. So that solves the first problem. The second problem is more difficult. How do we tell whether a result, a value and a range of the PRF actually corresponds to using a punctured key to evaluate at a punctured point? And this is actually kind of fundamental at least given the existing lattice-based constructions of private punctrable PRFs. In both the Bonet et al. construction as well as the Canetti and Chen construction of private punctrable PRFs from Eurocrypta this year the value obtained when using the punctured key to evaluate at the punctured point is actually a deterministic function of the pseudo-random function key. So we actually have very little flexibility and being able to influence or choose the value obtained when a punctured key is used to evaluate at the punctured point. So to get around this problem we actually relax the programmability requirement and introduce a new cryptographic primitive that to enable watermarking. And a new cryptographic primitive we introduce in this work is a notion called a private translucent PRF. The name will become more clear in a little bit. But at a very, very high level a private translucent PRF is the first and foremost a private punctrable PRF. But it has the special property that in the range of the PRF, so in the orange here there is a special hidden subspace. And it has the property that whenever you take a punctured key and evaluate at the punctured point you're going to always land inside this hidden subspace. Moreover, there is a secret testing key associated with this PRF family that allows you to take an element in the range and it will decide for you whether it's land whether it is contained in the subspace or not contained in the subspace. Let me just outline for you the properties that we require from this kind of set system. First, the values that are contained in this subspace should look roughly indistinguishable from a random value in the range of the PRF. Why is this important? Well, if you want to be able to privately puncture a PRF it better be the case that the adversary cannot just evaluate a PRF and test whether that evaluation is at the special point or not. So for privacy to hold it must be the case that if you see something here it's indistinguishable from something outside of the space. And moreover, it prefers a complicated by the fact that when the adversary or the evaluator is computing a PRF it's actually able to sample elements from the subspace by itself. Namely, it can just sample a PRF key for itself, puncture it and then evaluate the punctured key at the punctured point and in doing so they can essentially derive elements from the subset. So set systems that satisfy this property were first introduced as translucent set systems in the work of Kaneti et al in the context of building deniable encryption. In our case, we are essentially embedding a translucent set system within the output space of a pseudo random function hence the name of private translucent PRF. Once they have this cryptographic primitive it is actually fairly straightforward to build watermarking. Let me tell you how. The watermarking secret key will be as before consists of a sequence of test points as well as a testing key for the private translucent PRF system. To mark the PRF key we're going to derive the special point x star as before we're not going to derive a special value y star anymore. All we're going to do is puncture the key at x star. The watermark key is just an implementation of the punctured key for this private translucent set private translucent PRF. To test whether a program now is watermarked or not all we need to do is we derive the test point x star exactly as before and then we evaluate at x star and check whether we're in this special set or not. We have the property that the punctured key evaluated at a punctured point will always land in this special set and so it is easily to check. So in a remainder of this talk I will now tell you how we actually build private translucent PRFs from standard lattice assumptions thus completing the picture of how we build cryptographic watermarking from lattices. Because this is a construction based on lattices let me first start by reminding you what the LWE assumption says. Given a uniformly random matrix A the LWE assumption basically states that a noisy linear combination of the rows of A looks computationally indistinguishable from a uniformly random vector. The second ingredient that we will require in this work is the notion of a homomorphic matrix encoding introduced first in the work of Bonnet et al in the context of constructing attribute based encryption. A homomorphic matrix encoding gives us a way of encoding inputs x where x here is modeled as an L-bit string as a collection of LWE samples. The encoding works as follows for each bit of the input x we associated with it a uniform LWE matrix A1 up through AL. An encoding of a bit x1 is then just an LWE sample with respect to the matrix A1 associated with the first input bit as well as an LWE secret S. G here is a special gadget matrix its importance will not be relevant for the high level overview I'm giving now so feel free to ignore it if it's not familiar. So in this way we're able to encode each bits of the input as different LWE samples according to each of the different LWE matrices but with a common LWE secret S. The homomorphic property of the encodings is the following given an encoding of an input x we can derive from it a new encoding a new LWE encoding of any function f on x so we can derive an encoding of f of x and this new encoding will be with respect to a new LWE matrix A sub f where A sub f can be computed as a public function of just a function f as well as the public matrices A1 up through AL it is not in particular depend on the value that is being encoded. So using homomorphic matrix encodings I will now give you a step-by-step overview of how we build private translucent PRFs. Our construction will proceed through several components first we will build a puncturable PRF then a private puncturable PRF and finally a private translucent PRF. The puncturable PRF construction is due to Brokersky and Vaikunth and Nothin and relies on the observation that given any function f there are essentially two ways of computing the quantity S transpose AF. One way is directly given the LWE secret and the public LWE matrices A1 up to AL is homomorphically compute on these matrices and compute S transpose times AF. The second method of computing this quantity is homomorphically. If I give you the encodings of some x such that f of x equals zero then using the homomorphic properties of these matrix encodings we can derive something that looks like this and as long as f of x equals zero we see that we end up with S transpose AF plus some noise but there's basically two ways of approximately computing this quantity and the two ways will roughly then correspond to a punctured evaluation and a master key evaluation. Let me show you how that works. So to puncture at a point x star the class of functionalities that we're going to consider are going to be the equality function because we want to record it in a puncturable PRF the punctured key enables evaluation everywhere except the single point. So the equality function seems to be the natural fit for this. The equality function is zero everywhere except at a single point. So the real PRF evaluation where the secret key is going to be LWE secret S will correspond to S transpose times AF. The pump and to evaluate at a point x we just homomorphically compute this function and multiply by the LWE secret. The punctured key then consists of the encodings of the bits of x star, the punctured point. Y x star, well this given the encodings of x star this allows the evaluator to compute any function on x star and the functions that are of interest here is going to be the equality function. So in particular this allows the evaluator to compute all quantities of this form and notice that as long as x is not equal to x star this term goes away and we're left with the real PRF evaluation. So this precisely gives us a puncturable PRF. However we want something more than a puncturable PRF we want something at least that at least provides privacy or hides the punctured point and unfortunately the by itself LWE secret S does not provide privacy for a very simple reason. In order to evaluate the PRF using the punctured key to perform these homomorphic matrix operations we actually require knowledge of the punctured point x star. So the work of Bonet et al from Eurocrypt this year show how to avoid this by encrypting the punctured point using a fully homomorphic encryption scheme and they replace the equality function that we compute to evaluate the PRF with homomorphic evaluation of the equality function followed by homomorphic decryption. What this means is that when you take the punctured key to evaluate at the punctured point you're going to get something that's a little bit more complicated. It's going to instead of the basic equality function you get here we're going to get the output of the FHG decryption in evaluation process. But a key insight in the work of Bonet et al is they show a new way of doing of rounding effectively rounding away the FHG noise and again recovering the original value of the PRF. However, this approach still does not provide us flexibility in influencing the value of paint when we use the punctured key to evaluate at the punctured point and to bridge the gap between private puncturing and private translucent PRFs we need to do one more thing. So first we're going to modify the PRF evaluation by first computing S transpose AF as before but we're also going to multiply by a bit decomposition of some fixed matrix D. This will become more apparent why we do this later on. Evaluating using the punctured key proceeds exactly as before we homomorphically operate on the LWE encodings but there are two main differences. First, instead of scaling the input by Q over two as is typical in FHG schemes we're going to scale by its value W and W will be chosen at the time of puncturing. The second difference is because we changed the way we do the master key evaluation we have to multiply by G inverse times D at the end. So if you do some algebra and manipulate this what you'll see is that when we take the punctured key and evaluate at the punctured point we obtain a quantity that looks like this. So I'll ask you to just believe me when I say that there's a different way of doing the FHG rounding that correctness is still maintained when X is not equal to X star. For the purposes of this talk I will just focus on the behavior when we evaluate at the punctured point. The key observation here is that now we have this additional term W times D and notice that W is chosen at the time that the key is being punctured. This allows the puncturing algorithm to actually influence the behavior of the PRF when we evaluate at the punctured point. So it turns out though that if we just have one scalar here we don't have so much flexibility but if we want more flexibility all we have to do is have many copies of this. So instead of having one PRF we have many, many copies of the PRF and we choose many WIs and DIs. And basically what this means is now when I take a punctured key and evaluate at the punctured point we can obtain the original evaluation blinded by this term WI DI. And if we choose the DIs to constitute a basis for the matrix space we can choose the coefficients WI so that the matrix sums the any matrix of our choosing. In particular we're gonna choose W to be an LWE matrix. And basically what this means is when I take a punctured key and evaluate at the punctured point we're gonna land in a sparse subset determined by this LWE matrix. This is extremely important and being able to argue that this precisely implements a translucent set system under the LWE assumption. Moreover the fact that our samples now have this particular structure means that it's actually very easy to test whether we're in the subspace or not. Okay, what's happening? Oh, okay, I'll try to proceed. So the testing key then is going to be a short vector Z such that W times Z is equal to zero. So how do we test whether an element is in the subspace or not but we simply take the inner product with this short vector Z and we check if it is short or not and this allows us to achieve a private translucent PRF from the LWE assumption. So just to cook and there are many technical details that I glossed over here but I hope I gave you a flavor for how we have achieved private translucent PRFs from the LWE assumption and I'll refer you to the paper for the full details of our construction as well as its formal security analysis. Though to conclude the talk at the beginning or prior to this work we basically knew how to build cryptographic watermarking with strong security guarantees from indistinguishability obfuscation and all of these constructions relied on being able to secretly embed a watermark within a piece of code and using obfuscation to hide that watermark. At the same time, prior to this work as a EuroCrip we have our first construction of private punctrable PRFs from the LWE assumption. This seems very closely related to watermarking yet to our knowledge it is not clear that private punctrable PRFs suffice for building watermarking. So in this work we introduce a strength and notion called a private translucent PRF that has the advantage that it can still be built from standard lattice assumptions and yet is also sufficient for cryptographic watermarking. So today we now can achieve cryptographic watermarking from standard assumptions. Let me conclude with two open problems. First is can we build publicly verifiable watermarking without relying on obfuscation? All of the techniques here work in a secret key setting where we assume that the marking and the verification algorithms have a common key. The current best construction of this primitive is due to Kohen et al and still relies on obfuscation. Second, I think there might be other interesting applications that we can explore using this new primitive of private translucent PRFs. They seem to provide us more power than private punctrable PRFs but they have the advantage that we can still instantiate them from standard lattice assumptions. And we build new primitives and base new techniques on these standard assumptions. And with that I'll open the floor to questions. Thank you very much.