 Hello everyone, this is Zamit. I am a PhD researcher in the Causic Group of CableU1. In this video, I will be presenting our work of FSC22, entitled 1-2-3-FORC, Counter-Mode Variants Based on a Generalized WorkCypher. It is a joint work with Elena Andriva, Damian Vizar and Bart Pranil. The overview of this presentation is as follows. I will first briefly define and discuss about FORC cipher and its generalization multi-FORC cipher as MFC. Then we will do a recap of encryption modes, specifically counter-mode, as we all know that counter-mode is used in many applications, ranging from random number generation AAD schemes to network security protocols like TLS or IPsec. Clearly, then it is a good target of research for further improvements in terms of both security and efficiency. I will then define the generalization of counter-mode, dubbed as GCTR, and will drive you through our exhaustive study of all possible simple GCTR variants. This includes existing counter-like variants or counter-like modes, like counter-intweak, counter-dollar or the traditional counter-mode itself. Later, we will see an implication of this study. In particular, we will revisit the twicable and ciphering scheme called THCTR, and we will see the impact of power study on the claim security of THCTR. I will then conclude the presentation with describing some use cases of GCTR in practice and some open problems or possible directions for future research. Let's start. So, yeah, FORC cipher is a twicable cipher that takes an input block M, like T and key K as input, and returns to output blocks C0 and C1 from the same space as the input M as output. FORC cipher was introduced in ASIC 2019 by Andrew Ideal and was also a second-round candidate of this list with competition. The security of FORC cipher is defined by its indistinguishability from a pair of random permutations under chosen separate text attack. This notion is dubbed as PRTFP and the adversarial advantage it informally defines here. Now, a multi-fork cipher can be seen as a generalization of FORC cipher in terms of the number of outputs. So, instead of returning two output blocks, a multi-fork cipher will return as many output blocks where S is an external parameter that corresponds to the number of branches of multi-fork cipher. Similarly, the security of a multi-fork cipher is analogously defined by its indistinguishability from an S-tuple of random permutations under chosen separate text attack. And the notion is dubbed as PRTFP with an informal adversarial advantage defined as here. Let us now talk about counter-mode and its generalization in the CTR. The traditional counter-mode was introduced more than 40 kits ago. It is a block-cipher based mode of operation and is also part of NAIS standards for block-cipher encryption modes. Counter-mode has quite many properties that makes it important or better choice over other standards like CBC mode, for example, in certain settings. So, to exemplify, let us have a look at the table. If you see in this table, you will find that counter-mode can provide many additional properties like full parallelizability support or primitive inverse-free encryption properties like pre-processing support or padding-free encryption and many more. This makes counter-mode a really good choice for encryption. However, I would like to point this out that although it provides so many good properties, it can only provide birthday security, which if put in a simple words, means that for a block-cipher like AS128, one can only get a security of 64 bits. That is quite low and also that too only in a non-respecting setting. That means when the non-input of the counter-mode is unique every time. But 64 bit is not enough nowadays in many applications and forcing or ensuring non-repetition is also not difficult in devices that are mobile or cheap or not well maintained. For example, IoT devices, small IoT devices. So, the first question that comes in mind is can we come up with or some counter-like modes that provide all these desired properties of counter but also add more in terms of both security and efficiency? When an existing work of Patty and Suryan from Crypto16 gives partial answer to this question by providing a counter-like mode called counter-intweak that is based on a tweakable block-cipher and improves the security of counter in some cases. But in this work, we target to fully answer this question by defining a generic counter-mode based on multi-fork cipher and then performing an exhaustive analysis to filter out best counter-like modes that excellent both security and efficiency. So, in this slide, I'll define GCTR and simplify it to make it easier to understand or to compare it with counter-mode. So, in this slide, as you can see, GCTR can clearly be seen as a generalization of counter-mode where the key stream is generated using a framework called TCTR, tweakable CTR framework that takes two sequences. One is the tweak sequence and the other is the input sequence as input and gives a key stream V as output. This key stream, just like counter-mode, is then absorbed with the message to generate ciphertext. So, if you zoom into the TCTR framework, this is how the TCTR framework will look like. It consists of multiple multi-fork cipher calls and the input to the TCTR framework, which is two sequences of inputs X and inputs TCTR are separated and block by block are used here for each multi-fork cipher call as their input and tweak argument. And are used to generate the corresponding outputs, which are concatenated to generate the final key stream. So, going back to the main GCTR mode, we can simplify the mode like this. As you can see here, it takes tweak sequence T and X, gives a key stream V, exerts with message M and gives ciphertext C. If you put in a box, a message goes inside and ciphertext comes out. Here are the additional inputs and additional outputs. So, if there is a nonce used that goes with the input and if there is internal randomness that is used to generate the ciphertext or to randomize the ciphertext, let's say, then that randomness is also required to be put as output. So, we have R here as the output. So, clearly these functions T, the tweak function and the function for X as the input function, fX and fT are, in the simple cases, will be generated using the remaining arguments, the remaining inputs like N or the internal randomness R or some counter J. We now define some rules to define these functions fX and fT efficiently. We call them efficient JT R variance. And these rules are basically just by saying that out of these three inputs, as you can see, N, R and J, these fT or fX can only be either a concatenation of any of these two arguments or an XOR of them, any of two arguments or a copy of either of those three arguments or just a constant function, could be zero or any constant, which is independent of these three variables. And the second rule is that if fT already has one of these three inputs, fX is not allowed to have the same because that makes no sense to not add anything in terms of security and either in efficiency. So, these two simple rules are good to filter out simple JT R variance or say efficient JT R variance. And if one calculate them, we can see easily that there are 36 possible variants that follows these two rules. I would also like to note that these 36 variants, the simple JT R variance also include the traditional counter mode, the counter dollar mode and also the counter tweak mode from the work of parents. Let us now recall the security notion called knife security for encryption schemes that follow the syntax of non-send IV based encryption. This notion was introduced by Perrin and Sury in 2016 and is the same notion that has been used for the analysis of counter and tweak mode. Informally, this notion says that an encryption scheme, a knife encryption scheme, that is a non-send IV based encryption scheme is knife secure if it is indistinguishable from a random function, where the random function's output is variable and depends on the input message length. Here in the knife, as you can see, knife stands for non-respecting setting and IV stands for non-sreusing. So, to comment them, we use the bracket abbreviation. In this work, we have performed an exhaustive security analysis of all 36 simple JT R variance under the knife security notion. We have performed a security analysis using the TCTR abstraction, the TCTR framework abstraction. And since the TCTR framework is a generic framework that does not specify or say anything about the particular variant, the proof is also generic and a compact. So, in a generic and compact proof, we try to analyze all 36 modes. Our proof is based on Perrin's as coefficient technique and our results in a summary shows, as you can see here, shows that 18 out of 36 modes are insecure under knife security notion. The remaining 18 are at least but they secure with bounds better than counter mode. So, when I say better than counter mode, their bounds has a term that grows slower or are limitedly controlled by the adversary than the original counter mode. And this original counter mode is not included in these 18 secure variants because counter mode does not provide security in non-seriesing settings. So, when I say 18 secure modes, they are secure under both non-suspecting and non-missusing setting with different degradations, different security degradations. And out of these 18 secure variants, there are three that are beyond but they secure. That means they provide security beyond the but they bound. They are namely just your one, three, and seven. So, for the following few slides, let me get a bit more technical or so to say more formal to build up the stage for our found results. And don't worry after describing the formal results, I will briefly also explain what they actually mean in practice. So, you can see here, the first expression here follows the adversarial advantage, an adversary that is trying to break the nice security of GCTR variant, let's call it GCTRZ where Z is the name of the variant, the number of the variant. And for that adversary, we are trying to upper bound this adversarial advantage of breaking the nice security of that variant. And the advantage is upper bounded by two terms. The first is a term that refers to the pseudo random two cable multi fork permutation security of the underline multi fork cipher. And additional degradation that comes from the mode, the GCTR mode itself. So, this degree doesn't vary variant by variant. So, now in this small table below, you can see the beyond but they bound security variants with their corresponding functions fd, like how the tweaks are defined for the underline GCTR framework, function fx. The input sequence are defined for the underline GCTR framework. The degradation when x is one, that is when nonce is always unique, that is nonce respecting setting. For example, applications where nonce is defined as the state, which is maintained and ensured as unique every time or nonce is somehow ensured to be unique. And the last column is for cases where nonce is misused or reused or forced to be reused and the degradation corresponds to the security of the corresponding variant and the nonce misuse setting. Clearly, the security in the nonce respecting setting is better than nonce misuse setting for energy variants or to put it in the other way, the adverse advantage of breaking the security of energy variant is lower in nonce respecting setting than in nonce misuse setting. But more concretely, if you see here, if you see here, the highlighted column shows that when nonce is misused, even when nonce is misused, GCTR3 can provide security which is higher than birthday bound. The bound shows that the security is in birthday of n plus t and if t is quite large or non-zero, let's say, then the security could be beyond birthday in n. And on the other hand when the nonce is respected by that, that is the nonce is unique every time, GCTR7 gives information theoretic security for generally counter mode which means that GCTR7 has no additional degradation than whatever that comes from underline primitives PRDMFV security. Additionally, if you see to the last row in this slide that GCTR20 person who knows counter mode can easily see that this is just a counter mode when s is equal to 1, that is when the underline multifoxypher is associated with s equal to 1, that is kind of a tweakable block cipher which tweak fix to gamma, gamma could be any constant, let's fix it to 0 then we get counter mode and counter mode is insecure in a nonce misuse setting but gives you a birthday security in non-suspecting setting. And clearly the other variants are better than counter mode, although they give just birthday security, they have bounds that are not as they don't grow as fast as counter mode. This plot shows the adversarial advantage as functions of the number of block values made by the adversary or the number of maximum nonce repetitions used by the adversary. You can see this plot as visualization of the data that I showed before in tables. So the first plot here, the plot a basically shows that when the setting is not suspecting to 1, that is when the adversary is not allowed to repeat the nonce, the GTR7 has no additional degradation as you can see here the GTR7 a curve is a straight line parallel to x-axis, never meets the x-axis. So whatever number of block-wise adversary makes it can never get any high advantage. However for this counter mode and GTR3 this is not the case and there are an upper bound on number of queries after which the adversary can break the scheme. But we can note that for the GTR3 this number of queries this number of block queries is very high and that explains that in non-suspecting setting the GTR3 gives you higher security than this counter mode and to be concrete it's a beyond further security even up to full and bit security depending on the tweak size. If you see plot B where we said x to not equal to 1 to be something larger than 1 that is when the nonce can be misused this is a moderate case where the nonce is misused through sigma many times where sigma is the number of block queries. Then you can see even if nonce is misused for one more time like x is equal to 2 the security degradation the additional degradation for the GTR7 is high and in GTR7 security comes down to butane n you can see here and that's the same case for GTR3 as well when the tweak size is up to n bits but for larger tweaks we can still get higher security with GTR3 The last plot C here shows the advantage as a function of maximum number of nonce repetitions used by the adversary and you can see for a higher number of nonce repetitions the security gets faster and even with that the GTR3 with higher tweak with larger tweak size we get a better security degradation security diggers slower than the other variants. So to summarize we can say that GTR7 is the best GTR variant best simple GTR variant in terms of security for nonce respecting setting despite of whatever the tweak size is and also for nonce misuse setting but when the tweak size is either upper bounded by n or if it's beyond n then the number of maximum nonce repetitions allowed for the adversary is upper bounded by this term here where sigma is the number of blockwise, the number of multiphox hyperquies and the q is the number of message squares made by the adversary and otherwise GTR3 is the best GTR variant in terms of security I would also like to point out that GTR3 when instantiated with s equal to 1 that is the underline MFC instantiated with a tweakable block cipher reduces to counter in tweak mode however our generic proof provides security bound that improves upon the original counter in tweak bound and in particular it improves the original bound from being in order of sigma squared to an order of q sigma which says that counter in tweak provides stronger security guarantees than what has been cleaned in original paper more concretely it says when average message length is longer counter in tweak can provide higher security guarantee let us now look at an implication of this work also to say an observation as a consequence of this GTR work and the generic security analysis to applications that use a counter like component inside to achieve something good in the particular we target this encycling scheme called tweakable SCTR which claims to be beyond but they won't secure TSPRP scheme however after a careful look we realize that it uses a counter like component that looks like the GTR4 variant from the 36 simple variants that has been analyzed in our work and GTR4 as we know has only been shown but they won't secure we investigated this inconsistency and realized that TSPRP security claims are incorrect more specifically the bottleneck of the security degradation is the GTR4 like component that is used internally by TSPRP we also provide a but they won't attack to invalidate the current pound of SCTR and point to the exact flaw the exact Peltkit analysis in the security proof of SCTR energy fix to this gap could be replacing the GTR4 like component by GTR3 or GTR7 to get the beyond but they won't secure it as I described earlier that security was not only concerned and security and efficiency both were together targeted with MMC in mind MMC itself due to its expanding nature will bring speed up to the Cypher evaluation and hence could also bring speed up to the whole mode evaluation in this slide we provide the efficiency comparison of the GTR mode with the other counter-alike modes like counter mode itself or the counter in tweak mode for the CTR we instantiated it as equal to 2 because the only MMC instantiation is fork cipher with 2 outputs and the fork cipher we instantiate with fork skinny and you can see in this plot that for the y-axis where the number of rounds required are shown to process the number of quiet bytes on x-axis the CTR mode performs quite better than the other 2 where the other 2 counter and counter tweak mode are instantiated with fork skinny and more specifically the red line shows that the CTR mode requires fewer number of rounds to process a particular number of quiet bytes than the other 2 and in numbers the CTR provides at least 20% of speed up than the other 2 I would like to point out that this speed up of 20% or in general the speed up is not specific to a CTR variant it's the same for all CTR variants because they all follow the same CTR framework so to summarize in this work we have presented a generic counter mode over the section of multi fork cipher that provides all desirable properties of counter mode but with some extra that in terms of both security and efficiency to enumerate in terms of security we get security against nonce misusing adversaries or a security bounce beyond the birthday barrier or sometimes full and with security and in terms of efficiency particular to gcdr instantiated with mfc s equal to 2 fork cipher with fork skinny we get efficiency gain of at least 20% when compared with counter or counter and tweak mode instantiated with 2 gable block cipher skinny let us now talk about some use cases of generic counter mode in practice there are various ways the generic counter mode can be used and two of important of them are as follows the first one is when an application requires only encryption and announced misuse suggestions is desirable there to exemplify consider microcontrollers that are embedded with two random number generators but with constrained ramps and they want to stream sensor data and they have this possibility of nonce repetition and there we need an encryption scheme that can provide nonce misuse resistance so gcdr can fit there and gcdr can also be used as building blocks to large cryptosystems as we already saw in example of the encyphering scheme tscdr and also there are aad schemes that are based on either the composition paradigm of encrypt then mac or the synthetic ivy setting like scd that uses an encryption scheme inside so gcdr can be a useful component there that provides beyond background security I would also like to point out that as we know gcdr gives better security and efficiency when compared with counter mode but it requires slightly larger bandwidth and that is because of processing both nonce and ivy but in applications where the counter like mode is used as a building block and the ivy part is sometimes generated internally using the input we call it a synthetic ivy this extra bandwidth and randomness cost of gcdr can be avoided easily and we can get the security and efficiency advantage of gcdr without paying this cost of extra bandwidth I would now like to point out some possible future such directions and open problems that are raised and are left open by this research work the first one would be to design new secure and efficient fog ciphers and multifog ciphers with branches at least two this could be considered as a good opportunity in crypto community after seeing the versatile structure or nature of multifog cipher as it can be used to improve security and efficiency both in certain symmetric modes and that being said the second possible direction could be designing novel multifog cipher based modes that are not limited to the use cases of encryption or authentication encryption but can also be used in various other security settings there are certain preliminary results that shows that multifog ciphers can be good to be used in max or used for randomness instruction as well as for some privacy preserving applications with such good open problems being stated we are at the end of this presentation thank you for listening to this video of our work may the fork be with you all bye