Evolution of the StreamHash hash function family

This paper describes the evolution of StreamHash cryptographic hash function family proposed by the author. The (cid:12)rst member of the StreamHash family was StreamHash (now called StreamHash1) function, accepted for the (cid:12)rst round of SHA-3 competition organized by the US government standards agency NIST y . The competition has been started in order to select a new SHA-3 standard as the successor of SHA-2 family of cryptographic hash functions. Function StreamHash2 mostly addresses security weaknesses identi(cid:12)ed during the SHA-3 competition, while the sketch of function StreamHash3 attempts to improve resistance to side-channel attacks and performance properties. The paper starts with an overview of basic properties of cryptographic hash functions followed by the description of the StreamHash family design principles and its basic structure. Subsequent sections illustrate the way each subsequent function uses lessons learnt while designing and testing the previous one.

message can be efficiently computed, i.e. h(m) value can be easily computed for any given message m.
The following main security properties are required: (1) It is not practically feasible to find a message transformed into a given hash (also known as preimage), i.e. for any given h(m) value it is infeasible to find a corresponding message m. This property is called preimage resistance. (2) It is not practically feasible to modify a message without changing its hash, i.e. for any given m 1 message it is infeasible to find another m 2 message (also known as the second preimage) such that h(m 1 ) = h(m 2 ). This property is called second preimage resistance. (3) It is not practically feasible to find two different messages with the same hash, i.e. it is infeasible to find two different messages m 1 and m 2 (also known as collision) such that h(m 1 ) = h(m 2 ). This property is called collision resistance.
Some auxiliary properties are also often required: (1) The hash function output should be indistinguishable from random numbers, so they can be used as a foundation for keystream generators.
For example SSL and TLS [1] protocols use a mix of MD5 and SHA-1 to produce a sufficient number of master secret bits from an initial premaster secret and exchanged random values.
(2) The function should be resilient to length-extension attacks: given h(m 1 ) and len(m 1 ), but not m 1 itself, it should not be practically feasible to calculate h(m 1 ∥padding∥m 2 ). This property can be used to break naive authentication schemes based on the hash functions. The HMAC ‡ [2] construction works around these problems.
Practical infeasibility should not be confused with theoretical computational complexity measures such as time or memory consumption. Theoretical measures cover either best, worst or average complexity. For cryptographic applications it is acceptable to violate any of the above properties as long as the probability of failure is negligible.
Cryptographic hash functions are often mistaken for checksums such as CRC32, only designed to detect accidental and not intentional modification of data.
Applications of cryptographic hash functions include: • Digital signatures.
• User or device authentication. ‡

Design rationale
Commonly used cryptographic hash functions are based on the Merkle-Damgård construction. The input message is processed in blocks. The message needs to be padded, so the length of the padded message is a multiple of the block size. Further processing is performed with a compression function. The function takes two inputs: a chaining variable and a message block. Compression function outputs the next value of the chaining variable. Each block of a padded message is iteratively processed with a compression function, starting with a predefined initial value of the chaining variable.
Compression function is performed in several rounds in order to provide required cryptographic properties. Each round only performs non-trivial (e.g. non-linear) operations on a subset of the chaining variable, while the remaining part is merely shifted. This is why multiple rounds are needed to achieve the avalanche effect, so that every bit of output depends on every bit of input of the compression function.
The approach of the StreamHash family is completely different. Instead of achieving the avalanche effect with multiple rounds, it directly updates the state vector on each octet of the input stream.
The structure of the StreamHash family is based on a well-known problem of solving a set of non-linear equations or CSP § . Common algorithms for solving CSPs [3] include backtracking, constraint propagation, and local search. The StreamHash family is designed, so that these algorithms cannot be applied. This property is ensured by the clear separation of the constraints. Solving a subset of all constraints does not make solving remaining constraints any easier.
No security proof is provided for the StreamHash family. Specifically no reduction from CSP or any other NP-complete problem has been demonstrated.

NLF transformation
The main building block of StreamHash family is a fast non-linear transformation NLF (Non-Linear Function). Figure 1 illustrates inputs and outputs of the NLF transformation.

