Protocol++® (Protocolpp®)  v5.6.2
jsnow3g Class Reference

#include "include/jsnow3g.h"

Detailed Description

Snow3g Stream Cipher

See also
Specification of the 3GPP Confidentiality and Integrity Algorithms UEA2 and UIA2 Document 2: SNOW 3G Specification

SNOW 3G is a word-oriented stream cipher that generates a sequence of 32-bit words under the control of a 128-bit key and a 128-bit initialisation variable. These words can be used to mask the plaintext. First a key initialisation is performed, i.e. the cipher is clocked without producing output, see 4.1. Then with every clock tick it produces a 32-bit word of output

Functions used in different Components of SNOW 3G

MULx maps 16 bits to 8 bits. Let V and c be 8-bit input values. Then MULx is defined:

If the leftmost (i.e. the most significant) bit of V equals 1, then

$ MULx(V, c) = (V <<_8 1) \oplus c, else MULx(V, c) = V <<_8 1$

MULxPOW maps 16 bits and an positive integer i to 8 bit. Let V and c be 8-bit input values, then MULxPOW(V, i, c) is recursively defined:

If i equals 0, then $ MULxPOW(V, i, c) = V$, else $ MULxPOW(V, i, c) = MULx(MULxPOW(V, i-1, c), c)$

Linear Feedback Shift Register (LFSR)

The Linear Feedback Shift Register (LFSR) consists of sixteen stages $ s_0, s_1, s_2,\cdots, s_{15}$ each holding 32 bits

Finite State Machine (FSM)

The Finite State Machine (FSM) has three 32-bit registers R1, R2 and R3. The S-boxes S1 and S2 are used to update the registers R2 and R3

The 32x32-bit S-Box S1

The S-Box $ S_1$ maps a 32-bit input to a 32-bit output. Let $ w = w_0 || w_1 || w_2 || w_3$ the 32-bit input with $ w_0$ the most and $ w3$ the least significant byte

Let $ S_1(w)= r_0 || r_1 || r_2 || r_3$ with $ r_0$ the most and $ r_3$ the least significant byte. We use the 8 to 8 bit Rijndael S-Box $ S_R$ defined in 5.1

Then $ r_0, r_1, r_2, r_3$ are defined as

$ r_0= MULx(S_R(w_0), 0x1B) \oplus S_R(w_1) \oplus S_R(w_2) \oplus MULx(S_R(w_3), 0x1B) \oplus S_R(w_3)$

$ r_1= MULx(S_R(w_0), 0x1B) \oplus S_R(w_0) \oplus MULx(S_R(w_1), 0x1B) \oplus S_R(w_2) \oplus S_R(w_3)$

$ r_2= S_R(w_0) \oplus MULx(S_R(w_1), 0x1B) \oplus S_R(w_1) \oplus MULx(S_R(w_2), 0x1B) \oplus S_R(w_3)$

$ r_3= S_R(w_0) \oplus S_R(w_1) \oplus MULx(S_R(w_2), 0x1B) \oplus S_R(w_2) \oplus MULx(S_R(w_3), 0x1B)$

The 32x32-bit S-Box S2

The S-Box $ S_2$ maps a 32-bit input to a 32-bit output. Let $ w = w_0 || w_1 || w_2 || w_3$ the 32-bit input with $ w_0$ the most and $ w_3$ the least significant byte. Let $ S_2(w)= r_0 || r_1 || r_2 || r_3$ with $ r0$ the most and $ r3$ the least significant byte. We use the 8 to 8 bit S-Box $ S_Q$ defined in 5.2

Then $ r_0, r_1, r_2, r_3$ are defined as

$ r_0= MULx(S_Q(w_0), 0x69) \oplus S_Q(w_1) \oplus S_Q(w_2) \oplus MULx(S_Q(w_3), 0x69) \oplus SQ(w3)$

$ r_1= MULx(S_Q(w_0), 0x69) \oplus S_Q(w_0) \oplus MULx(S_Q(w_1), 0x69) \oplus S_Q(w_2) \oplus S_Q(w_3)$

