 Thank you. Thank you for that. So this is a Talk on depth or bus graphs and their cumulative memory complexity and this is joint work with Jeremiah blocky and Chisholm Piatrzak So I'm going to sort of set the scene a little bit and that goes as well for this talk and for the next talk so I'm going to tell you a little bit about a complexity notion and and and how it's motivated and this starts with the story of moderately hard functions so moderately hard functions you can think of these functions from bit strings to bit strings are computable by an honest party in reasonable time and space sequentially and When and brute force evaluation should be very expensive for an adversary so Why would you want such a thing? Well sort of the meta application is to limit the rate of invocations for some critical functions In particular you think about password based cryptography the critical function that we want to That we want to limit the rate of evaluation is guessing a password So for example on a password server, you don't store the password You store the output of a moderately hard function evaluated on the password that way when someone breaks in they steal these hashes Every time they want to guess they want to do an offline dictionary attack They want to guess a new password They first have to evaluate another instance of the moderately hard function Another example where you want this sort of rate limit on evaluating functions is proofs of work For example the distributed proof of work underlying most cryptocurrencies Also when in fact this was probably one of the earliest examples of moderately hard functions when combating spam and Also civil attacks so these are all examples where there's some critical function and you try and rate Limit the rate that an adversary can evaluate these functions or cause these functions to be evaluated in the case of combating spam So why why would you want memory hardness? Well in order for this notion of moderate hardness well in order to see that It's instructive to look at what happens in practice when people try and brute force evaluate these sort of critical functions so Really what ends up happening in a lot of cases that people build custom hardware to evaluate these functions and in particular ASICs so application specific integrated circuits and this is what's happening in the Bitcoin mining community community It happened with the desk cracker Also some really high-end password cracking machines and really it always ends up converging on ASICs And the reason is that for the for a lot of types of computation ASICs provide a financial incentive and what? What that boils down to is that? ASICs Like they give you much more computation in terms of rate of computation per unit per dollar spent So compared to a general-purpose CPU and sometimes on the order of like 10,000 times more And this is something that that's not good for us We want something that's more egalitarian so that that has less of a gap between the rate of computation for an adversary Versus the rate of computation for an honest user on a general-purpose CPU so we want something that's more egalitarian and We want a notion of complexity that approximates the rate of computation on an ASIC in a way that's closer to actual financial costs and In the VLSI community people have been looking at notions of efficiency for a while for circuits and a very common one is Area time so AT complexity so you look at a circuit you look at the area of the circuit and the time it takes for the circuit to output a value and an observation made by Percival is that for ASICs actually really expensive components on these ASICs on the memory and This is actually what balances when you look at just memory. This balances more General-purpose computing and ASICs because high-speed memory is very expensive for ASICs So we approximate we'd like to approximate area time by space time So this is for example what motivated the development of s-crypt, which is going to be talked about in the next talk So recapping basically what we want from our memory hard functions It's a memory hard function is a function with a hardness parameter n that can be computed in sequential time in time n Right, this is what the honest guy is going to do We don't want to assume he's got any kind of parallelism like an ASIC But on the other hand it requires as much parallel space time as Possible for any function that satisfies this first property So we kind of want to for any function that can be computed in n sequential time We want to maximize the parallel space time required to compute that function so memory hard functions They've been around now for a couple years and they've essentially you can view almost all Constructions that exist in the literature as a mode of operation over a round function and almost always this round function is actually compression function and So we're gonna it's useful to think about it this way to abstract it that way because really the memory hardness property Generally comes out of the mode of operation It's as long as you you know you module model your compression function as an ideal Compression function and then you analyze the mode of operation and that's also the the strategy will take in this work and We can we can categorize the constructions into two two broad groups and it depends on Whether the memory axis pattern of the honest algorithm that evaluates this MHF has Depends on the input or not So if the memory axis pattern does not depend on the input then we're speaking of data Independent memory hard functions or IMA chefs and if it does depend then data dependent So the advantage of IMA chefs here is that you it's much easier to implement them Without having without opening yourself up to cache timing attacks And if you think about the the use case of password-based cryptography This takes on a special importance because the input is the password So you really don't want to be leaking anything about that input if if you can so that's why IMA chefs sort of given given a choice You know IMA chefs are better all things being equal Although as you'll see all things are not equal and that's why we're still interested in DMHF's as well But this talk will focus on IMA chefs So there's been a lot of constructions and in particular in the context of the password hashing competition which is Recently ended many of the entrants claimed some form of memory hardness in particular the winner winner are gone to I several of the finalists And other contestants as well since then there's been a few other constructions notably balloon hashing and Recent theoretical construction as well Most of these constructions almost all of them really have been designed based on intuition and then Analyzed using crypt analytic techniques. So basically people with the constructions out there, and then everybody tried to break them There are a few exceptions to this approach notably katana balloon hashing and the recent as 15 construction in particular balloon hashing Actually has a security proof in sequential random oracle model And as 15 goes all the way to the parallel random oracle model for us Parallelism is important here because remember our adversarial real-world model are asics and asics are parallel devices You could have many instances of your compression function on the ASIC that you can evaluate in parallel so Trying to nail down a little more precisely. What is the right complexity notion here? We said that we're really interested in ST space-time complexity But we're also looking at adversaries that are parallel adversaries and there's a bit of a problem and and on top of that These adversaries they're actually brute force evaluating these functions, right? They're evaluating many many copies concurrently and there's a bit of a problem with how ST plays with parallelism and amortization So imagine to see to see what the issue is imagine you have a function Or a computation specific computation of a function that looks like this has the following memory profile at the beginning of the computation There's a spike in memory and then there's a long tail where you don't need a lot of memory But you just need a lot of time you just sequential time basically So this function would have suppose every every way to compute this function has this you know has this property This function has high ST complexity, right? Because you got the high s and you got a long t the problem with this is that When you're doing amortization over many instances and you can do things in parallel You can start to do things like this when the moment you finish the first instance like the input the blue input You freed up all your memory while you're doing this long tail So you can start the next input the green input and once you finish that spike you can start the next in but the orange one And you can because you can do things in parallel you can do all these computations in parallel The point is you really haven't increased your space time complexity by very much and in fact This can be quite extreme. So in a 15 there was an example of a function which was again a mode of operation on n calls to a compression function and The ST complexity of copy of computing this function square root n times was really not much more than computing it once So the point is ST complexity is it's good for one-off computation for understanding one-off computation But it's not useful or it's not it's not a very good notion when you want to do amortized complexity for parallel computation so we need something else and Maybe the natural thing to do so ST complexity you can think of it like this There's again in a computation at the space the space curve over time ST complexity would be the area of the entire box and kind of the natural thing Given the previous argument is to just restrict ourselves to look at the area under the curve So as long as you can't really reuse computation across instances reuse calls to your you know storage and reuse calls to your compression Function you can hope for nice amortization So the the the complexity should scale linearly essentially in the number of instances that you're computing That's really what we want and For that we look at cumulative memory complexity Which is essentially you can think of it as the time the sum of the amount of memory across time that your algorithm is storing So in order to reason about cumulative memory complexity in particularly in the random oracle model a very useful Simplified compute computational model has been developed, which is the parallel pebbling game so this builds on the the black pebbling game from the 70s and Intuitively it models parallel computation So the idea is that this is a this is a computational model over a dag Directed acyclic graph and it involves just putting pebbles on the nodes of graphs of the nodes of the graph and This is done iteratively so one round at a time And the goal of the game is simply to place a pebble on the sink of the graph on the last node of the graph Okay, for simplicity We just think of graphs with one source one sink and there's really only two rules that govern how you can place these pebbles The most important rule is you can only place a pebble on a node V If at the by the end of the previous round all the parent nodes of V already have a pebble on them The second rule is you can remove a pebble whenever you want So just to give you an example just so that this is like quite clear how this works Here's this very simple dag for nodes. Okay, and we're gonna look at how a pebbling would work Okay, in the first step you place a pebble on the sink on the source, right? It has no parents so you can always place pebbles on sources now in the next step We can immediately place the pebble on the children of this sink because both because their parents are already covered And at the same time in the same step we can remove the pebble on the source the Next step we can do the same for the sink and we're done right so that The complexity notion we look at here for this pebbling game mirrors cumulative memory complexity And we call it also similar name cumulative pebbling complexity And it's simply the sum of the number of pebbles on the graph Across the number of steps across the steps. So in that case that pebbling had CPC 4 So you can already see that there's like a strong parallel here between and how you would hope Computation works in the parallel random oracle model and the pebbling game and the so the pebbling game really serves as a way to simplify the analysis of different functions and Armed with this pebbling with this complexity notion for graphs We can you know define the complexity notion for a graph and that's simply the low the minimum pebbling complexity of any Complete and legal pebbling of a given graph right so this is the CPC of a graph and much of this talk is going to be about looking at the CPC and understanding the CPC of different graphs and The reason for that is the following theorem which is From a previous work which basically states you don't really have to parse it too much But what it says is that for a class of functions which would call hash graphs Really the only thing you can do in the parallel random oracle model is essentially pebble the graph you can just compute labels in this hash graph According to a pebbling and that's what this theorem says and so what it means is that we don't have to think about the Parallel random oracle model anymore for this entire class of functions for these Potentially memory hard functions all we have to do is we look at the underlying graph Which describes the mode of operation for these functions and we analyze the properties of the graph namely It's CPC that's all we have to do and so that's what we're going to do in this talk and So given this theorem we really have two goals now on the one hand in terms of attacks on the other one hand in terms of Security proofs for security proofs what we're looking for is a constant in-degree graph With high CPC now the reason for constant in-degree is because we're looking at the mode of operation over compression function and Kind of in the random oracle model the implicit assumption here Is when you want to call your round function your your compression function you really have to have everything in memory in one go That's just how we model things in the random oracle model and in order not to break that we don't want to have too big of inputs So that the random oracle model is still relevant in practice when you replace your random oracle with some hash function Cryptographic hash function so this is why we're looking at constant in-degree graphs Otherwise we'd be done the fully connected DAG so it you know is already gonna have as good CPC as you could ever hope but We need constant in-degree for this to make sense and indeed all constructions are constant in-degree The other thing in terms of attacks that we want is to find low CPC pebbling strategies So previous results on CPC remember there's many constructions I've highlighted some what we know about some of the most important functions in particular argon 2 Was the winner of the password hashing competition so that's important katana was one of the earliest ones and For now we've we up till now. We've mainly known about low about upper bounds So that would be a tax in some sense and the best by the way you can hope for of any function any mode of operation on n calls to Compression function is for CPC of n squared. That's the best you could ever hope for and that's just doing things sequentially In topological order and remembering everything keeping pebbles everywhere so as we'll see in the next script in the next talk Okay, I won't say too much about that. So the only thing we've we've got in terms of security proofs is for AS-15 this was a very theoretical construction, but we got pretty close. We got polylog asymptotically this looks good The problem is that for practical values of n log to the 10 is like that's like square root n Because that's actually pretty far away from n squared So in this work we developed several new techniques for both attacks and for new security proofs and In particular, we tightened the gap what we know about certain functions in particular argon 2i a and b There's new the new version is argon 2i b. That's the the newest version of argon 2i and Maybe the most interesting in a theoretical sense is that we have an asymptotically Almost optimal construction now So a graph that has as high CPC as you could hope for and the reason they say high C as high as you could hope for is because of This result here which shows that any graph on n nodes. You can't get n squared, right? You can the most you can get is n squared over log n effectively and in this we in this work we construct n squared over log n and the way we do that is by analyzing using a combinatorial property of graphs called depth robustness and what depth robustness is it's the following property given a graph G We say that it's ed depth robust if you can any subset of nodes that you remove of size e So any e nodes that you remove there will remain a path of length d So this is a combinatorial property and what we do is we This is the kind of the main theorem we show the following theorem Which says that if a graph is ed depth robust then the CPC of the graph is greater than e times d So given this theorem really All we need to do is now find a graph that has high CPC and Sorry has high depth robustness and Erdos Graham's Tzemeredi already gave us such a construction So this is using quite an old result. The only problem with that construction is that it didn't have constant in degree so the other thing we do in For this is to show how to reduce the in degree of a graph without paying too much in depth robustness So combining those two results this lemon this theorem we end up with at least theoretically asymptotically optimal construction For a graph with high CPC and therefore an IMHF The other thing we do is well, we do several other things In Particular show some lower bounds for known construction So what that boils down to is looking at the depth robustness of the graphs that underlie those constructions and Also another combinatorial property that we identify which we call dispersal Which also gives you some bounds on the CPC of a graph. We analyze that as well and We also take Pebbling strategy a previous one Which gives you low CPC? Pebblings for certain kinds of graphs and we improve on it by sort of looking at it recursively see if we can apply it recursively And indeed that gives us improved attacks in some sense on some known IMHFs All right, I think that's it time's up for now Questions so I'll start with one The you didn't formulate any statements about Hardness for the adversary that follows from the depth robustness So the hardness for the adversary is Essentially you have that it's high CMC right so that's cumulative memory complexity in the parallel random oracle model That's sort of the hardness notion for the adversary and then there's this result From the past work that shows that if you have a graph that has high CPC You can turn it into an IMHF that has high CMC in the random oracle model And then one of the key theorems we show is that if a graph is very depth or bus then it has high CPC So plugging that chain together you end up with an IMHF that has high CMC For example the adversary has ability to choose its own inputs in main applications. Is it something that your Secrets a statement capture indeed indeed. I've glossed over the fact that cumulative memory complexity We actually we look at the amortized cumulative memory complexity of a function So really the game is in the parallel random oracle model is you allow the adversary to choose How many inputs he wants to evaluate and what the inputs are and then he runs the computation and then you look at the Amortized complexity per in per IO pair that he computes So yeah, I kind of glossed over that but yeah, he it does capture that You've got a question What one sec one sec Will there repeat the question yet? You have an example for why you can't get past that factor four It's it's tight. Okay. Again. That's actually the simplified version of that theorem statement and in reality the quality of the theorem of That reduction Decreases in things like how many random oracle calls does the adversary make what's his probability? So the way it's formulated there is tight for some choice of parameters But not in the general case is a more complicated equation. So Yes, and no basically