 Hi everyone, I am Chun from the Shandong University. This talk is about message authentication or message authentication codes. The work is cooperated with VIX, Weijia and Yu Yu. The talk will follow this online. We will first recall something about message authentication. Message authentication is a symmetric key crypto system. It has a tag function taking a message as an input and produce a corresponding tag T. And has a verification algorithm. The algorithm will take the message and use a specified tag T as an input and output either accept or reject. Accept means the message is intact and reject means otherwise the message has been tampered during transmitting. So we follow the definition of this reference. We will distinguish between message authentication scheme and the message authentication codes. By message authentication codes it means the verification algorithm is defined by executing the tagging function tag and check if the output of the tagging function equals the user specified input tag T. If they are equal it outputs accept and otherwise it outputs reject. This is the message authentication code. This is more common actually. A message authentication or message authentication code may use IV or nonce. And in this case they are called IV based MAC or nonce based MAC. Or they can just don't use them and just take the message as an input. And in this case it is called a deterministic MAC. Some instances could be found in these two references. So message authentication could be done by a collision resistant hashing and a block cipher. So we just use the block cipher to encrypt the hash digest of the message. So in this case since the hash is collision resistant it is difficult to find two messages. Find two different messages has the same input here. So it is hard to forge. This is an idea. As known by many we could have better efficiency for this hash than MAC scheme. We could use a combinatorial object instead of the collision resistant hashing. We could use the universal hashing actually. So the universal hashing might be defined by a sequence of field multiplications and something like this. So we use a secret universal hashing key HK and it multiplies the first block of the messages. And it multiplies the second block of the messages and like this. And they are exalted as hash digest. In this case the hash key should be kept secret. So the key of the message authentication code becomes the combination of the universal hashing key and the block cipher key. So both of them should be kept secret. But this hashing could be more efficient than collision resistant hashing. It could also be defined based on the four-round AS as known by many. So it's potentially more efficient. One step further if the keyed function is a keyed function or PRF. We can use a nonce for better security. Like this. This is the popular Wegman-Cutter MAC and some of the block cipher based on the virus could be found. In these references. Another approach to use a hash for message authentication is the HMAC scheme. This approach looks like hashing the keyed message twice looks like something like this. Also we can use a block cipher. This is a cipher block chain mode, CBC mode. So in this mode, the final piece of data depends on every block of the message. So it could be used to authenticate the message. And also this is another approach. This is PMAC, another approach to use a block cipher or use a tickable block cipher. It has its own advantage compared with CBC. So here we just list these examples. Of course there are a lot of others. So once we implement the MACs, the message authentication schemes and deploy, we are facing the side channel attack issue. We will mainly focus on the differential power analysis issue. Differential power analysis, briefly speaking, once the key and secret is used to process different inputs or plaintexts or messages, the differential power analysis would allow the attacker to measure their power consumption and compare and then extract the key and secret. So with this in mind, we can see that the CBC MAC has an exact fit with this setting because the key of the block cipher is used to process different input blocks. So the key is used to process different inputs. So it's an exact fit. We could recover key. This is not something just theoretical because such an attack was used to break the IoT scheme of the Philip smart lamp. So what about the others? The others, this one PMAC is the same as CBC because the same key is used to process different inputs. So if it is deployed without any side channel protection, it will be broken. So about the others. About the universal hashing-based MACs, actually they are the same. With the previous multiplication-based hashing in mind, let's simplify the situation. We imagine we only use them to authenticate a single input block. So the hashing turns into such a definition. Just use the hash key to multiply the message. So then if we use the MAC to process different messages, we are able to collect a lot of leakages about the same secret multiplications. So we can use the MAC to process different messages. We are able to collect a lot of leakages about the same secret multiplied with different messages. So once again, we can use the differential power analysis to recover the hashing key. Once the key is recovered, the security of this universal hashing-based field multiplication is the universal hashing MACs and about each MAC, once again the same key is used to process different messages, different inputs. So if multiple messages are processed by the implementation, then we are able to extract the key again. To define against the side channel attacks, the differential power analysis and similar attacks, we may use implementation level protections such as masking, shuffling and something like this. But these protections induce severe overheads. So for example, according to the data given in this reference, the cost of a single key operation will increase from n cycles to 10n or even 100n cycles. It has a severe blow up. So if we follow this approach, the CBC will have to use the CBC. We will have to protect every block cipher call and every exhaust so it turns into a dark world. Every block cipher call and every exhaust will have to be protected. The PMAC will be as dark as this one because we also have to protect every block cipher call. So about universal hashing-based MAC, again we have to protect every field multiplication. So it is actually the same as before. Some of the protected calls is also linear with the length of the message. It's basically the same as the block cipher-based MACs. So to have something better, let's go back to the plan to hash the MAC using the collision-resistant hashing. The collision-resistant hashing might be less efficient, but it is secretly this. It has no secret, so we do not need to protect anything about this hash execution. We only need to protect this block cipher, so only one of the calls in this computation flow needs to be protected to define against the side channel attacks, so it would be much more efficient. Actually, if we have to use side channel protection to define against the side channel attacks, it could be much more efficient than the previous block cipher-based designs and the universal hashing-based designs. So it is unsurprisingly it was adopted in some previous papers about leakage-resilient MACs or leakage-resilient authenticated encryption. Let's see another issue of this naive design. About this naive design, if it is a MAC, during the verification, we will face verification leakage issue. So if the verification is defined by first compute the correct tag of the specified message M and check if it matches the user-specified target tag, then we could use a lot of different verification queries on the same message and the different user-specified incorrect tags and try to observe the power traces of these comparison operations. Actually, this could enable extract the right tag correspond to the message we specified. So we are able to extract the right tag of this message and make a following. So to define against this kind of verification leakage, a previous reference of our group proposed to use the inverse of the block cipher. During the verification of the user-specified message and the tag, instead of computing the right tag of the message and compare with the user-specified incorrect tag, we compute from both sides to the middle, from the message M to the middle and to the hash digest and from the user-specified tag to the inverse of the digest and compare at this side. If we do the verification as such, then even if everything is leaked, even if everything is leaked, we only have to use this pseudo-random value, e k minus 1 t. This is used for the following actually, and it can be formally proved. So the verification leakage turns useless here. So after we see what are the message authentication scheme and what are leakage-resilient message authentication, let's now see something about the birthday security issue. So about this design, if we use inverse for the so far so good, it is so far so good. It is resilient to leakages and it is efficient for side-channel security, but due to the birthday issue, it has a low data attack. The attack has three steps. First, we find a collision on the hashing. Because the hash is keyless, we could do this during offline computation. Find a collision, h m1 equals h m2. This requires 2 to n divided by 2 computations. If n equals 128, like the as, then the computation is just 2 to 64. Then we ask the tagging oracle for the right tag of the message. So by this, the tag t is also the right tag of m2. So we have a forgery m2 t. Overall, the computation of this tag is 2 to n divided by 2. And when n equals 128, the same as as, the computation is 2 to 64. This might be moderate, but the data complexity is one. It's a low data attack, so overall this attack seems a severe real-world threat. Security could be severed by a tweakable block cipher. We use a hash with 2n be the digest, and one half of the digest is used as the tweak. Then we could also use the inverse of a tweakable block cipher to avoid verification leakage. So for this scheme, the computation needed to find a collision turns into 2 to n. And when n equals 128, it is 2 to 128. So this is infeasible. We could also leverage this hash-the-max scheme using a permutation with large input, like what is done is the as-of-max scheme. But what if the crypto library only has reliable block cipher implementations? We have to instantiate such a scheme, such a hash-the-max scheme, use a block cipher, so this method could not be used. And we seek for a solution to this question. So about this question, we offer block cipher-based solutions. We propose block cipher-based hash-the-max designs that has beyond both very probable bounds in the presence of leakage. So the left one, we use a hash function with 2-n-bit digest. In the left one, a half of the digest is used as the input to the block cipher, and the two block cipher calls are using two different block cipher keys. And the other half of the digest is used to resolve between the two block cipher calls. And the verification is also made in a check-in-the-middle manner. For the verification, we will compute the hash digest and compute inversely, and actually for the intermediate values match here for the verification. And the right one, the right one uses a single block cipher key. It uses a key block cipher to derive a new key as the second block cipher call. And so the second block cipher is almost always recede for new messages. And also the verification is made in a mid-in-the-middle manner. We will compute the hash digest in the forward direction and compute the inverse of the block cipher and check if the intermediate values match here. So about these two designs, one could figure out, for the left one, the two block cipher calls actually form the so-called LRW-1 take-able block cipher proposed in the original LRW-2, LRW take-able block cipher paper. So this one we call it LRW-based for the right one, the right one actually the two block cipher calls in this red box is also a take-able block cipher proposed in this paper. But due to the use of the Rikin block cipher, we call it Rikin-based Hatch-MAC-R-HM. However, while the two schemes could be seen as the hash then take-able block cipher instantiated by two different take-able block cipher modes, modular proof is not possible because for the take-able block ciphers in the red boxes, they could only be proved secure up to the birthday bound. But here, we are trying to achieve beyond the birthday bound. And also, for the left one, we are trying to prove beyond the birthday bound security when the intermediate values between the two block cipher calls are leaked to the adversary. So we could not use or try to employ a modular proof. This is not possible. So we prove them via dedicated analysis. And eventually, our result as such for the LRW for the LRW-HM-MAC scheme, we proved 2N divided by 3 security when the block cipher is modeled as a strong pseudo-random permutation and the hash function H is modeled as a random oracle. For N equals 128, the concrete security is 2 to 78.3. This should be much stronger than the 2264 and might be sufficient for constant settings, actually. And for the Rikin-based HM-MAC, we prove the asymptotically optimal security 2 to N divided by N security but only when the block cipher is modeled as an ideal cipher and again, the hash function modeled as a random oracle. The concrete security is 2 to 121 for N equals 128. So these are their security. Confirm their efficiency. Confirm their performance advantage. We seek for instantiate errands and comparisons. So we instantiate the block cipher using agents 128. And for the hash function, we use the SHA-3 variant using the KCHAC-F400 permutation to enable a fair comparison with the ASAP-MAC scheme. So for comparison, we compare with two representative schemes. The first one is ASCBC. So in the CBC, the number of masked block cipher calls, masked keyed executions is linear in the length of the message. So this is the representative of the classical designs. And the second target is the ASAP-MAC, which is also a hash-the-MAC with efficient side-channel security. It consumes 1 keyless hash plus 1 rate-1 duplex. It uses a rate-1 duplex for the masked block cipher. And the performance is demonstrated in these pictures. In all of the pictures, this line is the performance, the number of cycles consumed by the ASAP-MAC. Because the ASAP-MAC does not need masking, so the performance is irrelevant to the number of shares. But for our schemes, of course, the more the shares, the less efficient it is. So about the conclusion, our proposals outperform the protected ASBC as long as the messages are not too short. For example, more than 50 bytes. This is within our expectation. And also, our proposals outperform ASAP-MAC when the level of side-channel protection is not too strong. For example, it's less than the order of masking. And finally, our proposals the performance is comparable to the more aggressive variant ASAP-MAC K8. So for a more detailed comparison, our schemes are extremely easy to deploy from existing crypto-leaves with the masked ciphers. For example, the HACIO library proposes that CCS-17. And the scheme inherent in some sense the security of the well-understood primitives, the security of the masked block ciphers and something like this. And the advantage of ASAP-MAC lies in that it is a dedicated design for potentially better efficiency. And also, they design in-bed default implementation. Actually, this is DPA. And if you implement ASAP-MACs correctly, the implementation will resist DPA by design. Finally, for potential applications with less it could be used as side-channel CQ-MAC or AE. For example, our proposals could be used to replace ASCBC in the Philip Smart Lamps to close the side-channel weakness. This will, of course, make the system more secure. And actually, the design might find more applications beyond side-channel security. For example, for efficient evaluation in multi-party computation engines, this reference has identified CTR, then HTA, then hash the MAC scheme as the most efficient AE scheme in such engines. And our proposal could be used to replace this plan hash the MAC scheme in this AE scheme to achieve better security bounds. So, that's all. Thank you.