 Hello everybody, my name is Sébastien Duval and I'll be talking about the couple analysis of the flip family of stream ciphers that we did together with Virginie Lallement and Jan Rotella. So first I'm going to introduce the context which is symmetric ciphers for fully homomorphic encryption. I'm going to introduce the cipher and I'm going to talk about our attack, the possible improvements we have and the experiment of the vacation we did. So first let's go very fast to the basics of fully homomorphic encryption. So the idea is you don't have much computational power so you want to delegate your computations to the cloud so you are going to send your data to the cloud but you don't want the cloud to get any information about your data so you are going to encrypt it using a homomorphic encryption algorithm. The cloud will perform its operations homomorphically and then send the data back to you, you decrypt it and you get the message modified in the right manner. There is one problem here which is that the homomorphic encryption algorithms we have all put huge ciphertext so if you have many messages or big messages it's not going to be very practical. So one way to go around this is to add a symmetric encryption on top of it. What you encrypt using the homomorphic encryption algorithm is the key to the symmetric encryption. That key is relatively small and it's of fixed size and you send it only once so that's not too costly and in parallel to this you encrypt your message using the symmetric encryption algorithm. You send all this to the cloud and the cloud on its side will be able to perform homomorphically the inverse evaluation of the symmetric encryption algorithm and get back the ciphertext like there was no symmetric encryption in the process whatsoever. There's still a problem here which is that the homomorphic encryption algorithms we have use a parameter called noise and if this noise grows too big it becomes very costly to handle so you have to limit the amount of noise and noise grows mostly from non-linear operations done homomorphically so for instance multiplications so for all functions that are applied homomorphically you want to limit the number of multiplications. Here the function that is applied homomorphically is the inverse evaluation of the symmetric encryption algorithm so you want to limit the number of multiplications in this. There are very few ciphers that fit these kind of requirements one of them is a block cipher called low MC it's an SPN with the specificity that the substitution layer is not applied on the entire word at every round to avoid having too many multiplications. The advantage of block ciphers in this context is that each bit of the ciphertext depends on the same number of multiplications but that number of multiplications is quite big. There are also stream ciphers Trivium and Trivium with the advantage that in stream ciphers the first bits of the key stream so the first bits of the ciphertext depend on very few multiplications but the number of multiplications grows with the number of ciphertext bits. So none of these are excellent solutions and a new solution was proposed recently with a better noise management it's called FLIP. FLIP was designed by Péric Meaux, Anthony Journaud, François Xavier Stonbert and Claude Carlet and it was published at Eurocup this year but I'm not going to be talking about the version that was published I'm going to talk about a version that was presented at National Seminar and it's also the version that was submitted and accepted at Eurocup. It was modified afterwards when we told the authors about our attack so the version that is published doesn't have the flaws that the old one has. So FLIP is a stream cipher with very few multiplications and actually that number of multiplications is constant for every ciphertext bit. They achieve this through a constant key register and a low-degree function. In more details this is FLIP so there is a key register storing the key k there is a permutation generator that outputs a random permutation at each time and there is a filtering function f. This cipher outputs key stream bit zi at each time and this key stream bit is explored with the plaintext to a plain the ciphertext. The way the key stream bit zi is produced is first you reorder the key bits and then you feed this to the filtering function f. The only thing that changes at each time is the permutation used to reorder the key bits. But this permutation is public because it's the output of a public random permutation generator which depends on the public PRNJ which depends on the public IV. So all this is public. The only thing that's not down to an attacker is the key. There's one more thing in the specification of FLIP which is that the key should be balanced. So let's look deeper. This is the filtering function f at least in the early version because that's what was changed the most in the new versions. So the filtering function f is the direct sum of three main components. Each of these components is meant to add resistance against one type of attack. There's a linear component L with N1 monomials of Degree 1. There's a quadratic component with only monomials of Degree 2. And there is a triangular function with one monomial of each degree between one and a certain degree k which is the degree of the function f. Each bit of the key appears only once in the formula of f. And what we can notice already is that there are very few monomials of degree greater than or equal to 3. And they are all in the function t. And they are the monomial of degree 3, the monomial of degree 4 until the monomial of degree k. There are only k minus 2 of those. So that's very few. In the early versions the earthers proposed two sets of parameters, one for an 80-bit security with a key of 192 bits and one for a security of 128 with a key of 400 bits. We identified several vulnerabilities of flip because having a constant key register and a low number of hydrogemonomials, that's excellent when it comes to FHE, but it can also be a weakness against guessing attacks. Indeed, having a constant key register means that if you make a guess at some time, that guess will hold out any other time. So that's pretty big. And having a low number of hydrogemonomials means that with only a few guesses, k minus 2 here with k the degree of the filtering function. With only k minus 2 guesses, you can manage to cancel all the monomials of degree greater than or equal to 3. If it's not clear how you do it, I'll be talking about this in a minute. That also can be seen as an algebraic vulnerability in the sense that having very few hydrogemonomials, the filtering function is often quadratic in the key bits. So how do we proceed? We're going to make a guess. We're not exactly going to guess the value of the key bits. That's almost the same. Remember that the key is balanced. There are positions that are zero. We are going to guess several positions of bits that are zero in the key, which is almost equivalent to saying that several of the key bits equal zero. Then we're going to wait for a time when all these key bits get permuted into all the monomials of degree greater than or equal to 3. Meaning that you get one of the guess key bits in each monomial degree greater than or equal to 3. So if the guess is correct, all these monomials are canceled and you are left with an equation of quadratic in the key bits. So you obtain one equation of quadratic in the key bits. You fetch it and you start again until you have enough equations to solve a quadratic system. You solve this quadratic system using, for instance, linearization techniques. You get one of two results. Either there is a contradiction in which case the guess is wrong and you start again from the beginning with another guess. Or the guess is correct in which case you get the key because it is a system in the key bits. So that's the attack. So now for its complexity. It depends on two main probabilities. The first one is the probability that the guess is correct. We do know this by PRG. Its formula is not very hard to compute, so it's just given here. The second probability is the probability of obtaining a quadratic equation at some time, which is equivalent to having all the guess, all the guess bits dispatched in all the monomials of the greater than or equal to 3. In a general case, the formula of this probability is a bit complicated, but if you make the minimum number of guesses, which is the number of monomials of the greater than or equal to 3, in that case the expression simplifies. Having those probabilities, we can compute the attack complexity if we assume that we are going to solve the quadratic system using linearization techniques and Gaussian elimination. If we call VL the number of variables in the linear system, which is also the number of equations we need to solve the system, the data complexity can be expressed as the number of equations we need multiplied by the time to get a quadratic attack equation. That's the number of key stream bits we are going to need to perform the attack. The time complexity can be seen as the time to solve the quadratic system multiplied by the number of guesses we need to get a correct system. And the memory complexity is the space to store the quadratic system, plus in some models we have to store the data also. This is in the known IV model, but actually if we have chosen IV model, we can do a bit better than this for the data, because we can see the data complexity as the number of queries we have to make to an oracle for the value of the key stream bits. So that's only the key stream bits we need to perform the attack, not the key stream bits that we have to generate, but the key stream bits we will actually use. And that's only the number of equations multiplied by the number of guesses we have to make, which is actually quite smaller. Now with a few pictures, so this is flip. And down here we have the expression of the key stream bit at time zero in the key bits. In red we have the linear part. In blue that's the quadratic part, and in green it's the triangular function with one monomial of each degree between one and k. So I'm going to make k minus two guesses. Let's say k minus two, that's the minimum I need. I'm going to guess that the red positions here equal zero. And I'm going to wait until these positions get permuted into all the monomials of degree greater than or equal to three. So at time zero it doesn't work. There are still monomials of degree greater than or equal to three. At time one there are also still monomials of degree greater than or equal to three. But at time two all these monomials get cancelled and if the guess is correct this is a quadratic equation. I fetch it and I start again until I have enough equations to solve the quadratic system. If the guess is correct I will then get the key. There are several possible traders for this attack. For instance we can make more than k minus two guesses. What is going to change basically is that it will require more time because the probability that the guess will be correct will be smaller. But it's going to require less data because at each time there are more chances that the equation will be quadratic having more bits guessed to zero. Also we can do a lot of pre-computation because the plaintext only comes at the end in this attack. The quadratic system only depends on the positions of the key bits and on the guess. So all this you can do before as pre-computation. You can generate the quadratic system and you can make its inversion. All this can be done offline and then at the end you can simply plug in the plaintext with a simple matrix vector multiplication. So the online time will be reduced from basically VL cube to VL squared. So that's nice. The other possible improvements we can for instance choose the guess better than at random. One way to do this is to look at the first two to the C permutations and make a guess that gives quadratic equations for many of these first permutations. That way we don't have to wait as long to get exploitable permutations and we need less data. We can also do a better solving because actually our system is quite specific. It's sparse, it's binary and it's quadratic. So there are better methods to solve this than linearization techniques with a Gaussian elimination. But we didn't look too much into it because actually the attack is already good enough as it is. And also the attack is entirely parallelizable. One way to parallelize it is to make for instance one guess on each computer and launch it. We made an experiment of verification of this on a toy version of the key of 64 bits and we compared the practical complexity with the theoretical one and what we get basically is that the practical complexity is almost the same as the theory. So if you look at table for instance, we need two to the 18.4 key string bits in practice which is exactly the same as in theory. So now for the sets of parameters for the early version. So in the upper table you have the 18-bit security version. We have a time complexity of two to the 54 without any optimizations with a known IEV model. That's the first yellow line. But if you put in optimizations and in a chosen IEV model, you can reduce this to an online time complexity of two to the 40 with two to the 54 as per computation. For the 128-bit version without any optimizations, you have a time complexity of two to the 68. But if you optimize, you have a time complexity of two to the 52. And what we managed to prove actually is that the time complexity is proportional to the square root of the key size. So simply putting in bigger keys is not the best way to patch this kind of ciphers. We communicated these results to the designers of Flip and they changed their cipher to resist our attack. Basically what they did is they changed the filtering function. They didn't change the linear part or the quadratic part but they put in more of the so-called triangular functions and they put in much bigger keys also. So now for the 128-bit security version, the key is 1,394 bits long. And as you can see in the table, the attack is not possible anymore. So that's it. To conclude, we have an attack on the flip funny of stream ciphers using guess and determine techniques that exploit the constant key register and the low number of hydrogen monomials in the filtering function. This attack is almost practical and we managed to verify it experimentally in a toy version. But there are still open questions about this because we attacked in one instance but it doesn't mean that the structure in itself is weak. So one question that we can ask is, for instance, whether the constant key register is still an exploitable weakness in the new versions of flip. So that's it for me. Thank you for your attention. If you have any questions.