Structure
See Figure 2 for the diagram of the StreamHash family structure. A separate transformation is also applied in the finalization phase. Finalization is designed to prevent the length-extension attacks and to improve statistical properties of the output.

Advantages of the StreamHash family
The main advantages of the StreamHash family are: • Clear and easy to analyze design.
• Negligible performance impact of machine endianness.
• High performance on 8-bit and 16-bit architectures.
• Easy to parallelize internal structure with theoretical performance up to a single clock cycle per input octet. • Fast finalization resulting in low latency. This property is extremely important in real-time (e.g. multimedia) applications. • Fast finalization resulting in high throughput for short messages.
• Minimal size of code, important for embedded systems.
• Minimal size of variables, important for embedded systems.
• Low size of static data.
• Scalability to use any multiple of 32 bits as the hash value length.

Limitations of the StreamHash family
The mathematical background is also not well studied in cryptographic applications. While this is not a direct weakness, extensive cryptanalysis is essential to trust a cryptographic primitive.

Motivation
The StreamHash [4] (now called StreamHash1) algorithm was accepted for the first round of SHA-3 competition organized [5] NIST.
The main motivation for StreamHash1 was to demonstrate security of performance properties of the StreamHash family. The function was designed to be as simple as possible in order to simplify its cryptoanalysis. Specifically, no constants or transformations were included without a clear security rationale.
As an early and immature design, StreamHash suffered from severe security weaknesses. At initialization the state vector is set to zero.

State update algorithm
StramHash2 NLF transformation works by adding (modulo 2 32 ) an S-BOX output to the state vector value. The S-BOX index is computed as: The resulting formula to update a state vector value for the index i is: Any remaining input data bits (for input size not being a multiple of 8 bits), and the number of these bits are both saved within the state structure. Figure 3 illustrates the internal structure of the StreamHash1 NLF transformation.
The content of the StreamHash S-BOX computed using the above formula is listed in Table 1.

Cryptanalysis
The third-party cryptanalysis is available for the StreamHash1 function, the first function of the StreamHash family. Dmitry Khovratovich and Ivica Nikolić from University of Luxembourg reviewed cryptographic properties of StreamHash [6]. Joux attack [7] was applied with the theoretical complexity of n 2 2 n/4 for finding collisions and n 2 2 n/2 for finding preimages.
Tor E. Bjorstad, a PhD student of Computer Science, University of Bergen, Norway implemented [8] a practical collision attack against the StreamHash1 function.

Motivation
The StreamHash2 algorithm was designed to address identified weaknesses of the original StreamHash1 function.

Algorithm updates
The following changes were implemented in the StreamHash2 function compared to the original StreamHash1: • NLF transformation was modified with a 32-bit output of PRNG ∥ in order to prevent from the re-use of any identified collision of a single state word. • ⊕ operation was replaced with (addition modulo 2 32 ) in order to propagate changes between the four octets of the 32-octet state word.
• Finalization phase was updated to improve resistance against lengthextension attacks and statistical properties.

Advanced Encryption Standard
The improved formula to update a state vector value for the index i is: StreamHash2 shares all other parts of the StreamHash2 design described above, e.g. the S-BOX table. Figure 4 illustrates the internal structure of the StreamHash2 NLF transformation.

Pseudo-random number generator
The StreamHash2 function uses a 64-bit version of the pseudo-random number generator Xorshift [9] as its PRNG transformation. The generator provides the period of 2 64 − 1. PRNG is not expected to be cryptographically secure, and security of StreamHash2 is not based on the PRNG properties other than its period.
The following algorithm is used to generate each 32-bit value of r c : (1) s ← s ⊕ (s ≪ 13).
(4) Return r c as the least significant 32 bits of s.
The 64-bit PRNG state s is initialized with the seed value of 88172645463325252. This starting value is a constant recommended by the author of the Xorshift algorithm.

Identified limitations of StreamHash2
Identified disadvantages of StreamHash2 are mostly the result of S-BOX lookup: • Side-channel attacks [10] on multiasking software implementations based on the CPU cache timings. • Not possible to compute with the SIMD * * instructions on x86 architecture. • Expensive hardware implementation (high number of gates).