$ r_2= S_Q(w_0) \oplus MULx(S_Q(w_1), 0x69) \oplus S_Q(w_1) \oplus MULx(S_Q(w_2), 0x69) \oplus S_Q(w_3)$

$ r_3= S_Q(w_0) \oplus S_Q(w_1) \oplus MULx(S_Q(w_2), 0x69) \oplus S_Q(w_2) \oplus MULx(S_Q(w_3), 0x69)$

The Clocking Operations

Clocking the LFSR

The clocking of the LFSR has two different modes of operation, the Initialisation Mode 3.4.4 and the Keystream Mode 3.4.5. In both modes the functions $ MUL_α$ and $ DIV_α$ are used which are defined in 3.4.2 resp. 3.4.3

The function $ MUL_α$

The function $ MUL_α$ maps 8 bits to 32 bits. Let c be the 8-bit input, then $ MUL_α$ is defined as

$ MUL_α(c) = (MULxPOW(c, 23, 0xA9) || MULxPOW(c, 245, 0xA9) || MULxPOW(c, 48, 0xA9) || MULxPOW(c, 239, 0xA9))$

The function $ DIV_α$

The function $ DIV_α$ maps 8 bits to 32 bits. Let c be the 8-bit input, then $ DIV_α$ is defined as

$ DIV_α(c) = (MULxPOW(c, 16, 0xA9) || MULxPOW(c, 39, 0xA9) || MULxPOW(c, 6, 0xA9) || MULxPOW(c, 64, 0xA9))$

Initialisation Mode

In the Initialisation Mode the LFSR receives a 32-bit input word F, which is the output of the FSM

Let $ s_0 = s_{0,0} || s_{0,1} || s_{0,2} || s_{0,3}$ with $ s_{0,0}$ being the most and $ s_{0,3}$ being the least significant byte of $ s_0$.

Let $ s_{11} = s_{11,0} || s_{11,1} || s_{11,2} || s_{11,3}$ with $ s_{11,0}$ being the most and $ s_{11,3}$ being the least significant byte of $ s_{11}$

Compute the intermediate value v as

$ v = (s_{0,1} || s_{0,2} || s_{0,3} || 0x00) \oplus MUL_α(s_{0,0}) \oplus s_2 \oplus (0x00 || s_{11,0} || s_{11,1} || s_{11,2}) \oplus DIV_α(s_{11,3}) \oplus F$

Set

$ s_0=s_1, s_1=s_2, s_2=s_3, s_3=s_4, s_4=s_5, s_5=s_6, s_6=s_7, s_7=s_8$

$ s_8=s_9, s_9=s_{10}, s_{10}=s_{11}, s_{11}=s_{12}, s_{12}=s_{13}, s_{13}=s_{14}, s_{14}=s_{15}, s_{15} = v$

Keystream Mode

In the Keystream Mode the LFSR does not receive any input

Let $ s_0 = s_{0,0} || s_{0,1} || s_{0,2} || s_{0,3}$ with $ s_{0,0}$ being the most and $ s_{0,3}$ being the least significant byte of $ s_0$

Let $ s_11 = s_{11,0} || s_{11,1} || s_{11,2} || s_{11,3}$ with $ s_{11,0}$ being the most and $ s_{11,3}$ being the least significant byte of $ s_11$

Compute the intermediate value v as

v = $ (s_{0,1} || s_{0,2} || s_{0,3} || 0x00) \oplus MUL_α(s_{0,0}) \oplus s_2 \oplus (0x00 || s_{11,0} || s_{11,1} || s_{11,2}) \oplus DIV_α(s_{11,3})$

Set

$ s_0=s_1, s_1=s_2, s_2=s_3, s_3=s_4, s_4=s_5, s_5=s_6, s_6=s_7, s_7=s_8$

$ s_8=s_9, s_9=s_{10}, s_{10}=s_{11}, s_{11}=s_{12}, s_{12}=s_{13}, s_{13}=s_{14}, s_{14}=s_{15}, s_{15}=v$

Clocking the FSM

