 Hi, this is Ashwin. I am from Indian Statistical Institute, Kolkata. The title of my talk is State, a lightweight and low-energy authenticated encryption mode. There is a joint work with Abhik Chakrabarty, Nilanjan Datta, Quatemukh Mencius Lopez, Mithul Nandi and Yu Sasaki. So, a state is a block cipher-based lightweight AEAD. So, let's first look into what's the requirement from a block cipher-based lightweight AEAD. The first one is small state size. So, we need that the overall state size should be small. This will help in low-IDI implementations in hardware as well as memory constraint software implementations. The second one is optimal number of primitive invocations. So, this is basically it's well known that the energy consumption by a cryptographic algorithm is directly proportional to the number of primitive calls it makes. So, reducing the number of primitive calls reduces the energy consumption as well. So, the third one is defense in depth. By defense in depth, we mean that construction which is robust, even when some parameters are exploited beyond the conventional means. So, for example, there is a nonce and the adversary can repeat the nonce. So, even if this construction is secure, then we say that it's nonce misuse resistance. So, even if the adversary misuses the nonce, the construction is secured. Another one, an important one is the RUP security. Where the adversary can get unverified plaintext. So, even before the complete plaintext is verified at the decryption end, the adversary gets some unverified plaintext. So, a scenario where you can get this kind of advantage is where the memory buffer is small. So, we have to release some unverified plaintext. So, it will be good if a construction can be proved to be RUP secure. Recently, Bunny Ketal presented a construction called Sunday that tries to achieve some of these goals. Sunday is a Mac then Encrypt type scheme where the Mac part is done by omac. So, omac type Mac where you use some constant multiplication by 2 or 2 square to separate the domain. And the encryption part is done by OFB or output feedback function. The Sunday mode has a compact n-bit state. Here, of course, we are ignoring the key size right now. So, you can always assume that there is a k-bit state for key as well. But apart from that, there is only n-bit state for the whole construction. Then, what the authors showed is that the Sunday mode is non-smuse resistant. In fact, it can be viewed as a SIV-like construction as well where both the Mac and the encryption part, they use the same key. So, and it achieves non-smuse resistant security. But there is a catch here and the catch is that the Sunday does not provide RUP security. So, you may have already seen an attack on Sunday in a paper that has been presented in FSE 2020. And another disadvantage of Sunday is that it requires an additional primitive call to prepare a state depending upon the emptiness of the data. So, whether data is empty or not, to differentiate this thing where Sunday requires an additional block cipher call. So, our motivation is simple. Our motivation is to design a block cipher-based lightweight AAD that first of all achieves near optimal state size like Sunday. It achieves the non-smuse resistance property of Sunday. Additionally, we want that it should have optimal number of primitive calls. So, we want to somehow reduce the number of that additional call to zero. We want to make the construction multiplication free. So, Sunday uses multiplications by constant elements in the field. So, what we want is we want to remove everything apart from any other operation apart from block cipher calls. And finally, we want inter-UP security. So, we want that the adversary should not be able to forge even when he is given access to unverified plain text. So, we propose a construction called state which can be viewed as an improvement over Sunday that achieves all these five parameters. So, how state works? So, you have A block associated data, M block message. So, first of all what we do is we encrypt the nonce using tweak value 1. So, a state is based on a tweakable block cipher and we will see what is the utility of tweakable block cipher later on. So, we encrypt the nonce n with tweak value 1 and then we use this as an initial value in CBC MAC like operation over the associated data. Basically, this is FCBC where the last call is differentiated with tweaks 2 and 3 depending upon whether the data is full or partial. Given the intermediate tag computed on the associated data, what we do is we again compute the same FCBC like operation over the message to generate the final tag. And given this tag, we use this tag as the initial value for the OFB encryption and this encryption is done exactly like OFB. So, you can see here this part is completely similar to OFB and these are similar to the FCBC operations. So, you can see what we are doing is we are using tweaks to domain separate. So, here the tweak is 1 and 1 is not used anywhere else. So, 1 is used solely for the nonce processing. 0 has been used to process all this associated data and the message. And 2, 3, 4, 5, etc. have been used to differentiate the last block processing. So, this is for A block associated data and M block message. Now, suppose the associated data is empty. In that case, we simply ignore the first layer of operations here and we directly go to M0 to MM-1. So, we directly process M0 to MM-1 and we get the tag and then the operation is similar. Similarly, for empty message, we ignore the processing of message and we simply go for A0 to A-1. Here, point to notice that we use different tweaks here. So, we use 6 and 7 instead of 2 and 3 so that this intermediate tag value does not release any information to the adversary. So, because in empty message case, the tweaks are different. So, the adversary cannot use this to construct another forgery query where the message is non-empty. Again, the last and the most extreme case is where both associated data and the messages are empty. In that case, we simply use a unique tweak 8 to encrypt the nonce and that is the tag value. We also give a smaller version of a state called as a state that replaces the full block cipher E. So, this is the full block cipher E. It replaces it with round reduced block cipher F that always uses tweak 15. And this round reduced version is always used to process the intermediate blocks. You can see the output of the processing of the last block data is always done using a full block cipher. In both associated data and message. And the encryption part is similar to the previous case in case of a state. And this is as similar to a state. So, here we are ignoring the AD part because AD is empty. In this case, we are ignoring the message part because the message is empty. And the empty AD and empty message is exactly same as a state. As I said, we use tweak 15 for function F and this is to maximize the distance with zero tweak. So, the way we will choose our tweakable block cipher. This maximizing the distance will be clear when we talk about the choice of our tweakable block cipher. But for now, you can assume that choosing tweak 15 will give us some advantage in terms of security. Let's talk about some of the design choices. So, first of all, we use Mac then Encrypt mode. So, this is because Sunday is using Mac then Encrypt mode and this construction state is inspired by Sunday. So, you follow Sunday's approach and as a result we gain by compact state. So, you can see that a state requires just n-bit state for the block cipher and a very small state for the tweak. So, this gives us compact state. Then there is an inverse free nature. So, there is no inverse call here and we achieve non-smissive resistance. Then the question comes for tweakable block cipher. So, Sunday is based on a block cipher. So, why do we need a tweakable block cipher? So, this is, first of all, this is used for domain separation. So, we use a very short tweak. So, we actually use from 0 to 8 in case of a state and 0 to 15 in case of a state. So, we use a very short tweak for domain separation. And for domain separation means we differentiate between the type of data whether it is AD or message. We differentiate between whether the data is empty or non-empty. And we differentiate whether the final block is full or partial. Another byproduct of this is that the construction is completely multiplication free. In fact, it is free from any other operation apart from the block cipher operation itself. So, in this way we can say that the construction is very simple and the circuit will be quite simple given that the tweakable block cipher circuit is simple. So, this is another advantage of using a tweakable block cipher. Okay, let's see the choice of tweaks. So, as I said, tweak 0 is used to process bulk of the messages. So, this will be identical to block cipher as we will see in the choice of our TBC. Tweak 1 is used to encrypt the nonce. So, the first block cipher call is used using tweak 1 and this will ensure RUP security because tweak 1 is not used anywhere else. Then tweak 2 to 8 is used for domain separation. So, 2 and 3 are used for full and partial block, 4 and 5 are used for full and partial final plain text block. 6 and 7 are used for non-empty AD and empty message. And 8 is used for empty AD and empty message. Okay, so, as I said, so the choice of tweakable block cipher, we actually use a tweakable block cipher which follows the elastic tweak framework. So, what is elastic tweak framework? So, elastic tweak framework is, so we convert a block cipher to a tweakable block cipher. So, elastic tweak framework converts a block cipher to a tweakable block cipher. Basically, we parameterize the block cipher with four parameters. T which is the tweak size. TE which is the expanded tweak size. TIC is the number of positions where we insert the tweak bits. And GAP is the number of rounds between each tweak addition. So, how it works? So, we first expand the tweak T with the high distance error correcting code. And then we inject it into the state after a certain number of rounds. So, the recommended version of state, it uses two different tweakable, short tweak, tweakable block cipher. First one is tweak AES which is the, which is a variant of AES 128 based on elastic tweak framework. And it has this property of AES because the number of rounds is very less. This construction is quite energy efficient in that terms. And tweak gift is based on gift 128. And because of the ultralight witness of gift 128, we get the same advantage here. And this construction is used, is useful for area efficiency. So, we have various constructions for various application domain. Okay, so let's see state in light of NIST LWC standardization. So, basically in the first round, there were several candidates based on SIV or Mac than Encrypt. So, state, Sunday gift, Limdolen, C Vrindal, Siftem Photone and Triffle. There were some others, but these were the major constructions. So, among these, Sunday and state, they continue to be in the second round. And as you can see, the state size is much smaller than the other ones. In fact, Sunday is slightly better than state. So, you get 4 bit less state in case of Sunday gift. But, state has optimality, entire UP security and multiplication free, which is not present in Sunday gift. So, state has some advantages over Sunday, with a negligible increase in the state size. Okay, so let's compare with Sunday. So, we have the number of primitive calls is in state, it's A plus 2M, whereas in Sunday, it's A plus 2M plus 1. So, Sunday has an additional call, which is to differentiate the emptiness of data, whether the data is empty or not. Depending upon that, the initial state is constructed, initial value is constructed, and then that is used for the processing later on. State achieves this via designated tweak, as I said earlier. So, this can be an efficient solution for short message processing. And we actually observed this for short messages via hardware implementation. So, the throughput for 16 byte data is 945.36 Mbps for Sunday AES. And you can see that state has around 300 Mbps more throughput here. So, in case of state, it's 1251 Mbps. And similar thing can be observed till 2048 bytes. Then there is number of multiplications. So, Sunday requires multiplications by 2 or 2 square for domain separation. And state achieves this by designated tweak value. So, again, the domain separation thing can be done via designated tweak values. So, it can actually remove all the multiplications. So, it is multiplication free. Entire UP security, as you will see in a paper by Chang et al. Sunday is insecure against inter-UP's attacks. But the choice of hard distinct tweaks ensures inter-UP security of state. So, let's see the hardware performance with respect to Sunday. So, if you see here, state has much better number of LUTs as compared to Sunday. It is much lower. And the throughput is much similar to Sunday. So, this is for long messages. So, for long messages, the number of primitive calls is quite similar because it's only... Sunday has only one more extra call. So, the throughput is quite similar. But state has significantly less LUTs. So, in terms of throughput by area, state is better than Sunday. We also compare state with SAES. So, what we do is we implement it to minimize the area using 8-bit data path on vertex 7. And we see that state has very similar number of LUTs as compared to SAES. And the frequency is much higher than SAES. So, this is another advantage of state in terms in comparison to SAES. Some third-party software benchmarking is given here. So, some of the implementations here are due to risk with early. And the benchmarking results are from the benchmarking effort by Renner et al. So, you can see that state performs favorably as compared to Sunday gift here. In most of the cases. In some cases, the ROM size is slightly higher. But overall, we can see that state is slightly better than Sunday in software also. In terms of security, what we show is that state achieves AERUP security. Which is roughly the birthday bound of the total number of block cipher calls across all encryption and decryption queries. So, just a heads up here, AERUP is a new notion by Chang et al. That combines the notion of privacy, entire UP and pre-image awareness. So, PA1. So, what we have shown is that state achieves privacy, entire UP and PA1 security. While the number of block cipher calls is less than 2 to the n by 2. So, it's a birthday bound security construction. And the high level proof approach is simple. So, the privacy is quite simple to see. Because the privacy follows from the PRF security of MAC and the weak PRF security of the encryption scheme. And it's quite simple to see that FCBC and OFB, both of them are secure till the birthday bound. So, we can ignore privacy for now. We can ignore the privacy in this talk and we will concentrate on the RUP security. So, what you can show is that the tweak values for the first block cipher call in tag generation encryption are always distinct. So, this ensures that the release of internal state information in the encryption phase gives no information of internal state of tag generation phase. So, these two states you can say that these are distinct up to a certain low probability of collision. So, for any forgery, then the adversary has to guess the output of a PRF which is possible with at most 1 over 2 to the n probability. So, when you combine all these things, what you get is a AERUP bound of the form order sigma square by 2 to the n plus QD by 2 to the n. Where sigma square by 2 to the n is due to the PRF security of the tag generation phase as well as there is a low probability of collision as well which is of the same order. And the QD by 2 to the n is due to the forgery attempt where QD denotes the number of forgery attempts. So, this kind of gives the proof of RUP security for a state and for a state actually the security follows from the security of FCBC as well as OFP. So, we have not given this in this talk but it is quite simple to see. So, here we end the talk and I hope you will read the paper and thank you. Stay safe.