 So, the next presentation is going to be the Foot on Family of Flight Weight Hash Functions by Jian Gu, Thomas Perrand and Axel Pochman, and Jian is going to give the presentation. My name is Jian Gu, I'm from the Institute for Infocommal Research in Singapore. The title of my talk is the Fund on Family of Flight Weight Hash Functions. This is joint work with Thomas Perrand and Axel Pochman from Nyon Technological University of Singapore. Here is the outline of my talk. First, I will give you some introduction to motivations for lightweight hash functions. And then we will do some preparations before we can give the front-end design. First is the generalized sponge construction and followed by efficient serially computable MDS metrics. Then I will give the details of the front-end family followed by security analysis and conclusion and following works. Second motivation, so why do we need hash functions? It's mainly for RFID devices, authentication privacy. In most of the privacy preserving RFID protocols, a hash function is required and a basic RFID tag have 1000 to 10,000 gates with only 200 to 2K gates budget for security. So the main goal of the front-end is to minimize the hardware footprint and hardware throughput and software performance are not the most important criteria, but we must keep them in an acceptable range. If we look at the current hash functions, including the standards and Shostrick finalists, they are not happy at all. For instance, MD5, SHA-1, SHA-2, they all have more than 6K GEs and all the finalists of the SHA-3 competition has about 10K or more than 10K. Recently there are many lightweight hash functions proposed. The first one is Squash by Shamya in 2005 followed by MAME in 2007 and presence in different hash modes in 2008. In last year, there are two proposed Amadero and Quark. If we look at these designs in this picture, if we draw a line at the 2.5K here, these are not happy at all. If we zoom in this area, what we can see is present, Quark and Fonton. We draw a theoretical optimum line here according to the corrosion resistance level. For instance, if we want to do the 32 corrosion resistance, we need the internal state to be at least 64 bits and storing only one piece requires six gates. So 64 bits alone requires 384 gates just for the storage without doing anything. So we can see here Fonton is actually very close to this theoretical optimum. So that's the motivation and introduction, and then we will do the preparations. The first is the generalized sponge construction. Sponge construction takes the arbitrary length input padded and split into blocks and fit into this internal state by extorting into this bit's rate portion, apply a permutation, and fit another block, apply the permutation, and here all messages are processed. This is called the observing process, and after all message processed, the same bit's rate portion habits is outputted, and if that is not enough, apply the permutation again, output another R bits, and here you get sufficient many bits. The sponge construction has been proven to be indifferenceable from random oracle up to 2 to the C over 2 caused to the internal permutation. However, the best no generic attack has the foreign complexities. If we fix C here, capacity to the end, both collision and the second pre-mage is required to the end over 2, but pre-mage requires 2 to the end minus R. Why do we choose sponge? If we compare the sponge with the classic Davis-Mayer, we can see that in classic Davis-Mayer construction, in order to get R bits, hash digest, we need the R bits block cipher with K bit key, and we need a feed-forward here. So first we need to store M bits just to process the block cipher, and we need to keep the original value of the training value in order to do this feed-forward. So actually we need to store double of the of the states plus the key. However, in sponge construction, we only need to store M plus R bits. So if we minimize the internal states by setting R and K to B1, and then we can see that sponge actually requires half the memory. Sponge with very small R can be very slow, but this is not good for the typical use cases such as EPC. EPC is of 93, 96 bits. EPC stands for electronic product code. So we generalized this sponge construction a little bit to allow this output rate to be a bit different from the input rate. So if we, and the pre-mage resistance level is revised to 2 to the N minus R prime. So if we choose a bit larger R prime, we can do the squeezing a bit faster, but we get a bit lower pre-mage resistance level. So the second preparation is the efficiency cerebral computable MDS matrix. So MDS refers to maximum distance separable here. So it's used in diffusion layer in many block ciphers in particular AES. It has very excellent diffusion properties. So if we have a vector with D cells, and if the matrix is MDS, we can ensure that there are in total D plus one non-zero values in V and V prime. This is especially good for linear and differential copanalysis resistance. So the AES diffusion matrix can be implemented in software by using table look stops, but the situation in hardware is not so great. Indeed, if we implement the row coefficients, one instant we use it for other rows. We can do this in hardware and we compute this row, multiply with this vector and update the V zero. But after that, when we want to update the second value, we need the original V zero in order to compute this V, update the V one. So in that case, we actually need to store the previous values, but in hardware storing means extra memory requirement. So to reduce this extra memory requirement, we propose this efficiency serial computable MDS matrix. You just can see the matrix like this with ones in the diagonals, zeros in other places except the last row. And we multiply this matrix with a vector. What we can see is we multiply the first row with the vector, we get V one here, and we get V two here, and we do this. So the essential effect is that we pushed the whole vector up by one position except the last one. The last one is updated by this coefficient, multiply with this vector. Here, we don't need extra memory because the shifting and the updates can be done simultaneously. And we'll repeat this process D time so that every cell is updated exactly once. In the meanwhile, we need good diffusion properties by requiring this A to D to be MDS. And excellence is excellence in hardware because we no longer need extra memory. It's also good in hardware software because the same table lookup tables can be used. These coefficients can also be used for deciphering. So to just show the effects of this technique, we tweak the AES. The original AES mix column requires about 263 gates equivalent, but with our tweak, it only requires 74 gates. So it reduces more than 30%. And furthermore, to implement this coefficient, I mean, the inverse matrix in decrypting is a bit costly in hardware, but in our case, the coefficients are similar as in the original matrix, so it can be reused. So here is the details of the Fondant family. The state is built as a D times D matrix of S bits, and we have five variants of the Fondant ranging from digest size from 80 to 256. And for the first four variants, we have S equals to four, with dimension from five to eight, and the last variant has S equals to eight, with dimension equals to six. So the typical question could be why don't we have nine and four here? So instead, we tried, but we failed because no such MDS matrix exists. So we have no choice but choose a larger S here. And to know other details, we only need to specify the permutation here. So actually, the permutation consists of 12 rounds, and each round is AES-like. It has four operations at constant rounds, independent constants into the first column, and then we apply the S box to every cell. We shift I-throw to the left by I-position, and we do the mixed column by applying our special MDS matrix to each column. So if we look at the security of the Fondant, the claims security are two to the N over two for both collision and second pre-mage, and two to the N minus R prime for pre-mage. And for the security proof, as we mentioned, the security relies on the internal permutation. If we model the internal permutation to be render-oracle, then the entire hash function is ideal. And so it's assumed that there's no structural flow up to two to the N, two to the C over two operations. But even if one finds structural flow for the internal permutation, it's unlikely to turn into attack because we have set a very small bit rate where the attack have a very small degree freedom. So AES-like fixed key permutations as very good properties is simple and simple to understand where it started, provide very good security. So for four consecutive round is provides D plus one square active S boxes. So Fondant have 12 round, so we can actually have three times this number active S boxes for any differential passes. So from that we can derive the differential and differential pass probabilities as well as linear and linear how probabilities. So this ensures that Fondant permutation is very resistant to the linear and differential attacks. So we also looked at the other attacks. So rebound attack only works up to the eight rounds for the distinguishes. Keep test, they only work for three rounds. There are some additional works for up to eight rounds with complexity bounded by two to the C over two. So we can also rewrite the whole system of the internal permutation into quadratic equations. But by counting the number of quadratic equations and variables, we are ensured that the current system is not able to be solved with current computation powers. And slight attack on permutation level, so because every round have round dependent constants, so it's ensured that every round is different from the other. So slight attack on operating mode is difficult to apply because the last padded message block is ensured to be different from zero because of the padding rule. Rotational kubernetes is difficult to apply because we have S boxes instead of ARX. Integral attacks can reach seven rounds with very high complexity. So in conclusion, Fondant provides very low hardware footprint. And we also implemented this in software. The speed ranges from 100 to 200 cycles per byte, which is not so slow. It's about 10 times slower than the most of the char-3 finalists. So in conclusion, Fondant is very simple, clean based on AES design. There are smaller hash functions published so far. I only mentioned published because I've heard that there's a sponge in 2011, which is maybe smaller than our proposal. But I haven't seen the paper yet. It provides acceptable software performance. It provides provisable security against linear differential-coupled analysis. And it also receives all known and recent attacks against hash functions with very large security margin. So we set up a website for the latest result. For the following work, we proposed a 64-bit block cipher, which we call LED, light encryption device. It can take any key size up to 128-bit key. It reuses the serial MDS metrics idea. It's slightly smaller than present in hardware. It's only about three times slower than AES in software. It provides provisable security against classical linear and differential cipher analysis in both single key and related key model. So this is the paper accepted by just this year. And we also have a website for the latest result. Thank you for your attention. Are there any questions? If not, let's thank the speaker and all the speakers of the session.