 So thank you for the introduction. I'm going to be talking switching gears a little bit. In last talk, we were discussing hash function security in the sense of collision resistance. And now we're going to look at it in terms of a stronger or at least different security property, which is that of indifferentiability, which have getting nicely set up a segue for me. So we'll look at two functions, H squared and H MAC. And I'll talk mostly about H MAC. And we'll see how H squared comes up as a natural target of analysis as we look at H MAC. So H MAC is a hash function construction introduced in 1996 that specifies how to use the black box, the cryptographic hash function, to build a keyed cryptographic hash function. That means a object that takes both a variable length key and a variable length message and maps it down to a n-bit digest. H MAC does this by deriving two subkeys, k in and k out, from the key k, and then hashing the message and the first subkey, and then hashing the result of that prefixed with the second subkey. And then the result is the H MAC of k in. And we'll see some details about the way k and k out are derived, which is very critical to our results in a few moments. So this was originally designed and analyzed for the setting of message authentication with secret keys. But now H MAC is used in a wide variety of settings. So if you're already bored and surfing the web right now, you're using assuredly H MAC in a whole host of ways. And unlike in the original Envision usage where H MAC was designed to use with uniform secret bit strings, now many of these settings use H MAC with keys that are, for example, Divvy Helm and group values, or passwords, or even public values such as nonces that are sent in the clear and adversaries may have access to. So in terms of security for these applications of H MAC, well, when we have a key that is a secret uniform bit string, then we can appeal to some of the well-known results about H MAC being a good pseudo random function. There's also some work showing that in some settings, if you have a high entropy secret input, then H MAC is a good randomist extractor. But these standard model results don't work for all of the applications of H MAC. And in particular, we see that in the literature and implicitly in practice, H MAC is being assumed or modeled as a key random oracle in the sense of Bellari-Rogway 1993. And what this means is that we really think of H MAC as mapping each KM pair to a random and uniformly chosen output. So I won't go into the details about all the results that use this modeling of H MAC, but suffices to say the standard model techniques do not work. And in particular, it's because the key input is being used for nonstandard in a nonstandard way. And really, we have this expectation that this should be OK, that H MAC does really give us somewhat random behavior for any KM input. So this brings us to our main motivating question for this work, which is, does H MAC really live up to these expectations of behaving like a random oracle? And we would at least like to hope that this holds true in a setting where we generously assume that the underlying hash function H is itself perfectly secure, so mapping inputs to random looking outputs. So we can formalize this question using the Indifferentiability framework. I'll give details in a second. And then we have, and this gives us this question, is H MAC indifferentiable from a random oracle? Now, this surface is a simpler and very elegant question, in my opinion, which is the indifferentiability of a related construction, which is H squared, or the hash of hash construction. Now, this was actually suggested in a textbook practical cryptography by Ferguson and Schneier in 2003. And it's basically like H MAC without the keys. Just get rid of all the keys, and you have a hash function applied twice to a message. And this was suggested particularly to avoid extension attacks that plague some prior hash function constructions. So these are our two questions. And we would certainly expect that the answers to these questions are yes. And in particular, we thought, setting out to do this work, that the answers would certainly be yes. First, there's very strong positive intuition that the answers are yes. These constructions were designed to prevent length extension attacks. And so length extension attacks are one of the main ways in which hash functions kind of fail to behave like a random oracle. It almost seems, particularly for the case of H squared, that what we're asking is almost tautological, that we're saying if you take a random oracle and compose it with itself, you get something that behaves like a random oracle. So it seems like it should be true. And indeed, there's been some tangential evidence in the literature suggesting that it was the case. In Cronidol in 2005 proved a related construction. The H squared of M but with some 0 is prepended. It is indifferential from a random oracle. And they somewhat confusingly called this the H-MAC construction, but it's not really H-MAC as we define it in standards. And indeed, in crypto 2010, there was a suggestion that this proof should extend to the real H-MAC and to H squared. Certainly, we shared this intuition that it should be a straightforward application of the techniques to the actual functions. So with all that set up in mind, we actually find that the truth is quite a bit more complicated. And in fact, that the indifferentiality of H-MAC and H squared are surfaced in very interesting technical questions and challenges. The first thing we realize is that in these settings where H-MAC is being used with not just fixed length bit strings that are uniformly chosen in secret, but perhaps arbitrary variable length keys, there's actually weak key pairs in the key space of H-MAC that cause issues. The first type of weak key pair is a colliding key pair. And this obviates indifferentiality and may even have issues elsewhere. The second is ambiguous key pairs, which basically prevent H-MAC from having strict domain separation between the inner and outer application of the hash function. And the H-MAC with ambiguous key pairs basically ends up behaving much like H squared, which by design has no domain separation between the inner and outer applications. And what we find here is some very interesting technical setting where the indifferentiality can be shown, but only with weak concrete security. And I'll explain more about that in a moment. And then finally, we end with a positive message that if you indeed avoid weak key pairs in H-MAC, then everything seems to be OK. And we can prove strong traditional indifferentiality for the construction. So to get towards these results, let me step back a bit and formalize or give a bit more formal treatment of what we mean by indifferentiality. And so this is a framework that was introduced by Maurer Renner Hollenstein in 2004. And then Crone et al. in 2005 popularized it for as a criteria for hash function design that we should have hash functions that behave like random or indifferential from random or equal. So briefly, Indifferentiality from Random Oracle asked that no distinguisher should be able to tell which of two worlds he's interacting with. In the first world, he's given a left oracle, which is the hash construction. And a right oracle, which is the underlying ideal object. And in the ideal world, he's given access to instead a random oracle and a simulator whose job is to use its oracle access to the random oracle to trick the distinguisher into thinking he's in the real world. And we have the usual type of measurement or definition security that if we can give a simulator that's efficient and succeeds at tricking all efficient distinguishers, then we call it indifferential from random oracle. For HMAC, which has keys and messages, this is exactly the same definition except that we allow additionally that the distinguisher, as well as the simulator, queries the random oracle or HMAC on both keys and messages. So particularly this captures what we want, which is keys that are arbitrary choosing, which matches up with the applications. So the benefits of Indifferentiality really stem from a very nice composition theorem that was proven by Maurer, Rennert Holstein, which at a very high level says that if you did have an indifferentiality of a construction like HMAC and you had some applications where one's proven security of protocols that in a setting where you've modeled HMAC as a random oracle, then the composition theorem implies that these applications are actually secure using HMAC as opposed to the random oracle. And what this gives us is a very nice guarantee that the structure of HMAC, or whatever hash function structure you're looking at, doesn't introduce weaknesses into your application. So there are some limitations to Indifferentiality. Last year at Eurocrypt, we had a paper talking about how only single-stage games are applicable. The composition theorem is only applicable to single-stage games, but that's not critical. The games we're looking at here, in fact, are single-stage. And second, concrete security here ends up being very important. So in particular, what will be relevant in our setting is how many queries the simulator must make in order to trick the distinguisher. And normally, we look for indifferential guarantees where the simulator makes the same number of queries as it is queried. But we'll call it weakened differentiability if it has to make many more queries. So let's take a closer look at HMAC now to understand whether we can prove, in general, for arbitrary keys and messages that this behaves like a random miracle. And HMAC is a bit more complicated than one usually thinks about it if you look at textbooks for the Wikipedia article, such as I was doing last night. And what it actually does is it takes the input key and message. And it first checks to see if the key k is of length larger than a parameter d. And this d is the block length of the underlying hash function h. If it is longer, then it first hashes the key down to drive a new key k prime. Otherwise, it just leaves k as it was. It then appends to this value enough zeros to get a d-bit string. And then this d-bit string is exclusive or with a constant string iPad that's also d-bits in length to get k in, and as well as x-word with a constant string opad to get k out, and then hash as we saw before. So we see that in the setting where you have variable length keys, in fact, HMAC doesn't provide an unambiguous encoding of keys in the key scheduling. So in particular, by appending out with just zeros, we get this phenomenon that you can have keys that collide with one another. And so for example, any k1 and k2 that are not equal, but such that HMAC of k1, m is equal to HMAC of k2, m. And so a very simple example of this is just a key k1 and a key k2, which is equal to k1 can aid zero. These are treated the same by HMAC. So this gives a trivial indifference ability distinguisher that just makes two queries to its left oracle. And it may be an issue in some settings in practice where there's variable length keys being used, but we're not aware of any places where vulnerabilities arise. I'll talk more about that in a moment. And perhaps the reason this has never really come up is that most applications do use keys of a fixed length, in which case, as long as H is collision resistant, these cliting key pairs do not arise. So the second type of key pairs that are weak are called ambiguous key pairs. And these arise in the way that domain separation is attempted to be insured in HMAC. And in particular, we can have keys k1 not equal to k2, such that after processing k1 sub n is equal to k2 is about and vice versa. And so for example, k2 equal to k1x or dypadx or dypad is such a pair. And this really means that we get no inner or outer domain separation in applications of H. So before I get into more talking about how ambiguous key pairs arise in differentiability, let me just summarize what we know about HMACs and differentiability. If we allow variable length keys, and in particular cliting key pairs, then you get the design differentiable at all. And ambiguous key pairs will give us that it is at most weakly indifferentiable from a random oracle. Finally, if we avoid such weak key pairs, then we do get nice guarantees. And in the paper, we prove using techniques very much like those in the CDMP05 result to show that, in fact, you get a nice strong traditional guarantee of indifferentiability. So the most technically interesting point in this table is in this middle ground between having no security and having complete security. And this is due to ambiguous key pairs. So as I mentioned, this has to do with the lack of domain separation between the inner and outer applications of the hash function. And it's actually easier to look at this in the context of H squared, which, as I mentioned before, by design has no domain separation between the inner and outer application. And what we see is that this construction has the property that any output of the construction, in fact, is an intermediate value used in the computation of another message in the domain. So in particular, if we let m prime equal to H of m, then we note that H squared of m is, in fact, the intermediate values to compute H squared of m prime. Okay, this sounds like just a very, this is a very basic observation, but it's a disconcerting to someone who's done a lot of work on indifferentiability. Prior constructions particularly seek to avoid such a phenomenon. And in particular, because similar, not exactly this, but similar types of intermediate value leakage have resulted in extension attacks, which are, in fact, exactly what these types of constructions were trying to prevent. So it's not clear exactly what an attacker can do with this property of the hash construction. So we did quite a bit of work to figure that out. And in particular, we're able to give a distinguisher D that can force the simulator to make a large number of queries. So in particular, this distinguisher D is going to make Q sub L queries to its left oracle, Q sub R queries to its right oracle. And it's going to be guaranteed to get an advantage of one minus the number of queries the simulator makes over Q L times Q R. And so what this does is it means that the only way the simulator can be effective is to make a large number of queries. And so we get this sense that it can only be weakly indifferentiable. Now in the paper, we show a matching upper bound for H squared that if you give the simulator or a Q squared queries, you can prove indifferentiability. This is a very technical result and I warn you before you print out the paper, it's like 60 pages of games. So I won't talk about it here more. So HMAC, we have a similar phenomenon, basically the same type of approach. If you have ambiguous key pairs and you can use them, then you can inflate the number of queries the simulator must make. We note that right now we don't have an upper bound that is analogous to the H squared upper bound for HMAC, but we suspect that it is possible to prove. Just gonna be very messy. So you might ask why it doesn't really seem like it should matter much, whether Q squared or Q. I mean, it's just, you know, it's all polynomials or whatever. But in fact, in many settings, this gap can be quite critical. In the paper, we give an example of a setting in which this threshold is sharp. So it's vulnerable using H squared or HMAC even with the underlying component totally secure, but secure instead if you had just used a random oracle by itself. And so this shows a sharp gap between the security of using these constructions and a random oracle. So we're concerned, of course, that there is vulnerabilities in practice about, particularly with HMAC, but it seems fortuitously that most applications avoid weak key pairs naturally. So from my kind of informal analysis of many of these applications, these all seem fine. With settings where you're using variable length keys, colliding key pairs might be an issue, but as far as we're aware, nothing, no actual tools are in danger. But certainly HMAC is used all over the place and it would be good to be aware of weak key pairs moving forward. So just very briefly, we can extend the, all these results extend in the paper to when H is not a random oracle, but an iterative hash function. And of course we know how to fix these two constructions from the point of view of indifferentiability, but of course that would have another host of issues. So I think I'm out of time. So I'll just leave the summary slide up here and be happy to take any quick questions. Thank you very much.