 Welcome to my presentation on the security of the suffix keyed sponge. My name is Bart Menning and this is a joint work with Christoph de Bruyne. The sponge is a very popular way for cryptographic hashing. It's based on a cryptographic permutation of size B bits and the state of size B bits is split into an inner part of size C, the capacity, and an outer part of size R, the rate. And if you have to hash a message of arbitrary size, in this case P, this message is first padded and split into blocks of R bits, which are compressed one at a time into leaves with permutation evaluations. After the last block and the last permutation are done, the squeezing starts. R bits at a time into leaves with permutations until you have sufficiently long digest. And the sponge is very popular. For instance, the SHA-3 hash function is based on the sponge construction. It can be used to construct softs and many lightweight hash functions are based on the sponge construction. And in 2008, Pastori et al. proved that if B is assumed to be an ideal permutation, then the sponge behaves like a random oracle up to around 2 to the C over 2 queries. And the C over 2 basically comes from the birthday paradox on the inner part of the state because if the attacker ever finds a collision in the inner part, this collision can be used to break the construction. You can also use the sponge for keyed applications for constructing a PRF. And the simplest way of doing so is by simply concatenating the key and the plaintext and evaluating the hash function on top of this. This is a construction that's currently known as the outer keyed sponge and it's a secure PRF. Alternatively, you can place the key in the inner part of the state and this is what we currently know as the inner keyed sponge. But at some point we observe that once you do so, the state of the sponge becomes secret and there is no need to maintain an inner part here anymore. So you can just as well do full state absorption and this is what we currently know as full keyed sponge. So the P is padded and split into B bit blocks which are compressed one at a time. And this is a very efficient and popular construction. At the same time, once this state is secret, all subsequent states will be secret. So this means that if we consider this construction in the leaky setting, the attacker can get quite some leakage from the secret state. In detail, if we focus on the leakage resilience of these keyed sponges, we can see that the permutation P is repeatedly evaluated on a secret state and any evaluation of P may thus leak secret information. And this brings us to an important question. Namely, can we minimize the leakage of the keyed sponge? Well, there is a way to do so. One way to do so is by adopting the hashed and MAC design. The hashed and MAC design takes a hash function and simply feeds the plain text to this keyed hash function to get a certain digest. And this digest is then processed by the random function f or the MAC function f on the input of a key and this finally gives the tag. And the construction has some advantages in the leaky setting. The reason is that the hash function is unkeyed so nothing needs to be protected. And note that this hash function could, for instance, be a sponge function. The only function that might leak information is f, which is keyed. And f is only applied to a fixed size input. On the downside, if we want to get K-bit security, you should take a K-bit key, but also should take a hash function with a K2K-bit output. In other words, the function f that must be protected has an input of 2K-bits plus the K-bit key. And that's why we consider a dedicated sponge construction. That's a suffix keyed sponge. And this construction, basically at a high level the name comes from the fact that the key is concatenated to the plain text in the end. But the construction is more general. So we consider a b-bit permutation, p. And we consider a state that's split into an inner part of size c and an outer part of size r. The plain text is padded into r-bit blocks which are compressed one by one into leaves by a permutation. And after the last block is compressed, we compress the key. And the key of size k is compressed into the outer s-bits of the state, s does not need to be equal to r. I'm using some function g. And I will come back to this function g later. It will play an important role. And this gives you a new secret state which we call v. One permutation call is done extra and then the output is truncated to a t-bit tag. T, again, does not need to be equal to r. And SUCKS has several advantages over existing schemes. So if you compare SUCKS to the full keyed sponge, on the downside SUCKS does not have full state absorption. Absorption is only r-bits at a time. On the upside, the side channel leakage is limited. The only functions that could leak in a side channel attack are g and the final evaluation of p. In addition, s and t do not need to be r-bits. They can be larger. They can be arbitrary. Typically, you take them equal to c over 2 and then you take them equal to r-bits. In other words, they are arbitrary. Typically, you take them equal to c over 2 or k-bits because this part can be broken in 2 to the c over 2 evaluations of the permutation. So the security level is c over 2 and you can take s and t equal to the security level. Now if you compare SUCKS to the hashtag MAC design that only has advantages. Most importantly, the keyed function here can be half as large. So typically s equals k and not 2k. So the state here is half as large. On top of that, g does not need to be cryptographically strong. For black-box security a simple xor suffices. In that case only one cryptographic building block is needed, namely b. We analyze the security of the SUCKS keyed sponge in detail and at first we consider a restricted setting to see how we can prove security in the simplest possible way. And in this restricted setting we restrict ourselves to the parameters s and t being smaller or equal than r. And in this setting we prove that if b is a random permutation and if g is 2 to the minus delta uniform the conformity means that if you fix an input and you fix an output the probability that this input goes to the output probability taken over the key k is at most 2 to the minus delta. So if b is a random permutation and g is 2 to the minus delta uniform then we prove security of the SUCKS keyed sponge up to n squared plus n divided by 2 to the c plus n divided by 2 to the delta. And if g would be the xor delta would be equal to k. And the proof kind of relies on the inter-frenchability of the sponge. As a matter of fact it uses the inter-frenchability of the sponge as a black box which can be done because s and t are smaller or equal than r. And now unfortunately for the unrestricted parameter setting where s and t can be larger than r we cannot rely on the inter-frenchability of the sponge so we have to develop a dedicated proof. And before going to this proof I first have to discuss an intermezzo on the multi-collision limit function. So consider the problem of throwing m balls uniformly random into 2 to the r bins. Then we define new rcm as the smallest value x such that the probability that the size of the fullest bin is more than x is at most x over 2 to the c. I must admit this definition is quite gibberish but let me explain it. So this definition comes from a work of Dama et al. Asia Crypt 2017 on the analysis of the full-keyed duplex. So it's really sponge-oriented this definition and this is also why we get the 2 to the c here. And in a typical sponge proof we always have a term of the form n divided by 2 to the c where n is the total complexity or n squared divided by 2 to the c. That's what we've seen in the previous slide. And from this respect x is typically a small value so x divided by 2 to the c is negligible compared to the rest that we see in the bound. And then this means that the smallest x such that this holds gives a negligible term or another one stated differently the size of the fullest bin is at most new except with negligible probability. And this means that we can upper bound the size of a multicollision by new and size of a multicollision on arbit strings by new unless with negligible probability. And in this work of Dambeidol Asia Crypt 2017 this bound was analyzed for a specific and a graph was given for specific parameters. So if you take a specific case of r plus c equal to 256 so we have 256 with permutation then a specific graph of rcm was given this is the black line here it's a stairway to heaven graph and there are two lemmas that derive an upper bound on this graph and these lemmas are quite good and we will use these lemmas later on these bounds later on. Now using this multicollision limit function we can prove security of socks in the unrestricted parameter setting in detail we consider against the same sponge picture we have a key of size k we have s and t of arbitrary size at most b and we prove that if b is a random permutation if g is 2 to the minus delta uniform which I recall means that for a fixed input x to a fixed output y the probability that x maps to y is at most 2 to the minus delta and g is 2 to the minus which means that for two fixed inputs distinct inputs x and x prime the probability that they map to the same output is at most 2 to the minus epsilon in that case we prove that socks is a prf up to this bound and I will explain the bound in detail it consists of three terms the first term is easy it basically accounts for inner collisions in the unkeyed hashing part and the same bound appears in the sponge channel and the sponge indifference ability analysis somehow but again it basically appears in the sponge indifference ability analysis and it accounts for collisions in the inner part here because if that happens the scheme can be broken now the second one I will omit for a moment I will first go to the third one and the third one corresponds to a break at g at t and q bounds the number of construction queries with the same tag so it upper bounds the maximum size of a multiculation on the tag in construction queries and to see why this is needed for a moment assume that the attacker just makes one construction query so q in this case is the number of construction queries and is the number of primitive queries but for a moment assume that the attacker makes one construction query so it gives one plaintext b let's attack t mt is the outer t bits of the secret value w but the attacker doesn't know the other b-t bits but what it can do is it can take this t it can guess the other b-t bits and it can make an inverse primitive query for this guest value w and any of these guesses succeeds with probability 1 over 2 to the b-t and now the attacker can make capital N guesses so the success probability would be n divided by 2 to the b-t now on top of that if the attacker does not make one query but q queries it could get a multiculation on t and now the attack that I outlined before could work not just for one of them but for any of the construction queries with the same tag t so we have to upper bound the maximum size of a multicolusion on the tag likewise here this term corresponds to a break at g and in this case this new bound the number of primitive queries with the same inner part note that the attacker can make primitive queries if the attacker gets a multicolusion here with the same inner part with a different outer part u then also the inner part of v will be the same the outer part of v is unknown because the construction is key but different so the inner part is known and the same for at most new values the outer part is different and unknown and the attacker can make capital N guesses and any of them succeeds with probability 2 to the power minus delta, epsilon and I want to note that if g is the XOR the minimum of delta and epsilon equals k still the bound is a bit confusing with these terms new so I would like to show the meaning of this bound by means of a concrete example and the example I consider is the ISAP authenticated encryption scheme so ISAP is a submission to the NIST lightweight crypto competition by the Brownig at all is particularly designed for secure use in a leaking setting and the message authentication of ISAP is the subject feed sponge ISAP uses SUCKS for message authentication with the function g instantiated using ISAP RK which for the sake of current discussion is a secure function g ISAP consists of four instantiations two with catch up 400 and two with the S-con permutation on a 320 bit state so if we consider the generic security of SUCKS with the ISAP-like parameters starting with the catch up 400 we've got the B is 400 to a 400 bit state the capacity of 256 rate of 144 and the key of 128 bits and if you plug these numbers into the bounds for new we get that the two new are upper bounded by 3 and 80 respectively and this means that we get I mean the 80 stands on top of the 2 to the power of 272 so that term is really negligible compared to the other two and the other two say that we get 128 bits of security likewise for the S-con based parameters we've got B is 320 C is 256 R is 64 and K is 128 and we get bounds on new namely 5 and 67 and again 128 bit security so this is quite a strong bound finally we also consider a leakage resilience of SUCKS and in the leakage resilience setting we consider non-adaptive leakage resilience so we consider any fixed leakage function L and this leakage function L leaks laptop bits of information for each permutation goal for each secret permutation goal and we consider PRF security as before so the attacker has access to either the construction or a random function in addition it gets access to the primitive in both worlds as before so this is the typical black box PRF security but now in addition the attacker gets access to the leaky version of the construction in both worlds it gets access to the leaky version of the construction and the idea of the model is that the attacker can make an arbitrary amount of leaky queries it can obtain an arbitrary amount of leakage but at the end we want that once the attacker makes a challenge query to the construction or to the random function it should still be hard to distinguish which oracle it is talking to and in this model we prove leakage resilience of SUCKS in detail we prove that if G is on top of the earlier conditions and is also strongly protected then the construction is a leakage resilient PRF up to the following bound and the bound really looks comparable to what we've seen before with some addition so this is new, here we've got a new term and here we've got a new term and let me explain these new terms starting with the minus lambda here recall that originally this fraction corresponded to the attacker gassing the inner B-t bits of W but now we consider a leaky setting and in this leaky setting the attacker might have obtained left bits of leakage here on W and this kind of reduces the entropy of W by left bits likewise this term originally corresponded to the attacker gassing and the outer S bits of UV but now the attacker can get leakage but the attacker cannot just get one portion of leakage of lambda bits but rather more and to upper bound how much leakage it gets we use the multi collision function and this term, this new bounds the number of repeated leakages on the same GKX more technically this new bounds the maximum number of multi collision on the same outer part U with a differing outer part inner part of U indeed if the inner outer part of U is the same the inner part of U is different this means that the outer part of V might be different and might be the same but the inner part will definitely differ and the subsequent permutation call might lead different amounts of data on the outer part of V and this is accounted for in this leakage to conclude as we observed that the suffix key sponge is a very easy to protect message authentication code it achieves a very strong security bound and it's still very efficient in fact it's beneficial over the full key sponge and the hash done by construction in a leaky setting and in part because of this ISAP users sucks as a message authentication code and on top of that we can prove leakage resilient authenticated encryption security of ISAP using this result and using a result from AsianCrypt 2019 on the leakage resilience of the duplex and this concludes my presentation so I would like to thank you for your attention