 Instead of the usual overview and the motivational part, in the beginning of the talk, I'll parse its title. So the first part of the title, Deterministic Public Encryption, appears to be flying in the face of 30 years of modern cryptography, whose early insight was that randomization is essential for security of encryption. But in recent years, there was efforts to understand deterministic public encryption to give its meaningful security definition and understand when it makes sense and it actually provides some security guarantees. So in the spirit of semantic security, to define deterministic encryption, we'll give an adversary to choose, instead of the two messages, the adversary will choose two sources of messages because it's easy to see that if the messages are fully controlled by the adversary, there's not much we can do if we insist on the encryption scheme being deterministic. So the adversary gets to choose two sources and will want some unpredictability and the kind of entropy that we like is mean entropy that bounds the maximal probability of an output. We'll say that a deterministic encryption scheme is secure if the distributions induced on these two sources by encrypting them are computationally indistinguishable. And this definition was given by Bellar and Tothers in the crypto 2007. The important note is that these two sources must be independent of the public key. For example, the public key can be sampled after the sources are identified by the adversary. So there are some applications of a secure deterministic encryption. It can be used for a search, for a data application. There are deterministic key encapsulation mechanisms. In order for the deterministic encryption to be secure, it relies on certain computational assumptions that we are mostly comfortable with. But it also makes this very strong assumption of the mean entropy of the plain text. And there are some circumstances where this assumption can be justified when we are talking about digital photographs, or long documents, or a full database, or entire disk. But still, there is an inherent tension between security and efficiency. For security's sake, we'd like our plain text to be as long as possible to harvest all of its entropy. For efficiency's sake, we'd like to work on smaller plain text and smaller cyber text. There is a way of resolving this tension, at least to some extent. And it's called incrementality. If our scheme is incremental, then updating, changing a single bit in the plain text, will only cause changes in the relatively few bits in the cyber text. And we'll call this degree of delta. And it's going to be uniform bound of the number of bits that change in the cyber text on a single bit in the input changes. And we can talk about different kinds of update operations that can be applied to the plain text. If someone has access to the plain text or to the private key, we can talk about setting a bit, setting a bit either to 0, 1. Or if our scheme is homomorphic, we can allow flipping a bit or some linear operation on the bit. So I think by now the title of the talk that is incremental deterministic public encryption makes sense to you. This is what we will be trying to construct for the rest of the talk. In short, our results are the following. We'll give a low bound that bounds the incrementality bound in terms of the size of the plain text, the assumption of the mean entropy of the plain text, and log of the length of the cyber text. And this log, it's kind of interesting if the cyber text is allowed to be exponentially long, then there exist schemes with almost constant locality. Second, we describe two solutions, one generic that relies on converts arbitrary public key deterministic encryption scheme into incremental public key deterministic encryption. And a second solution, which I'll spend the bulk of the talk on, is based on the DDH assumption. And it matches the low bound up to polylog factors. So what if we are given a deterministic public encryption scheme that does not have incrementality? We want to encrypt possibly longer plain text with incrementality property. A very kind of naive solution that is used all over the place is to chop the plain text into blocks and encrypt these blocks individually. Unfortunately, if the original plain text, the long plain text, had some substantial mean entropy, we have no guarantees about mean entropy of individual blocks. A useful and interesting lemma that will save the day here is called sample and extract. It was first proposed by Neeson Zuckerman in 1996, refined or strengthened by Salil Vadan in 2004. And what the state is that if the source has mean entropy, then projection of the source to a randomly selected subset of bits will preserve its mean entropy rate. That is, if, for example, the source was 10,000-bit long and had 5,000 bits of mean entropy, if we take a random sample of 1,000 bits with very high probability, this random subset of 1,000 bits will have at least 100 bits of mean entropy. So with this lemma in mind, it's easy to see that if, instead, we divide the input into randomly chosen subsets and encrypt put the bits in the subset together and encrypt them using the scheme whose existence we assume, the resultant scheme is going to be a secure deterministic public encryption. The only catch is that it will require a somewhat stronger definition that should hold in respect to multiple messages that I didn't define. And we only know how to construct deterministic public encryption scheme that satisfies the stronger definition in the random worker model. And I didn't explain why the new scheme we will have, why the scheme that we construct will happen in mentality, but I think it's easy to see. If a single bit is updated, if a wide bit is updated in the plain text, then we only have to recompute the wide cipher text. OK. So in order to construct a deterministic public encryption scheme in the standard model, we'll have to do something different. We can't rely on this generic construction because we don't know how to meet a stronger definition in the standard model. So in the rest of the talk, we'll be constructing a deterministic public encryption scheme with incrementality based on the DDH assumption. And we'll be heavily leaning, our stepping stone is going to be the concept of lossy trapdoor functions that we covered extensively in the morning session yesterday. And I'll recap the definition of lossy trapdoor functions here quickly. So they were introduced by Packard Waters in 2008. And the common two modes, one is injective, where the function is invertible, given a trapdoor. And the lossy mode, where the function actually compresses, maps its domain to a shorter, smaller range. And the security definition says that descriptions of these two functions, their public keys, are ought to be computationally indistinguishable. So we consider a new primitive that we call smooth trapdoor functions that look roughly the same. Again, it has two modes, one injective, where one of the functions is invertible. Another smooth, where we say that the function, related on a source of mean entropy K, has to induce a distribution which is statistically close to the uniform distribution of the ciphertext. So this is kind of our new definition, which strictly speaking is incomparable with lossy trapdoor functions, but in fact, it's slightly stronger. I'll show you in a second why. So I claim that smooth trapdoor functions are sufficient for our definition of deterministic public encryption. Why is that? In the injective mode, when we encrypt a message, the adversary gets to specify two sources of messages, each of which has mean entropy K. We switch the injective mode to the smooth mode without adversaries noticing, because the adversary is computationally bounded. And now these two distributions are both statistically close to the uniform distribution of the ciphertext. By the property of our smooth trapdoor functions, therefore, the original distributions, these two guys are going to be computationally indistinguishable. To construct smooth trapdoor functions out of lossy trapdoor functions, you only have to compose these functions with a pair-wise independent permutation. And actually, this construction was implicit in Baldur event others in 2008. So if you do that, if you first apply a pair-wise independent permutation, then a lossy trapdoor function by the leftover hash lemma, you'll end up with a smooth trapdoor function. This is why I say that smooth trapdoor functions are somewhat stronger primitive than lossy trapdoor functions, in that sense. And that was the way that Baldur event others constructed the termisy public encryption without actually defining calling out these smooth trapdoor functions as a separate primitive. The catch is that this construction is incompatible with our goal of incrementality. Because pair-wise independent permutations, by their definition, cannot be incremental. If you change one bit in the input, it can potentially affect all bits of the output. This is by definition of pair-wise independent permutations. So we have to do something different. But still, our construction will be inspired by existing constructions by freminate others, and even more closely by Barker-Skin-Segov from last year's scripting, will be inspired by construction of lossy trapdoor functions based under the DDH assumption. So we assume that we have a group of prime order p. To generate a key, we'll sample a matrix, a random matrix, a random n by n matrix where n is the size of the plain text. And the secret key is going to be the inverse of the matrix. The public key is going to be the generator of the group raised to the power of this matrix, which will just mean element-wise exponentiation. To encrypt, you multiply the plain text on the left by the matrix, and you raise due to this power. And it's relatively easy to see that you can do it given the public key alone. To decrypt, you use the inverse A inverse, which is the secret key, and to solve the disk log problem for bits, which is a very simple problem. In the security argument for lossy trapdoor functions, hinges on the fact that these two distributions, one is g raised to random full rank square matrices, and another g raised to random rank 1 matrices, these two distributions are computationally distinguishable. In the first family of matrices corresponds to the injective mode. The second family of matrices correspond to the lossy mode, where we compress a n-bit input to a single group element. For our goal of constructing incremental smooth trapdoor functions, we want these matrices to be sparse. This will guarantee incrementality. And our second goal is going to be somewhat different. We'll be happy with compressing the input to just l group elements. And the condition that we want to satisfy is that if the plain text has min and or pk, then under the second family of matrices, the result is going to be statistically close to the uniform distribution over a hyperplane of dimension l. How do we do that? Achieving the second property is actually easy. If we take, again, we'll want to construct sparse matrices. So we'll construct this skinning n by l matrix. Each of its row will have just a fixed number of small number of random elements. And multiplying this matrix by a vector will result in l group elements. And it's easy to verify that a combination of the sample and extract and left over hash lemma, or a variant of the left over hash lemma, guarantee that the result in distribution is going to be uniform over l group elements. Why is that? Because if we multiply this vector by this matrix, then each of the rows will select a random subset of these bits. So by the sample and extract lemma, it will mean that it will say that the result in subset will have some min entropy. And then a scalar product of a random vector is a strongly universal hash function, which by the left over hash lemma will guarantee uniformity of the output. But this matrix, this skinny matrix, cannot possibly be confused with the rank n matrix, because its rank is at most l. So what we'll do is that we'll take rows of this matrix and multiply them by random elements. It will make the matrix square, but it won't change the dimensionality of the output. It will still be confined to a hyperplane of dimension 3. And finally, on this example, the result in matrix can still have some structural zeros that form, that prevent it from being full rank. So we'll just add, by fiat, elements that will all end up on the main diagonal. And now we have these two family of matrices, one which I constructed as before, and another is obtained by replacing all non-zero elements on the left with random elements. So the matrix on the right with overwhelming probability will be a full rank, because its main diagonal is non-zeros. And under the dedutation assumption, g raised to the matrix on the left versus g raised to the matrix on the right, these two distributions are going to be computationally distinguishable. Incrementality follows by construction. We made sure that the matrix is sparse. If we update a single bit in the plain text, then only the bits touched by non-zero elements that sit in a single row will be updated. So sparses of the matrix will directly translate into incrementality of our scheme. So that concludes the talk with Open Problems. So meeting a stronger security definition. So the definition that we met is good for a single message. It's good for block sources. But there is a stronger definition that we don't know how to achieve under the goal of incrementality. It also would be interesting to construct a length-preserving incremental deterministic public encryption in the standard model. And there is a general question about deterministic encryption to relax the definition, to allow some dependency of the public key on the sources, and still give some meaningful security guarantees. So I call out this as an interesting problem in the area of deterministic public encryption. And with this, I conclude. We have time for a couple of questions. Question, question. Thank you. So I know you've already said you haven't met the strongest security model you'd like to. But I'm quite troubled by the security model you do use. So you're asking an adversary to distinguish between two sources, fair enough. But then you say those two sources will both have a certain minimum entropy. Now, when is that a safe assumption to make? Why would it be safe? That's an interesting question. I think it's fair to say that the examples that we have in mind are the following. There's a input, part of which the adversary control. And we don't really want to specify some specific control that the adversary has over the plain text. It can control some specific bytes of it, can inject some dependency between bits of the input. But still, the adversary doesn't know the entire plain text. There are some missing parts that will provide the required mean entropy. And in the spirit of symmetric security, it will give the adversary almost arbitrary control over the plain text, subject to this minimal requirement of mean entropy. I'm not sure if the answer is a question, but I think it's a relatively reasonable definition that subject, so you have to buy into this notion that the public is independent of the source. But after you make this step, I think the rest falls relatively, is fairly natural. Ilya, I have a question. Adi? I'm concerned about the following bed interaction between the various notions. So suppose you have a high entropy source. You have a database. You encrypted it. By looking at the original ciphertext, and the ciphertext obtained after you made some changes, in your scheme, it's quite easy to get an estimate of how many bits changed. So even though you will not know the plain text, you leaked information about the evolution of the database. So isn't it a problem in security definitions? That's correct, yes. So for the purpose of this talk, we wanted to separate the security under incrementality versus security under updates versus security of the underlying scheme. So think of it as a single shot game. First, an adversary has a single shot. So you update your ciphertext as many times as you want. You want to have efficiency here. At some point, the adversary intervenes and intercepts the ciphertext. And then the adversary has to determine which of the two sources you interacted with. So the adversary doesn't get to see the updates. But obviously, you can consider, and the stronger message definition allows the adversary to specify changes between the plain text. Any other questions? Good. Let's thank you again.