 Good morning, good afternoon, or good evening. My name is Poltik Ektal and I'm here to present the paper A new snow stream cypher called Snow Bee and this is a joint work with Thomas Johansson, Alexander Maximov and Ying Yang. Alexander and I are from Ericsson Research and Thomas and Ying are from Lund University. The background for this work is the air encryption algorithms in the cellular networks. Today in 4G and 5G we have three core algorithms specified. The first one is based on Snow 3G, the second one is based on AES and the third one is based on Sook. They all take a 128 bit key. This works perfectly fine in 4G but in 5G there are some new system properties coming along that will affect the air encryption algorithms. Firstly we have the virtualization property. There is a lot of work going on to virtualize both the core network as well as the radio access network and for the encryption algorithms this means that in the base stations where the encryption is terminated the algorithms will have to be able to run virtualized on commodity hardware and not rely on dedicated hardware accelerations like A6. This means that algorithms need to be fast in a pure software implementation. The second thing is that 3GPP which is the standardization organization for cellular networks is looking at introducing 256 bit algorithms for the air encryption interface. So they want to raise the security level from 128 to 256. The last property is the anticipated future speed of 5G which is a downlink speed of 20 gigabits per second and maybe even higher. So taking all this into account we decided to develop Snow V which basically is a refactored version of four parallel copies of Snow 3G and it's very fast in both hardware and pure software implementation. Here is an overview of Snow V and as I said it's built on the principles of Snow 3G. At the top we have a linear feedback shift register construction that is specifically designed for vector instructions like AVX or Neon. We have two tabs T1 and T2 feeding down into the finite state machine. The finite state machine uses two full rounds of the AES round function as just large 128 bit S-boxes. That makes it possible to leverage the commonly available AES acceleration instructions found in most modern CPUs. The total state size of the cipher is 896 bits so it is larger than the previous 608 bits found in Snow 3G but still much smaller than four separate copies of Snow 3G. The increased state also provides a good security margin in order to meter higher 256 bit security level. If we take a closer look at the LFSR it consists of two different LFSRs of size 16 times 16 bits so each of these elements are 16 bit wide and there are 16 elements in each register. The two LFSR have different generating polynomials and the feedback is a novel circular construction where the next element of the LFSR is not only dependent on the feedback polynomial but also on the first element of the other register. For each update we clock the LFSRs eight times so that we get fresh tap values T1 and T2 each clocking. This circular construction is very well suited for fast software implementations using vector instructions and in the paper we have a proof that it achieves the maximum periodicity 2 to the power 512 minus 1. If we look at the finite state machine it consists of three 128 bit registers R1, R2 and R3. R2 and R3 are updated through a full AS round function using the all zero key as the round key. Basically the AS round function is acting as a 128 bit wide S box. This design can take advantage of both AS acceleration instructions in a software implementation as well as hardware resource sharing if AS is also implemented alongside as is the case in 5G. We have both 128 bit wide EXO operations and as well as addition with carry but the addition is grouped into four 32 bit additions so that the carry does not propagate the full 128 bit width. The output Z is given by R1 plus T1 EXOR R2. Another difference from Snow 3G is that we have a byte permutation sigma in the update of R1. This significantly increases the security as we will see in the coming slides and it's practically for free in a hardware implementation. Snow V takes a 256 bit key and a 128 bit IV and the shift registers are initialized according to the code in the upper red rectangle. LFSR A is initialized with the low part of the key together with the IV and the high part of LFSR B is initialized with a high 128 bit part of the key. You can notice that the lower part of register B is initialized with all zeros. Then we run the cipher in a special in acceleration mode where the output Z is fed into the feedback loop of the A register as shown in the code in the lower red rectangle. We run the cipher in this mode for 16 clocks. During the last two rounds of the initialization the key is extored to the R1 register so during round 15 the lower part of the key is extored and then during round 16 the upper part of the key is extored to R1 as shown in the code here. This represents an instantiation of the FP1 mode introduced by Haman and Kraus in 2018 and makes it harder for anyone that has obtained the state at a particular time to run the cipher backwards and obtain the starting state and thus the key. In this paper we also specify an AEAD mode, Authenticator Encryption with Additional Data. It's basically the same construction as the integrity algorithm NIA1 in 5G but the polynomial is 128 bits the same as in ASGCM. However, one important distinction from ASGCM is that the key H is fresh for every new pair of key and IV. One thing that differs from the normal operation of snow V is that the inacilization of LFSRB is a bit different. If you remember a couple of slides ago I said that the low part of B is initialized with all zeroes when used for only encryption but in the AAD mode we insert a different value in the low part of the B register and it's nothing magic, it's just the names of the authors in UTF-8 encoding. Now we look at the software implementation aspects of snow V. Here is a complete implementation of one clocking of the cipher producing a 128-bit key sprint value. It is implemented using Intel vector instructions. As you can see it's very compact. Most of the time is spent doing the LFSR update and the finite state machine update can be accomplished in just a few lines of code. This of course reflects in the software speed of the cipher. Here is a performance comparison of snow V compared to some other popular algorithms. For the comparison we have used the open SSL assembler implementation of AES256 and Chacha20. As shown snow V is about 1.5 to 1.6 times faster than AES in counter mode for plaintext longer than 256 bytes. For really short plaintext the inacelestation rounds of snow V become predominant and slows it down considerably but for longer messages we can reach almost 60 gigabytes per second. You can also see that snow 3 is unsuitable for use in a pure software implementation on the air interface encryption algorithms in 5G. It's just too slow. For the AED mode snow V performs similar to AES GCM as the chair G has core impactus performance significantly. All these tests were run on a single thread implementation on an Intel i7 CPU. For a hardware implementation of snow V it's relatively straightforward to implement it but a full implementation with 128-bit wide buses requires two full AES round functions although the key scheduling part is removed and that could be costly in some constrained environments. In the paper we show how to implement snow V using a 64-bit architecture that only requires a single AES round function implementation. We have also made estimates on how big and fast different hardware implementations of snow V would be. For reference we used a recent result on an area speed optimized AES implementation from Ueno et al in 2016. In that paper they construct an AES 110-8 bit circuit using Nungate 15 nanometer technology and the values we use here are extrapolations to get the speed of AES 256. We have values for both the 64-bit architecture as well as the full 128-bit architecture of snow V. The different columns are referring to whether the AES core is internal or externally shared with an already existing AES implementation. In both cases we assume that the AES round function is the critical path of the implementation and derive the speed using the extrapolated values from the paper by Ueno et al. For the 64-bit architecture we can reach over 350 gigabits per second and the full 128-bit architecture can do over 700 gigabits per second. Using a newer gate technology and the faster S-box construction Alexander and I presented at chess 2019 we reasonably believe snow V could reach 1 terabit per second. In the paper we also perform a security evaluation of the new cipher. Starting with initialization attacks we look at the maximum degree monomial attacks on the IV. In this attack you fixate the key bits and most of the IV bits and then you vary a number of IV bits. Then you look at the maximum degree monomial of the output bits as a function of those three IV bits. If the distribution of the MDM is random the mixing during the initialization is sufficient. In the graph to the right we have the number of three bits on the x-axis and the number of initialization rounds that produces non-random outputs. As we can see after about six rounds the IV values are properly mixed into the state. We also looked at division trails-based cube attacks using mixed linear programming. Also in this case we see that after about five rounds the key and IV are sufficiently mixed. It seems like there is a good security margin up to the total number of initialization rounds of 16. Next we look at linearization attacks. This is very hard to perform on the full cipher but we have looked at but we have looked at different simplified constructions to get some indications. If we remove the byte permutation sigma denoted sigma zero here and reduce the 32-bit addition with carry to only 8-bit addition with carry we can perform a distinguishing attack with complexity 2 to the power of 240. Using again sigma zero but the full 32-bit addition we get the complexity up to 2 to the power of 237. If we use the actual proposed sigma permutation and an 8-bit addition again the best linearization we could find gives an attack complexity of around 2 to the power of 859. In the paper we also look at time memory data trade-off attacks, algorithmic attacks and guess and determine attacks but neither of those attacks seems applicable to snow v. To be considered for standardization in 3GPP a new cipher such as snow v even if it builds on a well-known construction such as snow 3G must be evaluated by an independent group of experts. This was done during the past year and the conclusion is that the evaluators did not find any concerns and snow v achieves its design and security goals. Because snow v uses the AES round function as an s-box a natural question would be how future cryptanalysis of AES would affect snow v. The evaluators looked specifically at this question and concluded that since the usage of the round function is so very different between AES and snow v and the round key is constant it is very unlikely that future cryptanalysis of AES would affect the security of snow v. The external evaluation reports are available at this address as part of the communication to 3GPP. So to conclude a new stream cipher snow v is proposed. It solves several of the new challenges with 5G air encryption such as high speed, enhanced security level and software implementation friendliness. It reaches 58 gigabits per second on an Intel i7 laptop and is estimated to do 300 to 700 gigabits per second in a hardware implementation depending on the chosen architecture. Apart from the cryptanalysis done in the presented paper here snow v has also been evaluated by independent external crypto experts. So thank you and we hope you'll find good use of this new stream cipher.