 So my talk will be about fully homomorphic encryption. So homomorphic encryption means that we can perform homomorphic operations on plain text while manipulating only ciphertext. For example, in RSA, if you have two ciphertexts for M1 and M2, if you multiply them, you get a new encryption for M1 times M2. And for this, you're only need to know the public key, not the private key. And there are also schemes which are homomorphic for addition, for example, pay a scheme given a ciphertext for M1 and ciphertext for M2. If you multiply them, you get modulo n squared. You get an encryption of M1 plus M2 modulo n. So we would like to have a fully homomorphic scheme that is a scheme which is homomorphic for both addition and multiplication. And as you know, this has been an open problem until Gentry's discovery three years ago. So currently, there are three known families of fully homomorphic schemes. There is the original scheme by Gentry, which is based on ideal lattices. So there has been some optimizations of this scheme by Smart and Verkotern. And at last, Eurocrypt, Gentry and Alevi described some optimizations and also an implementation with a public key size of 2.3 gigabytes and a ciphertext refresh time of 30 minutes. So this ciphertext refresh must be in principle done after every homomorphic operation. And then there is the second family of fully homomorphic schemes, which is the fully homomorphic scheme over the integers by Fanjik, Gentry, Alevi, and Vaikatoonatan. So the scheme is simpler than Gentry's scheme because it operates on integers instead of ideal lattices. And at last, Crypto, we described some optimizations and an implementation. And we got a public key size of 1 gigabyte and a ciphertext refresh of 15 minutes. So the timings are comparable. And then there is a third family of fully homomorphic schemes, which are based on the ring learning with error problem by Bakersky and Vaikatoonatan from last year. And this is probably the most promising family of schemes because one can do many interesting things in this family. One can do this amazing framework by Bakersky, Gentry, and Vaikatoonatan in which you can obtain fully homomorphic encryption without bootstrapping. And one can do also batch fully homomorphic encryption. This is basically the next talk. And recently, Gentry, Alevi, and Smart described an implementation of a variant in this family. And they were able to evaluate the full IUS homomorphically in less than one week. So but today, I'm going to concentrate on the second family of scheme, only the DGHV scheme. So I'm going to show two things, how to obtain a much smaller public key for DGHV, that is only 10 megabytes instead of 1 gigabyte. And also, I'm going to describe an improved attack against DGHV. So how does it work? So the scheme is very simple. So a ciphertext for a message m, which is just one bit, is simply q times p plus 2r plus n, where p is the secret key. So for p, usually, we take a prime integer. And q and r are random. So they are different for every ciphertext. And so m is the message bit. And so the ciphertext c is an approximate multiple of p. It's a multiple of p plus some noise. So this term 2r, we call this the noise. And to decrypt, so we simply reduce modulo p to eliminate this term. So there remains only 2r plus m. And then we reduce modulo 2, we look at the least significant bit to recover the message m. And if you don't know the secret key p, then you cannot decrypt because the message m is masked by this term q times p. So for the parameters of the scheme, basically we must take a very large ciphertext of size roughly 20 million bits. And this is to avoid lattice attacks. And so the ciphertext is huge. But the prime p, the secret key p, has a reasonable size. It's only 2,700 bits. So which means that to generate this huge ciphertext, we must take a very large q to have a large approximate multiple of p. And the noise here that is added has a much smaller size. It has only 71 bits. So basically to encrypt a single bit, we need a huge ciphertext of 20 million bits. So it's easy to see that the scheme has homomorphic properties because if you take c1 and c2, which are encryptions of m1 and m2, if you simply add them, then you get an encryption of m1 plus m2. So it's still an approximate multiple of p plus some noise plus m1 plus m2 modulo 2. And that's the same for multiplication because if you multiply c1 and c2, the modulo p parts get multiplied. And so here you still get an approximate multiple of p plus some thing, which is the product of these two parts. So that is some noise plus m1 times m2. So we get a new ciphertext for the product of the two bit plaintext. And here it's easy to compute the new noise, which is essentially the product of the two initial noise plus some term. So basically with multiplication, the size of the noise has increased. Its size is now twice larger. And this is what limits the amount of multiplication that we can perform because the noise is growing quickly. But the noise must remain smaller than p because otherwise there is a reduction modulo p and decryption becomes incorrect. So the number of multiplications is limited. So for example, if you start with ciphertext, with raw bits noise, when you multiply them, you get two raw bits of noise. And here four rows. So it's growing exponentially with the number of levels of multiplications. But here in this particular example, we must stop. Because if we do one more multiplication, then we get 8 rows, which is larger than p. And then decryption becomes incorrect. So of course you can always increase the size of the prime p to accommodate more multiplications. But the number of multiplications remains limited. That's why we call this a somewhat homomorphic scheme. This is not a fully homomorphic scheme because the number of multiplications is limited. So to get a fully homomorphic scheme, Gentry discovered this idea, which is to refresh the ciphertext or reduce the noise of the ciphertext by evaluating the decryption circuit homomorphically. And this is called bootstrapping. So how does this work? So here on the left side, I consider the regular decryption circuits for the encryption scheme. So it takes as input the secret key bits and the bits of the ciphertext. And there is a sequence of XOR gates and AND gates. And then eventually, this circuit would put the plain text bit. And now on the right side, we modify this circuit. We replace every AND gate by a homomorphic multiplication of ciphertext. And we replace every XOR gate by an addition of ciphertext. So that is, we perform exactly the same operations except that now we are manipulating ciphertext instead of individual bits. But the operations are the same because when you multiply two ciphertexts, it corresponds to AND of the corresponding plain text bits. So the operations are exactly the same. And now, since the circuit operates on ciphertext, it must take as input an encryption of the secret key bits. So for every secret key bit, we provide an encryption of it. And that's the same for the ciphertext bits. But actually, for the ciphertext bits, we can keep the same value because in the GHV scheme, 0 is an encryption of 0 and 1 is an encryption of 1. So we keep the same value. So here, those ciphertexts, they get combined inside this new decryption circuit. And since the same operations are done here on the right side and on the left side, eventually we get exactly the same value. That is, we get exactly the same plain text bit, except that it is not represented as a ciphertext. So we get a new ciphertext for the same plain text bit. Here, we started with a ciphertext, and we get a new ciphertext for exactly the same plain text bit. So we get a new encryption of the same bit. So the advantage of doing this is that if the number of multiplications inside this decryption circuit is not too large, then the noise of the ciphertext will not grow too much. The noise will remain small. So here, we start with fresh ciphertext, fresh encryption with small noise. And here, in this circuit, they get combined homomorphically. So the noise is going to grow. But at the end, if there are not too many multiplications, then the noise here in the result will not be too large, which means that the noise here can be smaller than in the original ciphertext, which means that we have decreased the noise in the ciphertext. And so which means that now we can perform additional homomorphic operations on this new ciphertext, which has been refreshed, which was not necessarily possible on this original ciphertext, because the noise was too high, and it was not possible to do any more multiplications. And so with this technique, the number of multiplications becomes unlimited. Every time we do an homomorphic operation, we refresh the ciphertext to reduce the noise. So we get a fully homomorphic encryption scheme. So for now, I have only described a secret key encryption scheme, because to encrypt, we need to know the secret key P. But actually, it's easy to get a public key encryption scheme. We simply provide in the public key a set of encryption of zeros, that is xi equals qip plus 2ri. And so then to encrypt a message m, we simply compute a subset sum of these encryptions of zeros. So this is still an encryption of zero. And so this gives an encryption of the message m. But when we do this, we get a huge public key, because every individual element is a ciphertext, which has 20 million bits. And we need roughly 10 to 4 of them for encryption to be secure. Otherwise, there is a lattice attack on the subset sum problem. And so this gives a public key size of 25 gigabytes, which is huge. And at last crypto, we show a different technique to encrypt with DGHV and based on quadratic encryption. And the size could be reduced to 1 gigabyte. But this is still very large. So now I'm going to describe a new technique to reduce the size of a ciphertext. And reduce the size of the public key. So the technique is very simple. So we start from a DGHV ciphertext, which is q times p plus 2r plus m, which is huge. It has 20 million bits. But p is much smaller. It has only 2,700 bits. And so the trick is the following. We compute a pseudo-random integer key with the same size as the full ciphertext from a seed which will be stored in the public key. So we compute this. So here we have a large random integer. And now we compute a correction delta such that this integer can become small modulo p. Because here we must obtain something which is small modulo p. And so for this, we compute delta as key minus 2r minus m modulo p. And then when we subtract delta to key modulo p, then of course we obtain key minus key. So it's 0 plus 2r plus m. So we obtain something which is small modulo p, as it should be. But now the advantage is that to generate this ciphertext, we don't need to store it in memory. We can only store the seed, the small seed, plus the correction delta to make it small modulo p. And we get a regular DGHV ciphertext. So since the correction delta is computed modulo p, it is very small. It has only 2,700 bits. So we only need to store 2,700 bits and the seed instead of 20 million bits. So for a single ciphertext. And of course, we can do the same for the full public key. So instead of storing all these huge elements of 20 million bits, we only store the corrections delta here. So instead of 25 gigabytes of public key, we get a public key of 3.4 megabytes, which is a significant compression. So now, of course, we would like that the scheme remains secure. So the original DGHV scheme, as a proof of security, it is semantically secure under the approximate GCD assumption, which is the following. You are given a set of x i's, which are approximate multiples of p plus some noise. And the goal is to recover p. So DGHV is secure under this assumption. So with or compressed public key, the problem is that we cannot really say that the x i's are random. Because to generate them, we use a pseudo-random generator. But with a public seed, here the seed is public. So we cannot really say that the result is pseudo-random. But what we can still have is security in the random miracle model and still based on the approximate GCD assumption. So the proof goes as follows. So in the public key generation, to generate these x i's, first we generate this large pseudo-random integer by lashing the seed and the index i of the public key element. Then we compute the correction delta i, which is key i modulo p. And we also add a random multiple of p. And this is to obtain a correction delta in a constant interval. Because if we don't add this random multiple of p, then we get something which is essentially modulo p. So it's going to leak the higher order bits of p. But by doing this, we are in a constant interval. And then we subtract this correction delta to get x i, which is small modulo p. And in the proof in the random miracle model, in the simulation, we proceed in the other direction. That is, we start with the element x i, which is given to us by the instance of the approximate GCD problem. So of course, we only know x i, not q i and r i. Then we compute an arbitrary correction delta i. And then since we are in the random miracle model, we can program the random miracle so that it puts exactly what we want. So it's going to output x i plus delta i, such that when we subtract delta i, we get x i, which is small modulo p, as it should be. And it's easy to show that those elements here on the left and on the right, they have statistically close distribution, which means that our simulation is almost perfect. And so we can really use the x i's from the approximate GCD instance to generate the public key. And then the proof proceeds exactly as in the original GCD scheme. So we have implemented the scheme for various set of parameters, and we get a public key size of roughly 10 megabytes instead of 1 gigabyte in the previous implementation at crypto. And the performances are the same. So the public key size becomes rather practical, but still, a ciphertext refresh is still time consuming. So now I'm going to focus on the ARNES assumption of the DGHV scheme. So as I said, the original DGHV scheme is secure under what we call the general approximate command divisor assumption, which is given polynomially many x i's, which are approximate multiples of p plus some noise. The goal is to recover p. And so this is called approximate command divisor because if there was no noise here, you could simply take the GCD between two elements, and you would recover p. But here, you cannot do that because there is this noise. But we also consider a variant of this problem in which we are also given an exact multiple of p. So we are given x 0 equals q 0 times p, and also polynomially many x i's, which are approximate multiples of p. So we call this the partial approximate command divisor. So why do we do this? It's because the DGHV scheme becomes more efficient under this variant. When you have an exact multiple, the homomorphic operations are more efficient. So clearly, the partial version is easier because we have more information. We have this exact multiple. But the question is, how much easier? So first, I'm going to concentrate on the partial version. That is, we are given an exact multiple of p, p times q 0, and polynomially many approximate multiples. And we must recover p. So there is a brute force attack which takes two to all GCD computations. So we take the exact multiple. And then for all possible values of r1, we compute the GCD. And so we recover p after two to all GCD computations. And there is also a variant which was suggested by Fung, Fung and Guyan, which has the same complexity. So the observation is that p is equal with good probability to the GCD of x 0, the exact multiple, and the product for all possible values of i's of x 1 minus i. And so here, for the correct value of i, when i is equal to r1, then x 1 minus r1 is an exact multiple of p. So this is equal to 0 modulo p. So this full product is equal to 0 modulo p. And so by taking the GCD, we recover p. But this variant has the same complexity, because we still have to perform two-to-row multiplications. But in practice, it's a little bit faster. Because multiplications are a little bit faster in practice than GCD computations. And then there is an improved attack with complexity two-to-row over two time. So strictly better than exhaustive search. And time and memory by Chen and Guyan, it will be presented this afternoon. So I'm not going to describe it. So now I'm going to consider the general problem. So that is the variant without the exact multiple. So we are only given polynomially many x i's, which are approximate multiples of p. And we must find p. But we are not given x 0. So again, as previously, there is a brute force attack. We use x 1 and x 2. And we guess r1 and r2 to perform the GCD. And so it takes two-to-row GCD computations. But of course, we can also use the Chen and Guyan attack. Because the Chen and Guyan attack requires an exact multiple of p. So what we do is we simply guess r1 to obtain an exact multiple. And then we apply the Chen and Guyan attack on r2. So the running time is the product of the time of the exhaustive search of r1, time, the complexity of Chen and Guyan. So it gives two-to-row over two time, and two-to-row over two memory. And so it's better than the brute force attack. And now I'm going to show an even better attack, which has complexity, two-to-row time, and memory. So the attack works as follows. So we are given all these approximate multiples of p. And we must recover p. So we start from a variant of the previous equation with two approximate multiples, x 1 and x 2. So as previously, we compute a product of x 1 minus i for all possible values of i. And we do the same with x 2. So here, for the correct value of i, when i is equal to r1, this is a multiple of p. So the full product is a multiple of p. And here, the full product is a multiple of p. So p divides the GCD. And so the problem is that these products are huge, because no, they are computed over the integers, not modulo x, x0, because we don't know x0. So they are huge. We need two-to-row memory to store them. And also, they can be computed in two-to-row time using a product tree. So the computation of these two products, and then the GCD, is two-to-row time and memory. But the problem is that we do not recover p directly, because p is only a divisor of the GCD. And there are many parasitic factors. But the trick to eliminate these parasitic factors is to take the GCD with more big products. So here, we can use the product with x3 and so on. And we eliminate the parasitic factors by using a sequence of GCDs. But only a very small number of GCDs is necessary, only it's probably logarithmic in row. So no, sorry, linear in row. And so we can easily eliminate these big factors. And we also eliminate the small prime factors by dividing by factorial b for a small bound b. So the attack works well in practice. And in the proceedings, we have a heuristic analysis to explain why it works. So here, for information, I give the source code of v attack to show that it is quite simple. So in Sage, we generate the random prime. We compute this small bound b, two-to-row, factorial b. Then we have a loop where we compute the approximate multiple of p. Then we compute the big product of x minus i for all possible values of i. Then when we have two such big products, we compute the GCD. And then we compute the GCD with factorial to eliminate the small prime factors. So here, we have a loop. And we continue. So the size of the current GCD is decreasing, because we are eliminating the parasitic factors. And eventually, it has the same size as p, so we have recovered p. So we have implemented this attack. And so here, I give the running time. So we wanted to compare with the second-best attack, which is the Shen-Nguyen attack. So the Shen-Nguyen attack requires an exhaustive search of the first random to get an exact multiple. So we have simply taken their running time in their paper, and we have multiplied by the time of the exhaustive search. And so we see that for this parameter here, our attack is much faster, because it takes only 17 hours instead of 3,000 hours. But our attack requires more memory. So we cannot go really much further, because our attack requires 2 to rho memory instead of 2 to rho over 2 memory. But time memory trade-offs are still possible. So to conclude, I have shown two things. So a smaller public key for the DGV scheme, that is take 10 megabytes instead of 1 gigabyte. Also, I have shown a better attack against the approximate GCD without the x0, with complexity 2 to rho instead of 2 to 3 over 2. And in the proceedings, we show two more things. So a generalization of our technique from crypto of quadratic encryption to higher degrees. And also, we show that with DGHV, we can also do DGHV without botstrapping, with modulus switching. Exactly. This is analogous to what was done by Brackersky, Gentry, and Veketunatan with the RLW scheme. So this is Vian of NATO. Thank you for your attention. We have time for one question, if any. I'm sorry? Can you use the microphone? So you have modified this x subscript 0 from the general scheme to this product of Q times prime. There is no error in it. I'm sorry. I do not. Yeah, your question. OK. You have modified the x subscript 0 from the original scheme, right? Right. Without error. But isn't it the point of one of the point of these schemes is they should be secure against quantum attacks? Because now you can factor it, right? Actually, here, P is a large prime. It's 2,700 bits. And Q0 is huge. It has millions of bits. So you cannot really factor it. No, I mean with quantum attacks, one of the point of these schemes where they were secure quantum mechanically. Like with sure algorithms. You don't know sure quantum algorithms, for fact? Quantum mechanical, quantum computer. It's OK. So you want to factor this using quantum computing? No, no. I'm saying that one of the point of these new schemes where they should be secure against sure algorithms. They're considered like post quantum assumptions. So when you modify this, then you are losing that. Yeah, of course, if you can factor. OK, so let's thank the speaker again.