#include "include/jsnowv.h"

Detailed Description

SNOW-V Stream Cipher

See also: "A new SNOW stream cipher called SNOW-V by Ekdahl et al"; 3GPP TS 33.102

The SNOW family of stream ciphers started with the SNOW proposal in European project NESSIE, a call for new primitives. Two attacks were soon discovered and the design was subsequently updated to the SNOW 2.0 design. Attacks on SNOW 2.0 will be covered in more detail in Section 3. The ETSI Security Algorithm Group of Experts (SAGE) modified the SNOW 2.0 design and proposed the resulting cipher SNOW 3G as one of the algorithms protecting the air interface in 3GPP telecommunication networks

Although sufficient for 4G systems, these 128-EIAx and 128-EEAx algorithms face some challenges in the 5G environment. For the 5G system, the 3GPP standardization organization is looking towards increasing the security level to 256-bit key lengths. For ExA1, and ExA2, this does not immediately appear to be a problem, since both the underlying primitives (AES and SNOW) are specified for 256-bit keys. ZUC is currently only specified and evaluated under 128-bit key strength, but another version, ZUC-256, supporting 256-bit keys has recently been presented. However, since the design of the radio and core network will also fundamentally change in the 5G system, there are other challenges. Many of the network nodes will become virtualized and thus the ability to use specialized hardware for the cryptographic primitives will be reduced. Many newer processors from both Intel and ARM no include instructions to accelerate AES but for the stream ciphers SNOW and ZUC, we need to look for other solutions. Current benchmarks on SNOW 3G gives approximately 9 Gbps in pure software implementation, which is far too low for the targeted speed of 20 Gbps downlink in the 5G system

This is a revised SNOW 2.0 / SNOW 3G design to be competitive in a pure software environment, relying on both the acceleration instructions for the AES round function as well as the ability of modern CPUs to handle large vectors of integers (e.g. SIMD instructions). We have kept most of the design from SNOW 3G, in terms of linear feedback shift register (LFSR) and the Finite State Machine (FSM), but both entities are updated to better align with vectorized implementations. We have also increased the total state size by going from 32-bit registers to 128-bit registers in the FSM. Each clocking of SNOW-V (V for Virtualization) now produces 128 bits of keystream

This also proposes an AEAD (Authenticated Encryption with Associated Data) operational mode to provide both confidentiality and integrity protection. The keystream width of 128 bits makes the authentication framework of GMAC very easy to adopt to SNOW-V

The design

SNOW-V follows the design pattern of previous SNOW versions and consists of a LFSR part and an FSM part. The overall schematic is show in Figure 1. The LFSR is now a circular construction consisting of two shift registers, each feeding into the other. The FSM has three 128-bit registers and two instances of a single AES encryption round function

The two LFSRs are named LFSR-A and LFSR-B, both of length 16 and with a cell size of 16-bits. The 32 cells are denoted ${a}_{15}...{a}_{0}$ and ${b}_{15}...{b}_{0}$ respectively

The elements of LFSR-A are generated by the polynomial

${g}^{A}(x) = {x}^{16}+{x}^{15}+{x}^{12}+{x}^{11}+{x}^{8}+{x}^{3}+{x}^{2}+x+1$

and the elements of LFSR-B are generated by

${g}^{B}(x) = {x}^{16}+{x}^{15}+{x}^{14}+{x}^{11}+{x}^{8}+{x}^{6}+{x}^{5}+x+1$

AEAD mode of operation

The GMAC integrity and authentication algorithm can easily be adopted to work with SNOW-V to define an AEAD mode of operation. In GCM, an unspecified block cipher is used in counter mode to encrypt the plaintext. Additionally, the block cipher is used to produce the final authentication tag T, and to derive the key H used in the function ${GHASH}_{H}$

When using SNOW-V together with the ${GHASH}_{H}$ algorithm, the key H is the very first keystream output ${z}^{(0)}$ . The we use keystream output ${z}^{(1)}$ as the final masking for the tag, similarly to the encrypted value of ${J}_{0}$ . To encrypt the n plaintext blocks, we use the keystream ${z}^{(2)}...,{z}^{(n-1)}$ , feeding the ciphertext blocks into ${GHASH}_{H}$

SNOW-V AEAD works as described in Section 2 with a single change. During initialization of the LFSRs, we set the lower part of the LFSR-B to the following hex values:

$({b}_{7},{b}_{6},...,{b}_{0}) = (0x6D6F,0x6854,0x676E,0x694A,0x2064,0x6B45,0x7865,0x6C41)$

The hex values are the UTF8 encoding of the names of the authors

An overview of how SNOW-V is used together with ${GHASH}_{H}$ algorithm is shown in Figure 6 The padding of the Additional Authenticated Data (AAD) and how to concatenate the length of

the AAD and the length of the ciphertext C and all other restrictions on plaintext length and change the IV remain. We have only defined a new way to derive the counter mode keystream, and the additional key and tag mask needed in the GCM algorithm

For API Documentation:

See also: ProtocolPP::jarray; ProtocolPP::jsnowv; ProtocolPP::jmodes; ProtocolPP::jconfident; ProtocolPP::jintegrity

For Additional Documentation:

See also: jarray; jsnowv; jmodes; jconfident; jintegrity

The source code contained or described herein and all documents related to the source code (herein called "Material") are owned by John Peter Greninger and Sheila Rocha Greninger. Title to the Material remains with John Peter Greninger and Sheila Rocha Greninger. The Material contains trade secrets and proprietary and confidential information of John Peter Greninger and Sheila Rocha Greninger. The Material is protected by worldwide copyright and trade secret laws and treaty provisions. No part of the Material may be used, copied, reproduced, modified, published, uploaded, posted, transmitted, distributed, or disclosed in any way without prior express written consent of John Peter Greninger and Sheila Rocha Greninger (both are required)

No license under any patent, copyright, trade secret, or other intellectual property right is granted to or conferred upon you by disclosure or delivery of the Materials, either expressly, by implication, inducement, estoppel, or otherwise. Any license under such intellectual property rights must be express and approved by John Peter Greninger and Sheila Rocha Greninger in writing

Licensing information can be found at www.protocolpp.com/license with use of the binary forms permitted provided that the following conditions are met:

Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution
Any and all modifications must be returned to John Peter Greninger at GitHub.com https://github.com/jpgreninger/protocolpp for evaluation. Inclusion of modifications in the source code shall be determined solely by John Peter Greninger. Failure to provide modifications shall render this license NULL and VOID and revoke any rights to use of Protocol++®
Commercial use (incidental or not) requires a fee-based license obtainable at www.protocolpp.com/shop
Academic or research use requires prior written and notarized permission from John Peter and Sheila Rocha Greninger

Use of the source code requires purchase of the source code. Source code can be purchased at www.protocolpp.com/shop

US Copyrights at https://www.copyright.gov/
- TXu002059872 (Version 1.0.0)
- TXu002066632 (Version 1.2.7)
- TXu002082674 (Version 1.4.0)
- TXu002097880 (Version 2.0.0)
- TXu002169236 (Version 3.0.1)
- TXu002182417 (Version 4.0.0)
- TXu002219402 (Version 5.0.0)
- TXu002272076 (Version 5.2.1)
- TXu002383571 (Version 5.4.3)

The name of its contributor may not be used to endorse or promote products derived from this software without specific prior written permission and licensing

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDER AND CONTRIBUTOR "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE

The documentation for this class was generated from the following file:

include/jsnowv.h