 Hi, my name is Michael and I'm going to talk about lattice block reduction. Production algorithms are key to encrypt analysis, especially but not limited to lattice-based cryptography. So it is very important to understand what they can achieve both in theory and in practice. The focus of this talk is a class of algorithms that we call slide type reductions that have so far been considered mostly of theoretical interest because they are not competitive in practice. In our work we apply a more fine-grade analysis due to Arron, Puyol and Stille from crypto 7 to this class of algorithms and this leads to some improved theoretical results, in particular improved bounds on their running time. But more importantly, we discover a new trade-off between the running time and the output quality of these algorithms. And this leads us to a variant that is actually quite competitive in practice in which we confirm by experiments. And this is interesting because this type of algorithm has some very nice features. For example, it is easy to parallelize and distribute, which is a feature that other block reduction algorithms don't have. And we also believe that there is some room or a lot of room for further improvement. So this could lead to faster practical algorithms actually. And now we're going to start with some background. A lattice is a discrete subset of RM. Yeah, I have depicted a lattice in R2. And lettuces have a number of hard problems associated to them. And one of these hard problems is the so-called shortest vector problem. And here, the task is given a lattice to find the shortest non-zero vector in this lattice. The length of the shortest non-zero vector is usually denoted by lambda 1 and called the first minimum. The shortest vector problem is trivial in dimension 2, but as dimension increases, it becomes harder and harder. And all known algorithms have at least exponential running time in the dimension of the lattice. And we don't expect that to change anytime soon because the shortest vector problem is actually NP-hard under randomized reductions. An easy way to describe a lattice is by giving a basis. A basis is a set of linearly independent vectors that you can think of as a matrix. And these basis vectors, they generate the lattice by means of integer linear combinations. A basis is not unique. In fact, every lattice with dimension larger than one has infinitely many bases. And for example, the blue set of vectors is also a basis for the same lattice. And it turns out that some bases are better than others when it comes to solving computational problems. For example, if a basis already includes the shortest non-zero vector, well then the shortest vector problem is trivial to solve given that basis. As a goal of lattice reduction, it's actually to turn bad bases into good bases. And this requires a way, though, for us to quantify the quality of the basis. And this is what we're going to look at next. So consider a specific basis. Before we can start talking about how we quantify the quality of a basis, we need the notion of a projected subblock. So consider a set of vectors of the basis inside this green block. Then we can take all preceding vectors, which we call the head of the basis, and we can project the vectors in our green block orthogonally to the head of the basis. And this gives us a projected subblock of the basis. And these vectors in itself generate a projected sub lattice. And we can apply this process actually not only to blocks of vectors, but also to single vectors, to blocks of size one. For example, we can apply it to the first basis vector, which leaves it unchanged because there's no head of the basis, and so there's no projection. So the first vector remains unchanged. But the second one changes and gives us a projected vector. And we can continue doing this up to the last vector. And this gives us a set of vectors, which we call the GSO vectors. These are the Gram-Schmidt vectors, because they are the result of the Gram-Schmidt authorization process. Now notice that the Gram-Schmidt vectors are not actually a basis of our lattice. They're a separate matrix that is related to our basis, but it's not a basis itself. In order to quantify the quality of our basis, we're going to look at the length of the GSO vectors of our basis. And we're going to take the length of these vectors and we're going to plot it against the index i. And we're going to do so in a log scale. And this gives us the shape of the basis. And the shape is crucial for the quality of our basis. In the rest of this talk, we will focus on these shapes of basis and we will represent basis by their shapes. And we will also refer to sub-blocks of such shapes. And I want you to remember throughout this talk that what I really mean by this is actually the corresponding projected sub-block in the corresponding basis. The basis is associated or represented by this shape. Okay? So let's focus on the shape of a basis. So this shape is pretty typical for an input basis we might get into our algorithm. And as you can see, there is this linear drop-off. And remember that we're plotting this in log scale so this actually corresponds to a exponential drop-off in the actual length of the GSO vectors. But as I said, this linear drop-off is pretty typical so we may approximate it with line. And so from now on, I'm going to work with these idealized shapes of basis to get the ideas across in this talk. So the area under the curve of such a shape is actually a lattice constant. So any basis of this lattice will have the same area under this curve. And since this linear drop-off is pretty typical for a lattice basis, the goal of lattice reduction is actually to reduce the slope of this line. And what that means, well, recall that the first vector of the GSO of the GSO vectors is actually a lattice vector, right? Everything else is projected, but the first vector is not. So the first vector is actually a lattice vector. And so that means if the slope is smaller of this line, then also the first vector is relatively short. Now, assume that we have an algorithm available that finds the shortest vector in a given lattice. Again, this is a hard problem, but assume for now that we have such a algorithm available, what can we do? We should be able to convince ourselves that you can come up with a basis that actually contains this shortest vector. And let's say this vector is in the first place of the basis. What does such a basis look like? Like what's the shape? Well, it probably looks something like this. Now, what we can also do is we can actually apply this algorithm also to the dual of our lattice. And you don't need to know what the dual is to understand this, but what that will do effectively is will change the shape of our basis such that it looks like this. So instead of minimizing the first vector of our basis, what this application does, it is maximizing the last vector in our basis. But as I said, solving the shortest vector problem in such a large dimension is actually pretty hard. And we might not have enough time or resources to do this. So what we can do instead is we can apply such an operation to a projected subblock of the basis. So we can, for example, pick out this block and then apply an SVP oracle to the smaller dimensional lattice. And this might turn the basis into a shape that looks like this. And similarly, if we apply the same operation in the dual. And now the basic idea of block reduction is simply to apply these two operations in certain orders in order to improve the shape of the basis overall, right? Like apply this local operation to improve the basis globally. And one of these reduction algorithms is what is called slide reduction. Then an algorithm that was proposed by Gamma and Grimm in 2008. And the basic idea is relatively simple. So what we're going to do is we're going to apply the primal SVP reduction to all the disjoint blocks. So we're going to break up the basis into, you know, a set of disjoint blocks. We're going to apply a SVP reduction to each of those in parallel. And then the basis might look something like this. And then as the next step, we're going to apply the dual operation, the dual SVP operation, to blocks that are shifted by one position. So this gives us these pivot points, right? That these are the vectors that are in the first step, they're minimized with respect to the block to the right. And in the second step, they're maximized with respect to the block on the left. And then we're going to loop this over and over. And as this happens, information is transported from the right to the left to the basis through these pivot points. Let's have a look what this looks like in action. So here I'm simulating an example of a run of slide reduction on a lattice with dimension 300 and blocks like 75. So this means we have four primer blocks and three dual blocks. And as you can see, the point on the left that represents the length of the first vector in the basis is creeping towards the red line. It's creeping slowly, but it's getting there. And the red line actually represents the expected result for the length of this first vector. Now, if we were to use larger blocks than 75, for example, let's say 100, then we'd only have three blocks. But then the red line would actually be lower. So the output would actually be better. The first vector would be shorter in this case. But then each of the oracle calls would be much more expensive. So that's a typical tradeoff that's provided by block reduction. It's usually controlled by the size of these blocks. To understand the improvement in this work, let's have a look at our shape again. Our improvement was actually inspired by a recent observation made in the work of Albrecht Tuka, Erwald, Köschenhofer, Hothaway, Stevens and Eurocrypt 19. And what they observed is that our model for SVP reduction of a block is actually pretty bad when using modern SVP solvers. So we modeled it in a following way, right? Like we looked at a specific subblock. We said, well, if we apply the SVP reduction in this block, the result is going to look like something like this. But if we use the modern SVP solvers, the observation in the aforementioned work was that what actually happens is closer to this. This means that not only the first vector is reduced by the SVP oracle, but actually these modern solvers, they reduce the entire head of the basis. So the left-basis vectors and anonymously for the dual SVP reduction. And in the aforementioned work of Eurocrypt 19, this observation was used to skip certain computations because the blocks are overlapping there. You can skip certain calls to the oracle. This is not really applicable for SVP reduction because the blocks are disjoint. So we can't really take advantage in the same way. And this disjointness of the block is actually a nice feature, right? Because we said that this allows SVP reduction to be paralyzed and distributed very easily. So we could try to take advantage of this observation in some other way. So consider again the shape of the basis after applying the SVP oracle to all these primary blocks. So what the shape actually looks like is something like this. If we take into account our updated model of what happens after SVP reduction. And so now the natural idea here is to shift the dual blocks by more than one vector. We're going to apply the dual SVP reduction by blocks shifted by a number of indices that is larger than one. And the question now is, is that better? Let's have a look at what this looks like in action. So here's an example. Again with the same parameters as before, but with a dual block shifted by 15 instead of 1. And as you can see the algorithm converges much faster. Now if you look closely and pay attention very closely, you might have noticed that the red line is now a little bit higher than the one before. So what this means is that it looks like we have another trade-off here between the output quality and the running time of the algorithm. And the question now is, can we analyze this to check if it's actually worthwhile? And so this is a core technical contribution of this of this work. So first I want to observe the idea of using these larger overlaps is not entirely new. Actually in a work by Lee and Graham in 2014 they introduced an algorithm called block rank and reduction, which considers a slightly different problem and also uses a different oracle. But structurally this algorithm is very similar to what we are considering here. And we may exploit the similarity to reuse their results on the number of oracle calls. So they approved the bound on the number of oracle calls which also holds for our setting here. So let's see what they approved actually. So if we consider the dimension of letters and denote by n, and we're going to denote the block size by d and the overlap parameter by k, the bound that they approved on the number of oracle calls that the algorithm does before convergence is n to the 3 over d squared roughly. Now their goal was to show that it is polynomial, which is clearly is. So they were fine with this. But for our setting it is unfortunate that this bound is independent of k. It's this overlap parameter because this prevents us from analyzing the tradeoff between the running time and the upper quality. The reason why they don't have k in their in their bound is because they're using an analysis technique that is two cores. And so what we do is we apply the dynamical systems analysis which you can view as a more fine grained version of the analysis they applied. And the bound that we show through this analysis looks like this. And here you will notice that for k equals 1 the bound effectively coincides. Now we also improve this bound with respect to some other parameters, but we're going to ignore this for here. But what I want you to focus on is that with increasing k our bound actually decreases. And for k being linear in d we actually get a factor d improvement in the bound. And this gives us our first set of results which is an improved running time bound for block rank reduction. Now we can also analyze the output quality of our algorithm relatively easily. Unfortunately there is no nice formula that I could put here in slides that would give you an intuition of what this tradeoff looks like, but we can evaluate it numerically. And so what we can do now is we can compare the tradeoffs that we gained by tweaking the parameter k with the tradeoff we get by fixing k and only considering the block size. And we do so by using a crude model for the running time of the SVP solver and we do so on an example. And in this example with a 270 dimensional basis with block size 90, this shows that by tweaking the parameter k we can get a speed up of factor 4 over the tradeoff purely achievable by tweaking the block size. In order to check if our analysis actually holds up also in practice we implemented the algorithm and we ran a set of experiments. And here we see the results of one set of experiments. So the y-axis describes the length of the first vector in the basis. So it's the measure of the output quality and on the x-axis we have the running time. So each of these curves shows how the length of the first vector in the basis develops over time during the execution of the algorithm. And we see indeed that for parameters k that allow the other one the algorithm actually converges faster. So this seems to support our analysis. And then also we wanted to compare this algorithm to state of the art. Let us reduction algorithms. And here our algorithm is the HKZ slide algorithm. It's a solid line where we chose an overlap 10 because it seemed to perform best in the previous experiments. And then we compare it to several other algorithms and we see that while it's not clearly outperforming them yet it is clearly competitive. And we believe that there's some room of improvement here because this was just like sort of a prototype for implementation where I think you can tweak the parameters a bit more to probably get some more performance out of them. And also we have not considered so far as a problem of progressiveness which means that for other reduction algorithms it is a good idea to improve the basis bit by bit using increasingly aggressive parameters. This is what's denoted here by progressive PKZ. We have not yet found a good way to apply this approach to our algorithm yet. But we believe this should be possible. And if this is possible this should give a faster algorithm. And also recall that our algorithm is easily distributed and paralyzed. This is not necessarily true for the competition. And so with this I want to conclude this talk and thank you for your attention.