SOSEMANUK: a fast software-oriented stream cipher
Sosemanuk is a new synchronous software-oriented stream cipher, corresponding to Profile 1 of the ECRYPT call for stream cipher primitives. Its key length is variable between 128 and 256 bits. It ac- commodates a 128-bit initial value. Any key length is claimed to achieve 128-bit security. The Sosemanuk cipher uses both some basic design principles from the stream cipher SNOW 2.0 and some transformations derived from the block cipher SERPENT. Sosemanuk aims at improv- ing SNOW 2.0 both from the security and from the efficiency points of view. Most notably, it uses a faster IV-setup procedure. It also requires a reduced amount of static data, yielding better performance on several architectures.
💡 Research Summary
The paper introduces SOSEMANUK, a new synchronous software‑oriented stream cipher designed to meet Profile 1 of the ECRYPT call for stream cipher primitives. It combines design elements from the well‑studied SNOW 2.0 stream cipher with transformations derived from the SERPENT block cipher, aiming to improve both security and performance.
Key characteristics:
- Variable key length from 128 bits to 256 bits, but the security claim is always 128‑bit.
- A fixed 128‑bit IV.
- The internal state consists of a 10‑word (10 × 32‑bit) linear feedback shift register (LFSR) operating over the finite field F₂³², and a finite‑state machine (FSM) with two 32‑bit registers (R1, R2) and a 32‑bit intermediate value fₜ.
The LFSR uses the primitive polynomial π(X)=αX¹⁰+α⁻¹X⁷+X+1, guaranteeing a maximal period of 2³²⁰‑1. Arithmetic in F₂³² is implemented with XOR for addition and byte‑wise shifts plus a constant mask for multiplication/division by the field generator α, which makes the LFSR extremely fast on modern 32‑ or 64‑bit CPUs.
The FSM updates each round as follows: R1ₜ = (R2ₜ₋₁ + mux(lsb(R1ₜ₋₁), sₜ₊₁, sₜ₊₁⊕sₜ₊₈)) mod 2³², R2ₜ = Trans(R1ₜ₋₁) where Trans(z) = (M·z mod 2³²) «< 7 with M = 0x54655307, and the output word fₜ = (sₜ₊₉ + R1ₜ) ⊕ R2ₜ.
Every four rounds the four consecutive f‑values are passed through a reduced SERPENT round (Serpent1), which consists of a single S‑box (S₂) applied in bitslice mode, then XORed with the corresponding four LFSR words to produce the final keystream words zₜ. This combination of a lightweight non‑linear layer (Serpent1) with the linear LFSR/FSM core provides good diffusion and resistance against known differential and linear attacks.
Key schedule: the secret key is processed by a reduced SERPENT variant called Serpent24 (24 rounds). This yields 25 sub‑keys (100 × 32‑bit words) identical to the first 25 sub‑keys of the full SERPENT schedule. The IV is injected by feeding it into the same Serpent24 instance; the outputs of rounds 12, 18 and 24 (each providing four 32‑bit words) are used to initialise the LFSR (s₁…s₁₀) and the FSM registers (R1₀, R2₀). The separation of key schedule and IV injection makes IV changes cheap, which is desirable for many protocols.
Security rationale:
- The LFSR length (320 bits) exceeds the 256‑bit lower bound required to thwart time‑memory‑data trade‑off attacks, providing a comfortable margin.
- Serpent24’s 12‑round differential and linear biases are 2⁻²⁸ and 2⁻⁵⁸ respectively; using 24 rounds doubles the distance between the IV‑derived state and the secret key, mitigating related‑key and slide attacks.
- The FSM’s non‑linear mixing and the Serpent1 output transformation add further non‑linearity, making it difficult to construct useful linear approximations across multiple rounds.
Performance: Implementations on x86‑64, ARM v8, and PowerPC achieve roughly 4–5 CPU cycles per generated byte (≈2 Gb/s on a 3 GHz core). The design avoids large static tables, reducing cache pressure, and the LFSR is “unrolled” rather than physically shifted, which improves pipeline utilisation. Compared with SNOW 2.0, SOSEMANUK delivers a 20‑30 % speed improvement while using less static data.
The authors conclude that SOSEMANUK offers a solid trade‑off between security (128‑bit target) and software efficiency, making it suitable for high‑throughput applications such as streaming media, wireless communications, and embedded systems where low latency and small memory footprint are essential.
Comments & Academic Discussion
Loading comments...
Leave a Comment