 Okay, can you hear me? Great, thanks for the introduction. So, without further ado. Okay, fully morphic encryption, fully morphic, fully morphic, fully morphic, fully morphic. So, yeah. So, I'll start with a bit of an introduction on fully morphic encryption, which those of you who are there at the tutorial session yesterday will probably find somewhat, but hopefully not fully redundant. And then I'll say a few more precise words about the fully morphic scheme over the integers from Eurocrypt last year, which we are improving in some sense. And then I'll give another view of our contribution, though I probably won't be able to go in as much details as I wish I could. So, fully morphic encryption, so basically homomorphic encryption, encryption scheme is homomorphic when you can do operations when you can compute encrypted data. For example, you have multiplicatively homomorphic scheme. For example, textbook RSA in which you can compute the ciphertext associated with the product of two messages, knowing ciphertext associated with those two messages without knowing, without having to decrypt or knowing the secret key. So, it can be publicly done. You have additively homomorphic schemes and fully homomorphic schemes is when you can do both additions and multiplications. And that was an open problem until Gentry's breakthrough in 2009. So, we're restricting ourselves to encryption of bits. So, we are considering ciphertext associated with the encryption of either zero or one. And that's what we're trying to compute on. So, given encryptions of one bit and another, we want to be able to compute an encryption of either the XOR of those bits or their end, their product without knowing the private key. What that allows us to do is compute essentially any Boolean circuit on encrypted data, at least a Boolean circuit with a polyon milliminigate. And so, you can compute pretty much any function on families of bits on encrypted data without knowing the private key. So, an example, a use case for homomorphic encryption given by my advisor who's more business minded than I am is the following. So, you have, imagine you have a software that predicts the stock price of a company based on a number of data about it. And I want to know the future stock price of my company, but I don't want to disclose a confidential information about it. And you don't want to give me your software because it's worth a lot of money, I don't know. And so, we can do that with a homomorphic encryption. I encrypt all my secret data with a free homomorphic encryption scheme and I send it to you in encrypted form and you process those inputs in encrypted form using homomorphically, applying your software homomorphically. And you send me back the result, still encrypted and I decrypt it myself. You didn't learn anything about my data and I didn't learn anything about your software. Okay, so, more generally, so maybe you can hope to achieve secure cloud computing, things like that. And more importantly for some of us, it's, there's very nice mathematics in this. Topic. So, there are not many examples of a free homomorphic encryption scheme yet. There's the original scheme by Gentry and there's a somewhat arguably conceptually simpler scheme by Van Dijk, Gentry, Hallevi and Vaikuta data presented that you recrypt last year, which we are extending somewhat and that was about it. Until a few months ago, you will see interesting, exciting new stuff in the next talk. And those schemes are quite far from practical. So for example, if I take the scheme from your clip last year, if you want a reasonable level of security, the rule of thumb, the public key size would be something like two to the 60 bits. Which I can't store on my personal computer. And for Gentry's scheme, it's a bit, probably a bit difficult to give hard to suggest actual parameters. So there has been an effort to maybe not make this actually practical, but progress towards that goal. So for Gentry's scheme, that does improvements by your smart and Vercautron last year at PKC. And Gentry and Hallevi used that and many clever tricks at your recrypt to actually implement Gentry's scheme. And they obtained an implementation with public key size two gigabytes and CypherTax refresh 30 minutes. So that's CypherTax refresh, something that you want to do basically for every multiplications between encrypted bits. That's still far from practical, but at least you can implement it. And this work is about doing the same for the schemes of our Dintegra. So we propose parameters that give you a public key size of 800 megabytes and CypherTax refresh in 15 minutes. But as Shai was saying in his session yesterday, the parameter choice might actually be a somewhat overconfident, as I said. So I'll discuss that a bit later. Okay, in practicality, we're getting much closer to it with very recent new works, especially about fullyomorphic encryption without bootstrapping. But it's not my place to tell you about it. So how do you build those traditional types of traditional data to two years old but of fullyomorphic encryption schemes? You start from something called a somewhat homomorphic encryption scheme in which you can apply polynomials on your binary data, but only polynomials up to a bounded degree. So your CypherTax are somewhat noisy in some sense and the noise increases when you apply homomorphic operations and when the noise becomes too large, so when the polynomial has a too large degree, the noise becomes too large and you can't decrypt anymore, you can't decrypt correctly anymore. So, and then if you can fit in that bound on the degree, you can fit the decryption function for your scheme. Then you can hope to apply it homomorphically and then decrypt in a homomorphic way. So that's the idea. So you have your decryption circuit which upon giving CypherTax bit and secret key bits gives you the plain text. So the CypherTax for a public person, it's a public data. Then you can give it encryption of secret key bits and you put that in the decryption circuit and apply the homomorphic evaluation function in what you get. If the decryption circuit is low depth enough, if it fits in your somewhat homomorphic scheme, what you get the result is an encryption of the result here, so an encryption of a plain text bit and that's a CypherTax for the original plain text, the original, a new CypherTax for the original message. That's a refresh and hopefully the noise here might be lower than the noise you started with and that allows you to do more homomorphic operation. So that's the great idea by Gentry. Yeah, so that's the idea. The problem here is that you have to obtain a decryption circuit of sufficiently low depth to fit everything. Okay, now I turn to the somewhat homomorphic part of the scheme from your group last year. So your keys, your public key is consists of a set of multiples of a certain, say, odd prime P of near multiples, let's say. So very large numbers which are multiples of P plus some noise. And so I'll give a slightly simplified description in which you also give an exact multiple. So then, how do you encrypt the message with that? You pick your message, you add some even small noise to it and you add a secret random subset sum of your public key elements. And how can you decrypt that? Then that's all mod X0 and I can reduce it mod P since X0 is a multiple of P and I see that the safer text is the message plus something even. And if the noise is a smaller than P, say much smaller than P, then the equality, when I reduce mod P, I have the equality of all the integers and I can take the result mod two and recover my number M. So to decrypt time, I always have to take care about the size of the noise. So it's easy to see that to do addition and multiplication as I can simply add and multiply ciphertext mod X0 as long as the noise remains small enough. Okay, and I have a number of multiplications that are possible that is about the size of P divided by the size of the noise. So if we estimate exactly parameters involved, you see in the original papers as I said that the public side should be about lambda to the 10 where lambda is your security parameters. That's two to the 62 for 72 bits of security which is our target, it's not very large but that's our modest target for now. So what we want to do here is reduce it to something more manageable. So to do that, we take our public key elements and a smaller number of them and multiply them two by two. So the public key elements will look like X i, X j and to encrypt, you do a subset sum not of the public key elements but of the two by two products of them. And that will look something like that. And if you analyze your various constraints, you find that the number of pairs of elements you can take is about lambda to the square, lambda square. So your public key will be two beta elements of a size gamma which was lambda to the fifth power. So it's lambda two times lambda five, lambda seven, compared, so it's still pretty large but compared to lambda to the 10, it's a significant improvement. So we have to prove that this construction is secure and the proof goes mostly the same way as in the Eurogroup paper except that we have to show at some point that since it's indistinguishability, semantic security, we have to show that something is statistically close to uniform. So in the Eurogroup paper, it's done using the leftover hash lemma applied to a family of functions of universal functions of that form, which is linear, which is pretty classical. And to extend it, since we have a quadratic way of generating our ciphertext, it's functions, the family of say universal hash function of that form, which is quadratic and no longer linear. So we have to prove that it's not exactly a universal hash function, it's close enough to apply a slightly modified leftover hash lemma. And we can actually do that. It's a pretty nice math. So you have to count points on hyperbolic quadrics in over Z to the mode Q zero. And that's probably the main contribution, technical contribution of that paper. So what are our hypothesis? So the scheme I've just described. So both are simplified scheme from Eurocrypt and our paper that's based on the partial approximate common divisor problem. So you have plenty of near multiple of some number P and an exact multiple. That's our problem, we suppose that's the start. And the original paper was slightly more complicated in this formulation but was based on the general approximate common divisor problem where you don't give the adversary an exact multiple. So of course the second one looks stronger than the first and but we didn't know before like last week that any better attack on the second problem than on the first, so it was all very nice. Unfortunately it seems that it doesn't quite work like that. Okay, so that was for the somewhat homomorphic part and you have also a squashed, the extended part that brings everything to fully homomorphic. So I don't have time to go into details there but there are some problems because even if you analyze things precisely, if you do things exactly like in the Eurocrypt paper, then your key grows again to something like lambda to the eight whereas in the somewhat homomorphic scheme it was lambda to the seven, so we have a problem. So there are various tricks mostly borrowed to Gentry and Hallévis paper at Eurocrypt this year to shrink the key in this squashed part as well. Which I won't go into. Then we try to propose concrete parameters so that the idea was to find, enumerate all the attacks available on those problems and see how they work so that we can pick the smallest possible parameters to avoid them. Okay, so there are several attacks, brute force on the noise. Also gonna let his base attack on the GACD problem, let his base attack on the sparse subset some problem and these gave us some parameters. In particular, they were saying the 72 bits of security gave you a public key size of 800 bits, recursion operation of 15 minutes, et cetera. Unfortunately, so last week that there was a paper on Eprint published by Chang and NGN that pretty much broke those parameters by finding a more efficient attack on PACD and also on GACD but not as efficient. And so our stated security level is not as large as we were hoping, so instead of 72 for example it's less than 67. So we would have to hike the parameters here a little to reach the same level of security as Genry and Halevi and that would make our key size, et cetera, less competitive. But then there's also a new attack that you might have heard in the room session yesterday. But anyway, I think this shows reasonably even if we have to hike parameters a bit that the screen from your clip last year can be compressed to something that at least you can implement on a standard PC. It's not quite practically yet, not near practically yet but there's ongoing progress. So you have exciting new developments around without bootstrapping stuff that you might even apply over the integers that's working progress. You can compress a public keys much further if you look at Eprint right now, there does a paper. We do it by a factor of like 200 and some more technical contributions. On the other hand, there's also progress when I'm taking the underlying Hale problem. So then also sort of raise here. Thank you. So we're on a tight schedule so we'll move directly to the next talk and we'll see you in a minute. Thank you.