 Hello everyone, I am Ovik Chakramurthi and today I am going to talk about two inter-UPC secure likewise parallel A modes namely Lotus and Locust and this work has been jointly done with Nilanjan Datta, Ashwin Jha, Huatemok, Pencilas Lopez, Midhul Nandi and Insa Sati. So this talk covers the specification of Lotus and Locust, its security analysis, its hardware implementation results and some cryptanalytic results on the underlying primitive. So before going to the specification of Lotus and Locust I would like to give some motivation behind our designs. So consider the scenario of client-server architecture and we assume that the server has lots of resource and it does not care about resource but it cares about the data processing speed. On the other hand the client may be a lightweight device that does not care much about data processing speed but it cares about resource. So in this scenario if we want to provide integrity and privacy on the communication channel between this client and server, we need to adopt some authenticated encryption scheme that can be efficiently implemented in a hardware, faster hardware platform as well as in a lighter platform. So parallel modes actually serve this purpose and also we wanted to achieve a high security bound and preferably the full security bound on the state size such that we can reduce the state size and the block size but still we can achieve the desired security. Next is very important integrity under RUP setting. So frequently it happens that it happens when the receiver's buffer is very small and if the receiver buffer is small and it processes a longer message in that case it is often the receiver release some message bits that is even before the full message is verified. So it is highly undesirable in terms of integrity or authenticity. So we want to have a design that provides integrity even in this RUP setting and last but not the least the versatility of the designs definitely we want our design to be versatile such that it can be efficiently implemented in various platforms. So we have given some motivation behind our design, let's come to the design choices. So as I have already told you we wanted to design a parallel mode and we found the best way to start is to begin with the popular structure of popular parallel modes like OTR and OCD that two of the most popular parallel modes and then add some extra functionalities on the structure to achieve a better performance both in terms of security and in terms of implementation. So to achieve high security bound we have adopted two techniques one is non-based raking and another is masking and this can help us to get a higher security bound in the standard model. The next point is since we are getting higher security bound we can reduce the block size and state size and last but not the least integrity under RUP setting so in addition to the non-based raking and masking we have adopted one more technique which is to generate intermediate checks from a hidden layer of the encryption state. So these three combination non-based raking, masking and generating intermediate checks from a hidden layer these three combination makes the design integrity secure under the RUP setting. So this is the overall design choice behind Lotus and Locas. Let's come to the specification. So Lotus stands for lightweight OTR with RUP security. So here we adopt the structure of the mode OTR and we add some additional feature of RUP security over it. So it is efficient in terms of inverse freeness and definitely it is suitable for combined encryption decryption implementation since it is inverse free. Locas stands for lightweight OCD with RUP security here we use the we adopt the structure of OCD and adds a feature of RUP security over it. It is not inverse free but it achieves a smaller state size and since it is not inverse free it is suitable for encryption only implementation not the includes combined encryption decryption implementation. So when we see the structure of Lotus and Locas you can observe that Lotus and Locas actually differs in the differing the message processing phase but the non-son associated with the processing phase are the same. So this is the non-son associated processing phase for Locas and Lotus and here we are adopting we are using a tweakable block cipher where EKI KN comma 2 denotes the block cipher E with a non-slipendent key alpha to the power I into KN okay and the second component in the subscript is the tweak and KN is equal to K plus n. So you can see that we have adopted a very interesting structure in Lotus and Locas with respect to the tweakable block cipher because tweakable block cipher is in tweakable block cipher the tweaks are mainly used as counter but here we actually use the tweaks as a domain separator so I will come to it later in the in the later slides okay let's come to the message processing phase of Lotus. So you can see the structure is almost similar to OTR except we are extracting some hidden internal states to compute a checksum WXOR and you can see that the output of the associated data processing phases VXOR which is a checksum of the outputs of the tweakable block ciphers and in the for the last block message block we combine it with both VXOR and WXOR and process it using a masking mask encrypt and mask fashion and outputs the final tag. So this is the overall structure of the message processing phase of Lotus and you can see that these values 4, 7, 5, 8 they are actually domains and overall we have 15 domains. So since this design has 15 types of domains so I think 4 bit tweaks are sufficient to represent all the 15 types of domains. So here we can adopt a tweakable block cipher with only 4 bit tweaks. Next is message processing phase of Locust. It has a similar structure to OCB except again we extract the internal state WI states to compute the WXOR checksum and combine it with VXOR the checksum from the associated data processing phase and process it with the last message block in the same manner as Lotus to generate the final tag. So you can observe that Locust and Lotus actually differ in the message processing phase from M1 to MM-1. Last block is processed in the same way for both Lotus and Lotus and here we have total 13 types of domains so again we can use 4 bit tweaks to represent all 13 types of domains. Now let's come to some structural comparison between Locust, Lotus and the other well-known designs. So you can see Locust and Lotus. So Locust is provides almost the same functionalities as OCB except it provides additional features of interuptial security but within compromise in the rate. So since the rate here it is half here it is 1 and Lotus it provides all the features and it provides an additional feature of interuptial security over OTR within compromising the rate half and all the other designs they are not as featureful as both Lotus and Locust. Now we have described the high level mode structure of both Locust and Lotus along with some structural comparison. Let's come to a lower level which is the choice of the primitive that means the choice of tweakable block cipher that we use. So here we are either the interesting point for these designs Lotus and Lotus and Locust. So normally in most of the designs with tweakable block ciphers tweaks are used for the tweaks are used as a counter but here we are using tweaks for domain separation. So if a design have like 15 domains or 14 domains then we we can describe all these domains with a short tweak. So that's the main motivation such that we can use short tweak to design our TBC and we name it short tweak tweakable block cipher as small t and then busy because the tweak is small. So this is the framework for designing our tweakable block cipher. This is the high level structure and here we have actually defined a framework which is called elastic tweak framework and what it what this framework does it actually converts and stand alone block cipher to a short tweak tweakable block cipher and it actually takes a tweak it takes a some it can take some well-known block cipher and it uses a tweak small tweak of t bits it actually expands this tweak we are with a high distance encoding to make an expanded tweak te and the small t is the size of the expanded tweak and then we inject the expanded tweak to the block cipher state after every gap number of rounds. So here we use the tweakable block cipher which takes the gift 64 well-known gift 64 block cipher it uses a 4-bit tweak expanded to a 16-bit tweak using a high distance encoding and then inject the 16-bit tweak to every after every four rounds. So most of the tweakable short tweakable block ciphers they actually differs in how to inject the tweak in which position we inject the expanded tweak. So here we have in gift 64 we have 16 4-bit nibbles in the state so we inject one bit each of the one bits of the of this expanded tweak to each of the 4-bit nibbles total 16 nibbles and we and total 16-bit in the expanded tweak. So overall the structure is simple but the main motivation behind the structure is that we can be more confident on the security of the short tweak tbc because we are using we can use some well-known block cipher we can use AES we can use gift we can use a late present anything. So in that case we will be more comfortable we will be more confident for the security of the tbc and definitely tweak gift is not exactly same as gift 64 it adds some additional structure so definitely we need to mix some additional crypto analysis on tweak gift. So you can see that if we want to do single if we want to consider the crypto analysis on single key settings if it is zero tweak difference then it is exactly the same as gift 64 we don't need to do anything we have sufficient results on gift 64. Now since we are using non-dependent key in the AED modes so that's why we we can prove we can prove the security of Lotus and Locas in the ideal cipher model and we need to analyze the related key crypt analysis of this tweak gift. Now in related key crypt analysis there are two options one is related key crypt analysis with zero tweak difference which is exactly the same as related key security of gift 64 and to the best of our knowledge the best related key differential characteristic is upper bounded by 2 to the power minus 1779 proposed by Liu et al for 19 rounds of gift 64 and for related key setting with tweak difference we have actually adopted some interesting way to do the crypt analysis. So gift 64 is a 28 round block cipher and we divide the rounds into cores that means four consecutive rounds forms a core. So we leave the first two rounds and the last two rounds so intermediate 24 rounds can be divided into six cores and then we compute the characteristic for each of the core and we have found that for related key setting each of the core has characteristic 2 to the power minus 16 so if we have consecutive six cores then we can get upper bound on the characteristic. So this characteristic will be 2 to the power minus 96 because six cores and each of the cores 2 to the power minus 16 so upper bound of the characteristic is 2 to the power minus 96 and we have found the best known lower bound is only 2 to the power minus 192. So the actual characteristic will lie between 2 to the power minus 96 and 2 to the power minus 192 and for security in single key setting we have found that one core has a characteristic 2 to the power minus 25.6 so six consecutive core will have a characteristic of 2 to the power minus 153.6 so it is upper bound and it is already more than 128. So this is the overall cryptanalytic results we have done on tweak gift. Now we have also implemented the whole design on FPGA and we have also implemented the design tweak gift independently on FPGA. So this is the architecture I am not going to the describe the details of the architecture so this is the architecture and these are the FPGA results so you can see that the encryption only architecture achieves a much better hardware area than the encryption combined encryption decryption implementation and overall it achieves a better frequency and a better area efficiency throughput area efficiency ratio and this is for vertex 6 this is for vertex 7 and these are the results for standard or tweak gift. So this is the architecture for Lotus when we use tweak gift in the structure of Lotus EAD mode and this is the structure architecture for locus using tweak gift. So we just feed the module of tweak gift inside the architecture of locus and lotus and these are some FPGA results for lotus and locus you can see that the state size of locus is smaller than state size of lotus but overall lotus outperforms locus in terms of the elutes and slices and also it achieves a better slightly better frequency than locus and almost same throughput as locus but overall the throughput area efficiency ratio is better for lotus than locus it's it's significantly better actually. So this is the overall FPGA results for lotus and locus and we have also benchmarked lotus locus with some existing designs and you can see that definitely there are several other designs like acorn or betel light, betel secure and and and a few others which is which are better than lotus and locus in terms of hardware area as well as in terms of throughput area efficiency ratio but on the other hand lotus locus provides a versatile features like any addition in terms of security or implementation in faster and lighter platforms both so overall lotus and locus actually achieves some extra features than the other designs and this is in the result in vertex 7. Now we have till now we have described the specification of lotus and locus the cryptanalysis results on the internal primitive and hardware implementation results of lotus and locus let's come to the provable security of the lotus and locus mode. So here we have proved the privacy of both lotus and locus and instead of proving the in-city xt security we have directly proved the interupt security so we all know that interupt security implies in-city xt security because here the adversary gets some extra power so if we can prove in interupt security we can be sure that we have we also have in-city xt security so here regarding the privacy security we can have n by n plus k by 2 bit security which is pretty high and if n equal to k then we have full n bit security and if n is less than k then we have even more than n bit security but in the ideal cipher model and we for the for this thing we q is stands for the number of encryption queries sigma stands for the number of blocks in the encryption queries and q p stands for the number of queries to the ideal cipher and sigma v is the number of verification queries now coming to the interupt security in interupt security we actually achieve this sigma square by 2 to the power n n plus k and q v by 2 to the power n bound so if n equal to k then so if n equal to k then we achieve n bit security if n is greater than k then actually we achieve less than n bit security but this scenario is not very common okay and here we the adversary gets some additional oracle access and it can make decryption query and what is decryption query decryption query is the adversary can give some ciphertext blocks and it can get the corresponding message blocks and it doesn't care whether the ciphertext is verified or not okay so it just gives a ciphertext block and gets a corresponding message blocks so here it is a extra power for the adversary over the standard security model in ctxt security model so even if we are getting interupt security we are actually getting a very high security bound of minimum of n plus k by 2 and n okay this is for lotus and it's it's it's a the bound is almost the same as locus it's exactly the similar the same n n plus k by 2 for privacy and minimum of n plus k by 2 comma n for interupt security so overall i would like to give some intuition so the main reason that we are achieving interupt security is tweak values properly differentiate the domains so we can represent all the domains individually using the short tweak tbc by changing the tweaks we have nonce based keys the keys is derived from the nonce and we are getting intermediate checksum and this checksum is computed by some hidden internal state hidden to the adversary instead of the plaintext checksum and this gives an interupt bound of order of sigma square by 2 to the power n plus k and 2 qv by 2 to the power and we can also and we all can imagine that the first part comes from the non-trivial collision in input as well as that quick and the second part comes from the forging attempt so there are total qv forging attempts so definitely it should be qv by 2 to the power minus 2 to the power n okay so this is all from all about the design of lotus and locus so thanks a lot for inviting me at fsc so i'll be very happy to answer your questions thank you