 So, hi. I'm Seth Hiroshima, and I'm going to be presenting some joint work I've done with Will and Tom on how to construct triple block ciphers with beyond-birthday bound security guarantees. So, triple block ciphers are a symmetric key primitive that were initially proposed in a paper by Liskover Vessen Weigner in The idea here is that they're very similar to a regular block cipher, but we have this extra input, the tweak, and each time we change the tweak, we get a brand new permutation. The idea here is that the tweak provides built-in support for variability, which block cipher-based constructions usually obtain through ad hoc means. And this built-in variability makes triple block ciphers sort of a very natural starting point for designing symmetric key constructions. In practice, TBCs have been used for a wide variety of things. This includes authentication, authenticated encryption. An example here is Rogways, OCB, MACS, and PRS, PMAC, and PMAC cluster examples of this. The skein hash function, which was one of the SHA-3 contenders, is built using a triple block cipher. And a recent paper by Minomatsu and Iwata give a block cipher domain extension construction that uses triple block ciphers. Various other constructions can also be viewed as being built from a triple block cipher, even if they're not cast this way explicitly by the authors. Examples here include even cipher block chaining EME, EME star, which are again domain extension. So here's the formal security experiment for a strong tweakable pseudo-random permutation. The experiment is very similar to the PRP setup. We have this adversary who has black box access to some oracle. In this case, the oracle takes two inputs rather than one, the tweak and the block input. And the adversary is trying to distinguish between two possible worlds. In the first world, his oracle is the triple block cipher that we're considering that uses some random key K. In the second world, world zero, his oracle instead instantiates an ideal cipher, or a random block cipher that uses the tweak as its key. So put differently, each time the adversary changes the tweak in world zero, he gets a uniformly random permutation that's independent of the others. Note that unlike the key, which also parameterizes the permutation, the tweak is explicitly under the adversary's control. So the adversary uses his oracle, he tries to guess which world he's in. If he can't do so with any reasonable probability, then the triple block cipher is secure as a strong tweakable pseudo-random permutation. Now, how would you go about building a triple block cipher? Well, here's a very naive first attempt. Okay, so let's just take the tweak. Let's assume it has the same length as the block cipher input and export the two together. So the problem here is that it's very easy for the adversary to tell that this is not an ideal cipher. There's an obvious relationship between different tweaks that the adversary can exploit. So here's the first attempt at patching this. What if we also explore the tweak and at the end? Again, this fails. It doesn't get us anywhere. The relationship between two different tweaks is pretty easy to derive as shown there. So the problem here really is that the adversary has too much control over what goes into the block cipher, and he can easily reproduce the value that comes out of it. We can solve both of those problems simultaneously by putting the tweak through a hash function. And this gives us the construction that Liskoverves and Weiner proposed. We call it LRW2 because it's the second one they proposed. I don't think they gave a name for it. And this gives us birthday bound security in terms of being a strong TPRP under the assumption that the block cipher E is likewise secure and that H is an epsilon almost 6th universal hash function. The birthday bound is tight in the sense that you can find attacks, distinguishing attacks that succeed with high probability using about a square root of 2DN queries. Minamatsu's construction, Tweet-dependent rekeying, gives us beyond birthday bound security guarantees, which is wonderful. So it works by putting the tweak through a block cipher, which we think of as being a PRF, and using the output is a key that we use to process the block. So it's awesome that we get birthday bound security here, but unfortunately there are a couple limitations. First and I think most significantly, the tweak must be much shorter than half the width of the block cipher. This restriction prevents us from using this construction in various modes of operation where we might want to change values through the tweak or use a tweak to ensure some sort of domain separation. Additionally, this construction requires us to change the key we're using every time we change the tweak. This incurs some speed penalty and it's not what block cipher typically designed to handle. So our design goals were to find a construction that gives us beyond birthday bound security guarantees while permitting arbitrarily length tweaks and also avoiding the need to rekey the underlying components. Here's what we came up with. Chained LRW2 is essentially two rounds of LRW2. We use the same tweak for both rounds. So we'll prove, I'll sketch the outline, that this does indeed give us beyond the birthday bound security guarantees. It uses standard primitives, in this case box ciphers and hash functions. And we don't need to rekey anything. And we have arbitrarily wide tweaks restricted only by the domain of the hash function we construct, which is in practice not really a problem. We actually didn't go into this trying to analyze what happens if we use two rounds of LRW2. We found some construction that work and tried to optimize it as much as we could and then a couple weeks later Tom said, hey, this is two rounds of LRW2. So that made it easy to name at any rate. Here's our main result. If Chained LRW2 is defined as above, then we get the following security bound. The tilde over the SPRP indicates that it's tweakable SPRP that we're considering here. So we have a reduction to the security of the block cipher E plus some other term. For practical values of E hat that we can easily achieve, this second term is roughly equal to Q cubed over 2 to the 2n. So that means that we have security tow around 2 to the 2n over 3 queries rather than the birthday bound. And here's a graph that shows this visually. So assuming that we have a secure 128 bit block cipher, Chained LRW2 is secure. We lose security guarantees only after around 2 to the 85 queries, whereas constructions that give us birthday bound security break around to the 64. If you're interested in whether and when these bounds exceed some given constant like to the minus 40 rather than when they become completely vacuous, the gap between these two curves grows even further. So now let's talk about the intuition behind the construction and its proof. So here's our starting point. The LRW2 frugal block cipher. So we made the obvious first step in the proof of replacing the block cipher with this random permutation pi. And as is very typical in these sorts of proofs, we run into problems when there are collisions. For example, if there are two queries that put the same value on that indicated wire, then lazy sampling techniques give us no new randomness that we can exploit on the second such query. And as a result, these type of constructions behave very similarly to an ideal cipher until there's some sort of internal collision. This presents a pretty significant problem when you're trying to get beyond the birthday bound because triple block ciphers are inherently a many to one function. And so in that sense, these internal collisions are inevitable. However, our intuition here is that maybe if we can show that a construction can behave very similarly to an ideal cipher, unless there are two independent collisions on the same query, then that should give us beyond the birthday bound security guarantees. And so that's what motivates this structure. The problem, of course, is showing that this is indeed what happens. Our analysis breaks us down into two cases. So we say, okay, first let's look at what happens if there's a collision at that first point. It's pretty easy to show using standard techniques that unless there's also a collision at the second point, our distribution on outputs looks very close to what we wanted. So there's no problem there. The more interesting case is when there is no collision at the first block cipher, and we want to show that we can withstand a collision at the second point. So in this case, we have some distribution on the possible outputs that's given by the blue curve, the CLRW2 distribution on outputs. And we want to show that that's very similar to the distribution we would get from an ideal cipher shown here with a dotted purple line. And you can break down the outputs into these four sets that make it very easy to analyze the distributions involved. And indeed, these curves are very close to each other. The statistical difference between the two distributions ends up being proportional to the size of the set S3, which basically corresponds to the set of outputs that are impossible to return, given that there is no first round collision. Most of our analysis then is showing that the size of this set S3 remains essentially negligibly small, even against adaptive adversaries. So I haven't seen this construction. There are some, I think, natural questions to ask. One of the first is, can we reduce a number of keys? So here we're using four keys, two for the hash functions, two for the block ciphers. And that seems maybe a bit cumbersome. So I don't know of any attacks that using the same block cipher key toys, for example, would allow. That being said, I also can't prove that no such attacks exist. Trying to make this modification to the proof would require very non-trivial changes to its already rather long technical proof. The second question is, okay, so one round of LRW2 gives us birthday bound security. We get two to the two N over three queries if we use two rounds. So what if we use three or even four rounds? And using pattern matching, the conjecture here is that if we have R rounds, then perhaps we can get security two rounds into the RN over R plus one queries. Again, I don't have a proof for this, but I suspect that this is indeed the case. Finally, is this construction overkill? Can we simplify this by, say, removing some of these X-Ware operations? The answer to this question is no. If you remove any one of these X-Wares, I can give you a birthday attack. And so in that sense, this construction is optimal. So, chained LRW2 is our main result. We have some others. Let's look at one of them. In the Tweetville blocks I have for paper, Liscofer, Vessen, Wagner proposed TBC MAC, the construction shown here. It's essentially the same thing as CBC MAC except the chaining value goes through the Tweet. In fact, you can view CBC MAC as a particular instantiation of this construction. So we did the security analysis and it turns out that you only get birthday bound type security. And this is disappointing. Tweetville block cifers are much more powerful permitive than regular block cifers. We have a whole set of random permutations rather than just one. So surely we should be able to get better than the birthday bound. And in fact, we can. Our strategy here is to take advantage of the fact that we can use wide tweaks to get domain separation. So this construction is TBC MAC 2. We're very creative with our names here. We chain through the tweak, but we extend the tweak to allow domain separation. So we have this middle zero that gets changed to a one for the last block. So that means that there's domain separation within a query. And the fact that we have this nonce N means there's additional domain separation between different queries. And so there are two sort of cool things about this. The first is that we get a tight reduction to the security bound for the underlying Tweetville block cifers. So if we use CLRW2, we have PRF with beyond birthday bound security guarantees. Secondly, this construction is very resistant to nonce misuse. The worst case scenario where the nonce is a constant, we recover birthday bound security. The security, the degradation between these two extremes is smooth in that in general the second term is quadratic and the maximum number of times the nonce is repeated. So this construction is very robust against implementation errors for so on by programmers, which is a pretty nice feature to have. All right, so thank you for your attention. I hope you're able to use these constructions to build fun things. Thank you very much.