The FSM has two input words $ s_{15}$ and $ s_5$ from the LFSR. It produces a 32-bit output word F:

$ F = (s_{15} \oplus R1) \oplus R2$

Then the registers are updated. Compute the intermediate value r as

$ r = R2 \oplus (R3 \oplus s_5)$

Set

$ R3 = S_2(R2)$

$ R2 = S_1(R1)$

$ R1 = r$

Operation of SNOW 3G

Initialisation

SNOW 3G is initialized with a 128-bit key consisting of four 32-bit words $ k_0, k_1, k_2, k_3$ and an 128-bit initialisation variable consisting of four 32-bit words $ IV_0, IV_1, IV_2, IV_3$ as follows

Let 1 be the all-ones word (0xffffffff)

$ s_{15}=k_3 \oplus IV_0$

$ s_{14}=k_2$

$ s_{13}=k_1$

$ s_{12}=k_0 \oplus IV_1$

$ s_{11}=k_3 \oplus 1$

$ s_{10}=k_2 \oplus 1 \oplus IV_2 s_9 = k_1 \oplus 1 \oplus IV_3 s_8 = k_0 \oplus 1$

$ s_7=k_3$

$ s_6=k_2$

$ s_5=k_1$

$ s_4=k_0$

$ s_3=k_3 \oplus 1$

$ s_2=k_2 \oplus 1$

$ s_1=k_1 \oplus 1$

$ s_0=k_0 \oplus 1$

The FSM is initialised with $ R1 = R2 = R3 = 0$

Then the cipher runs in a special mode without producing output:

repeat 32-times {

STEP 1: The FSM is clocked (see 3.4.6) producing the 32-bit word F

STEP 2: Then the LFSR is clocked in Initialisation Mode (see 3.4.4) consuming F

}

Snow 3G Algorithm During Initialization

Generation of Keystream

First the FSM is clocked once, see 3.4.6. The output word of the FSM is discarded. Then the LFSR is clocked once in Keystream Mode, see 3.4.4

After that n 32-bit words of keystream are produced:

for t = 1 to n {

STEP 1: The FSM is clocked (see 3.4.6) and produces a 32-bit output word F

STEP 2: The next keystream word is computed as $ z_t = F \oplus s_0$

STEP 3: Then the LFSR is clocked in Keystream Mode, see 3.4.4

}

Snow 3G Algorithm During Key-Stream Generation

The Rijndael S-box $ S_R$

The S-box SR maps 8 bit to 8 bit. Here the input and output is presented in hexadecimal form

Let $ x_0, x_1, y_0, y_1$ be hexadecimal digits with $ S_R(x_0 {2}^{4}+x_1) = y_0 {2}^{4} + y_1$, then the cell at the intersection of the $ {x_0}^{th}$ row and the $ {x_1}^{th}$ column contains the values for $ y_0 || y_1$ in hexadecimal form

For example $ S_R(42) = S_R(0x2A) = 0xE5 = 229$

Rijndael S-Box

The S-box $ S_Q$

The S-box $ S_Q$ maps 8 bit to 8 bit. Here the input is presented in hexadecimal form

Let $ x_0, x_1, y_0, y_1$ be hexadecimal digits with $ S_Q(x_0 {2}^{4}+x_1) = y_0 {2}^{4} + y_1$, then the cell at the intersection of the $ {x_0}^{th}$ row and the $ {x_1}^{th}$ column contains the values for $ y_0 || y_1$ in hexadecimal form

For example $ S_Q(42) = S_Q(0x2A) = 0xAC = 172$

S-Box SQ

For API Documentation:

See also
ProtocolPP::jarray
ProtocolPP::jsnow3g
ProtocolPP::jmodes
ProtocolPP::jconfident
ProtocolPP::jintegrity

For Additional Documentation:

See also
jarray
jsnow3g
jmodes
jconfident
jintegrity
Protocol++® (ProtocolPP®) written by : John Peter Greninger • © John Peter Greninger 2015-2024 • All Rights Reserved
All copyrights and trademarks are the property of their respective owners

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: