 We'll get this right eventually. The final talk is reverse cycle walking and it's applications by Sarah Melakul, Scott Yerek. Very excited. All right, can you hear me? Yes, all right. I'm not sure I still have this right, but. All right, that is not my slides. All right, I'm gonna go ahead and get started here. We'll see if I can figure out the technology. Okay, so I'm gonna talk about the following problem. All right, suppose you're given a block cipher on a set T and you have a smaller set S, which is a subset of T and our goal is to use our block cipher on our set T to find a block cipher on our smaller set S. All right, I'm gonna give you a new algorithm to do this and I'm gonna start off by telling you a story to motivate this problem. Then I'll give you the new algorithm or I'll give you a little bit of background on the problem and existing solutions. I'll tell you about our new algorithm and then I'm gonna end by giving you a few proof details but there won't be too many of them. So I'll go through that pretty quickly. All right, and this is joint work with Scott Yelik. Fashion day? Okay, so this is motivated by the application or the by format preserving encryption. So here's the setup. Suppose you have an existing database that stores some sort of information. So for example, maybe you have an existing database with millions of US social security numbers already set up there, right? So your customers have applications, there's hardware, software involved, it's already set up. And you come back later and decide, hey, we wanna add encryption to this database. So how are you gonna do this? And this data that you have has some special conditions. So for example, for social security numbers, these are nine digit numbers and there's some restrictions. For example, the first three digits can't be 666 and there are all kinds of other restrictions associated with this data. Okay, so how are you going to do this? Well, one basic first pass idea is we could represent these social security numbers as 30 bit numbers, pad with some extra zeros and then encrypt using just standard block cipher. But in some cases, this doesn't work because the encrypted numbers have a significantly different format, could have a significantly different format from the original format. And this can cause all sorts of problems with your application, hardware, software, et cetera that you don't want to have to fix. So the idea is that we wanna generate ciphertext that have the same format as the original data. So these are actually valid social security numbers. They don't start with 666, et cetera. All right, so that's our goal. So let me go ahead and tell you a little bit about the background and what we know so far and then I'll tell you about our new algorithm. Okay, so in many settings, we already have solutions that can do this. So for example, if you're set S, our bit strings or integers up to nine, there's lots of work showing how to solve the problem in these cases. Also, if your target set S has an efficient way to rank or unrank the elements in your set, then you can simply use this algorithm and then a cipher on the set of integers from zero up to the size of your set minus one. So we're looking at the situation where basically all we know how to do is test membership in the set S. So we know how to find whether something is in the set S or not, but that's just about it. Okay, so here's the general approach to this problem. Is again, we find a cipher on some larger set T which contains our set as a subset. Then we transform it into a cipher on our smaller set S and this is the problem I started with at the very beginning. So for example, in the social security setting, we can use the larger set S, let that be the set of 30 bit strings. We have many ways to encypher this and then we need to tackle the second step, right? So how do we take the cipher on the set T and get a cipher on the smaller set? And one of the kind of canonical ways to do this is called cycle walking and the idea is that if you have a point in your smaller set S, you evaluate the permutation on your larger set and you check, okay, did I get a point that happens to be an S, right? Because we can test membership in S and if you get a point in S, great, you're done. If you get a point in T, well, you do it again, okay? And if now you get a point in S, again, you're done. If it's a point in T, you keep going and basically you do this until you hit a point in S and you're always going to eventually hit a point in S because maybe you'll come all the way back around to the point itself but you'll get there eventually. Okay, so we're gonna take a look at this algorithm from the cycle structure perspective because it will be useful when I introduce our new algorithm but essentially if you look at your permutation on T and the cycle structure, the effect of cycle walking is simply to cross out all the elements in S or sorry, all the elements that aren't in S and we're left with a permutation on S. Okay, pretty straightforward so far, hopefully. All right, so cycle walking was formally analyzed by Black and Rogaway in 2002 and they showed, well as you can see, there's running time of this algorithm has expected running time of constant time assuming that the size of S is as small is a constant fraction of T but in the worst case it's not so great because in order to evaluate a single point in S we might have to go through basically every single point in the worst case every single point that's in T but not in S before we find a point in S. Okay, in addition, this algorithm can take different times depending on the permutation and depending on the point so it's possible that maybe the fact that we have different running times can leak some sort of information. Now, Blair, Rustin, Rogaway and Steakers did show that in a certain setting this doesn't actually leak any information and it's not damaging but you can envision that maybe there's a setting where this could cause problems. Okay, so the question, our algorithm or what we looked at was can we do better? So can we improve this worst case running time and can we come up with an algorithm that doesn't leak any timing information? All right, so finally our algorithm. Okay, so let's consider the cycle structure. We know one idea you might have is can we somehow cut this algorithm off early? Can we somehow, if we're in that worst case situation can we cut it off early and maybe just accept some sort of error? But it's not clear how to do this with cycle walking because we still need to end up with an actual permutation. Somehow we have to get a point in S. So here's the idea. So we're gonna go ahead and take our point that we wanna evaluate and we're gonna evaluate our permutation in T and if we get a point in S then again we're gonna stop just like we did in cycle walking. But if instead we get a point that's not in S, a point in T, so for example, if we're trying to find out what two gets mapped to then instead of continuing on we're actually gonna go backwards instead. Okay, so we're gonna go backwards until we hit a point that's not in S. And essentially what this is going to do, the effect it's gonna have on the cycle structure is again we're getting rid of all the points that aren't in S, but now we're only looking at contiguous points in S. Okay, so we're only looking at contiguous points in S. So this single cycle here in our original permutation is gonna get broken up into two different cycles which are the contiguous points in S. Okay, so if you're following me so far you're probably thinking to yourself, wait a second, this hasn't actually improved the worst case running time too much, right? Because in the worst case we still might have to go through every point in S and if S is a constant fraction of T then, all right, this is not very satisfying. Okay, I mean it's a smaller constant fraction but okay, so here's the further idea and that is that we're just gonna look at two cycles. Okay, so we're gonna look at these contiguous points in S and if they're more than two points we're just going to get rid of them, all right? So we're only gonna look at two cycles and so we're gonna be left with essentially a matching at that point. Okay, so just to give you another example, again we're eliminating all the points that aren't in S and then we're only looking at the contiguous points and any cycle that's longer than two we're just gonna get rid of and we're gonna map all those points to themselves. Okay, so here are the formal details of the algorithm. It's not as complex as it looks but we've added an extra bit flip so in addition those points that get mapped to something besides themselves, we're gonna flip a bit and if that bit flips one way we're gonna use that pair, if not we're just gonna map those points to themselves and this actually happens to be useful when we get to the proof which we probably won't run into too much detail today but the big thing to note is that you only have to evaluate the permutation on three different points in the worst case. So in the worst case it takes constant time. Okay so one, in every case it takes constant time. So one step takes constant time, that's great but even if the permutation on T is random this new permutation that we've generated is certainly not random, right? And you can pretty easily see that in that a lot of points are gonna get mapped to themselves. So this isn't random, it's not even a random matching or I mean it's not a uniformly random matching. So the question becomes, okay so it's not random but if we do it enough times it is random. So now we ask the question how many times do we have to repeat this process before we get a permutation that's close to random and at this point this is essentially a Markov chain and we can use techniques from the Markov chain community to answer this question of how many times do we have to apply the algorithm and we're really hoping it's less than the size of S to get an improvement on this algorithm. And it turns out the answer is logarithmic in the size of T. So this is gonna get us an improvement in the running time. Okay, so what are the advantages of this algorithm? So we have an improvement in the worst case running time from O of, alright so now I'm switching to Markov chain community. So N is the size of T, here so we go from linear to logarithmic and this is the worst case. We have no leaked timing information here so everything is gonna take the same amount of time to evaluate. In addition we can now trade off security in running time so you can choose okay maybe I don't wanna do the full log N steps I can make a trade off depending on how secure or how random I need my permutation to be. In addition we're gonna have some other benefits like increasing the level of security and the reason we get some of these and I won't go into too much detail on it is that essentially we only need to evaluate the points in S, we don't need to evaluate the entire permutation in the worst case. Okay, alright so I'm gonna talk to you a little bit about some of these proof details but not too much detail. Okay so this question of how many times do we need to apply the algorithm before it's close to random is essentially the question of what's the mixing time of this Markov chain. So I have it defined formally here but essentially we're looking at how long do we have to go before the variation distance is less than some epsilon. Okay so in order to bound the mixing time we're gonna show that our algorithm leads yields what's called a matching exchange process and a matching I'll tell you what that is in a second but essentially it was defined and analyzed by Sumaj and Kulowski in 2000. And we're able to use a lot of the same techniques that they did to come up with a bound on the running time of our algorithm. And we do do some modifications and we dig into their proof and we give some explicit bounds. So they give a big O bound but no constants and we re-prove several of the key lemmas in the context of our setting. So they prove more general bound in a more general setting. Okay so we do some customizations for our algorithm. So I'm gonna start off telling you what the matching exchange process is and then I'll dig in a little bit into the details. Okay so a matching exchange process works as follows. You begin by choosing a number kappa according to some distribution. Then you pick a matching of size kappa uniformly at random and then for each pair in the matching you're gonna transpose the two points with probability a half and otherwise do nothing and this is where that bit flip in our algorithm comes in to play. So it's pretty straightforward to see that our algorithm is a matching exchange process although we're not generating the matchings uniformly at random. A matching of a certain, if we look at all the matchings of a certain size those all have the same probability. Okay and their theorem says that as long as the expected value of kappa is O of N then a matching exchange process mixes in time O of log N. Okay so in order to analyze the mixing time of this process your first pass approach might be to use the technique of path coupling which is a fairly standard approach in the Markov chain community and essentially what you do is you take a look in our setting you're gonna take a look at two permutations and we're thinking about these now as permutations on S that differ by a single transposition so a transposition of a single pair of points and then we're gonna take, we're gonna simulate our process on those two different permutations and the time that it takes until our process meets gives us a bound on the mixing time. Okay so when we apply this in our setting and we consider two configurations that differ by a single transposition and if the first matching that we get at the first step if it contains this specific pair then we can essentially use this matching for one of our processes or use this pair for one of our processes and not use it for the other one and the two permutations will meet after a single step. If it doesn't contain this pair there's not a lot we can do and the problem is that this pair only comes up with probability one over N. Okay so this isn't gonna work because this will give us a bound of N log N which really hasn't helped us at all, it just got worse. Okay so what they do in the case of the matching exchange process to get a better bound here's the high level approach. Instead of looking at what happens to this process over a single step they look at what happens over log N steps. Okay so they look at it over a longer period of time using a technique that's called delayed path coupling. In addition they're gonna use what's called a non-Marcovian coupling so they're gonna use some information about what happens in the later steps to choose some of these matchings for the two processes. Okay so I'm just gonna get again I'm gonna do this fairly quickly to give you a high level idea of how this works. Okay so again we have these two processes that we're trying to simulate they start by differing by a single transposition and we wanna see how long it takes before they couple and we're looking over log N steps. And one of the requirements is that if we look at a single one of these processes it needs to look like our algorithm right? So if we just look at that one in isolation it has to look like our algorithm but we can do things to help them along as long as they again if you just look at one it looks like the process. Okay so for one of our processes we're just gonna choose the matchings like we would with the algorithm straight off, all right? But we're gonna be selective in how we choose the matchings for the second process. So here's the idea. Again since these two processes start by differing by a single transposition if we get that particular transposition we're good, right? We're golden. If we happen to get that particular transposition. But that doesn't occur that's not very likely to occur, right? That's our problem. Well what is likely to occur is that our two points U and V get matched with other points, right? So maybe U gets matched with Z and V gets matched with W and this is likely to occur. And so what we can do is then, and we could choose these two matchings so that after one step they differ by the UV transposition but we can also choose the matching so that after one step they differ by this ZW transposition, okay? And if in the next step after that we happen to get either of these two transpositions the UV or the ZW then we can fix everything. And essentially the key important fact is that now the number of transpositions that fix our problem now there's twice as many after one step. And essentially we can show that after two steps there are four times as many and they double. And so we can take a look and because these transpositions are doubling we end up showing that after log in steps we're gonna have enough so that we're highly likely to hit one of these good pairs after that many steps. So that was pretty much all the detail I wanna give you about that, but okay. All right, so we're gonna call these good pairs and essentially the parts that we prove is we're gonna show that after log in steps with high probability we're gonna have a linear number of these good pairs and thus after, then we can show that with high probability one of the next log in matchings is gonna contain one of these good pairs and that's the part that we end up refroving. Okay, so in terms of future directions it's, you know, there's obviously things we can do to improve the algorithm. We don't think that this bit flip is necessary it's really just a, it's, you know it makes the proof go through but I don't think it actually improves the algorithm. But you know I think the more important one is that this expected constant running time that you get with cycle walking is very attractive, right? And we certainly don't achieve that, right? It's gonna take us logarithmic time every time so it's consistent and it has a better worst case running time but it'd be nice to go back to that constant time that looks very nice, right? Okay, that's it, any questions? Any questions on the comments? So I was trying to go through a mental calculation on particular concrete numbers and something seems to be wrong. Maybe I misunderstood your algorithm but you get the example of T being two to the 30 and let's look at S which is two to the 20. So one in a thousand numbers are good numbers, good values. So if you are looking at a random permutation the chance that a given good point is followed by another good point is only one in two to the 10, one in a thousand. So almost all the numbers are going to be single tons in your construction. Let me continue. So the probability that you are going to have a pair or larger cycle is going to be smaller than one in a thousand due to the addition that you mentioned. Now you are repeating the whole thing only 30 times and in 30 times with this probability of one in a thousand almost always the single tone will be mapped to itself in the first application, second application up to the 30th application. So with very high probability still every point will be mapped to itself in your example. You somehow don't consider at all the ratio between S and T. You just do the number of iterations to be log T regardless of how small S is within the range. Yeah, so I've hidden a little of those details from you. You're perfectly correct. So the numbers that I give you assume that S is a constant fraction of T. Then it will work. When you look at the theorems in the paper everything is in, right that ratio of the size of S to the size of T is critical and that shows up in every theorem because it affects. But you didn't say this is a crucial element. This parameter or the size of T, the size of S. Yeah, so we assume it's a constant fraction. A question? Thanks for the talk. I had a question about whether you could generalize this argument so it looks like right now you're sort of pairing up elements and then swapping or not. Could you take triples of elements or quadruples and permute them? Does that still work? Does the proof not work? What happens? Yeah, so that's a great question. I mean we, that was our original idea because I mean ideally right if you have, if you allow longer cycles it should take fewer steps before it gets to be random right because it's closer to what the original permutation looks like. But we haven't gotten the proof to work out. So presumably there's some trade off right? If you allow longer cycles you wouldn't have to go as many steps but we don't have a theorem that's general in that case but you should be able to get that. If you go a little bit further and you attempt to find another good point. Yeah, the proof also. I mean you can do it and it, I mean clearly it should be faster but how much faster is, we're not sure. As a question? Moment. Okay, let's thank Sarah and all speakers again.