The Usage of Counter Revisited: SecondPreimage Attack on New Russian Standardized Hash Function
Abstract
Streebog is a new Russian hash function standard. It follows the HAIFA framework as domain extension algorithm and claims to resist recent generic secondpreimage attacks with long messages. However, we demonstrate in this article that the specific instantiation of the HAIFA framework used in Streebog makes it weak against such attacks. More precisely, we observe that Streebog makes a rather poor usage of the HAIFA counter input in the compression function, which allows to construct secondpreimages on the full Streebog512 with a complexity as low as \(n \times 2^{n/2}\) (namely \(2^{266}\)) compression function evaluations for long messages. This complexity has to be compared with the expected \(2^{512}\) computations bound that an ideal hash function should provide. Our work is a good example that one must be careful when using a design framework for which not all instances are secure. HAIFA helps designers to build a secure hash function, but one should pay attention to the way the counter is handled inside the compression function.
Keywords
Streebog Cryptanalysis Secondpreimage attack Diamond structure Expandable message HAIFA1 Introduction

Collision Resistance: it should be computationally infeasible for an adversary to find a pair of distinct messages that have the same hash digest.

SecondPreimage Resistance: for any given message \(M\), it should be computationally infeasible for an adversary to find a distinct message \(M'\) that leads to the same hash digest than \(M\).

Preimage Resistance: for any given hash digest \(h\), it should be computationally infeasible for an adversary to find a message \(M\) that leads to the hash digest \(h\).
A cryptographic hash function is commonly built by iterating a fixed inputlength function called compression function in order to handle arbitrarily long messages, and the iteration algorithm is referred to as domain extension. In this article, we mainly discuss the domain extension schemes for cryptographic hash functions, and consider the compression function as an ideal component.
Generic Attacks. The wellknown MerkleDamgård scheme [13, 26] has been the most popular domain extension scheme in order to build a hash function, e.g., MD5, SHA1 and SHA2 are built upon such design strategy. However, since 2004, several weaknesses of MerkleDamgård scheme have been discovered. In particular, Kelsey and Schneier published a generic secondpreimage attack for long messages against the MerkleDamgård scheme [23] in 2005. The attack complexity is roughly \(2^{nk}\) compression function calls if the original given message is \(2^{k}\)block long, with \(k\le n/2\). Later, Andreeva et al. gave an alternative attack using a diamond structure [3]. Their attack also require \(2^{nk}\) compression function calls if the original given message is \(2^{k}\)block long, but only for \(k\le n/3\). On the other hand, it is applicable to a wider range of designs; in particular it can accommodate a small dithering input in the compression function. It also gives some more freedom to the adversary: as mentioned in [3], this variant allows “the attacker to leave most of the target message intact in the second preimage, or to arbitrarily choose the contents of roughly the first half of the second preimage, while leaving the remainder identical to the target message.”
Therefore, regardless of how the compression function is designed, a MerkleDamgård hash function can simply not achieve the security of \(2^n\) with respect to secondpreimage resistance. Consequently, the research community designed new domain extension schemes in order to overcome the inherent weaknesses of the original MerkleDamgård construction. In their original secondpreimage attack, Kelsey and Schneier already suggest this approach, and mention that “XORing in a monotomic counter as part of the round function would resist the attacks”. Later, Biham and Dunkelman proposed the HAIFA domain extension scheme [7], which became quite popular. The main feature of HAIFA is that it adds a counter (which corresponds to the number of previously hashed message bits) as an extra input parameter to the compression function during the iteration process, in order to make each compression function call different. On the one hand, this is widely believed to provide resistance against secondpreimage attacks, and this can be proved under strong randomness assumptions for the compression function [10]. On the other hand, this means the compression function must accept an extra input, which must be processed securely to avoid security issues. In particular, compression function attacks can take advantage of this input [4, 9, 16, 19], even though the effect on the iterated function is not obvious. Recently, many new dedicated hash functions have been designed following the HAIFA framework, including some SHA3 candidates (BLAKE [5], ECHO [6], Shavite3 [8], Shabal [12], Skein [14]), as well as Streebog, which has been standardized by the Russian government as GOST R 34.112012 [27] and by IETF as RFC 6896 [20].
Our Contributions. In this article, we focus on the security of Streebog hash function with respect to the secondpreimage resistance. According to the designers, Streebog is based on the HAIFA framework, and is explicitly claimed to resist secondpreimage attacks with long message [17, 30]^{1}.
While we are not aware of any generic secondpreimage attack on the HAIFA framework, we emphasize that HAIFA acts as a generic framework, without explicitly specifying how the counter should be involved in the compression function computation. On the other hand, Streebog, as an instantiation of the HAIFA framework, has fully specified the way how the counter is used inside the compression function. This instantiation is quite provocative as the counter is simply XORed to the internal state variable of the compression function. Thus, it is necessary to evaluate whether this simple approach is sound or not (at least with respect to the secondpreimage resistance). This analysis will also shed some light on the statement of Kelsey and Schneier that “XORing in a monotomic counter” is sufficient to avoid those attacks.
Unfortunately, we show in this article that Streebog’s method to incorporate the counter does not strengthen its security with respect to secondpreimage resistance. More precisely, we observe that during the sequential iteration of the compression function, the counter injection at block \(i\) interacts with the counter injection at next block \(i+1\). The iteration of the compression function in Streebog can then be transformed into an equivalent form, for which a counterindependent function is used multiple times during the hashing process. This behavior reduces to almost zero the extra security brought by the HAIFA framework over the regular MerkleDamgård construction. Thanks to our findings, we describe two secondpreimage attacks on the full Streebog512. In Sect. 4, we give an attack using a diamond structure, similar to the attack of [3]. It requires about \(2^{342}\) compression function evaluations for long messages with at least \(2^{179}\) blocks. In Sect. 5, we give attack using an expandable message, similar to the attack of [23]. It requires only \(2^{266}\) compression function evaluations for long messages with at least \(2^{259}\) blocks. For short messages of \(2^{x}\) blocks, the first attack gives a complexity of about \(2x \cdot 2^{512x}\) when \(x < 179\), while the second attack gives a complexity of about \(2^{523x}\) when \(x < 259\). Note that this increases linearly with the decrease of the message block length (ignoring the logarithmic factor).
The rest of the article is organized as follows. In Sect. 2, we provide a description of the Streebog hash function, and then discuss our main observation on the usage of the counter value in Sect. 3. We detail how this observation can be used in order to mount secondpreimage attacks of the full Streebog512 hash function in Sect. 4 (using a diamond structure), and in Sect. 5 (using an expandable message). Finally, we draw conclusions in Sect. 6.
2 Specifications of Streebog
2.1 Domain Extension of Streebog
Streebog is a family of two hash functions, Streebog256 and Streebog512 that has hash output sizes 256 and 512 bits respectively [20, 27]. In this article, we only consider the large version Streebog512 and we simply refer to it as Streebog.
During the computation process, Streebog updates the internal state \(h\) as well as two other internal variables: \(\varSigma \) that denotes the checksum of the message blocks already processed, and the counter \(N\) that refers to the number of already hashed bits. Both the message block size and the intermediate hash variable size are 512 bits. The dedicated domain extension consists of three stages that we describe below (see also Fig. 1). Let \(M\) be the input message, and we denote \(M\) its bit length. In the rest of the article, we also denote \(h_{i}\) the internal state variable \(h\) after the \(i\)th application of the compression function \(g\), which is defined in more details in Sect. 2.2.
Stage 1. This phase initializes the hash state. The three variables \(\varSigma \), \(N\) and \(h\) are assigned to 0, 0 and \(IV\) respectively, where \(IV\) refers to the initialization vector of Streebog, and has been publicly defined by the designers.
2.2 The Compression Function of Streebog
As described in the introduction, the designers of Streebog have chosen to adopt the HAIFA model in the design of the compression function \(g\). This framework has been initially introduced to differentiate the successive applications of the compression function calls by adding a counter as additional input parameter. Here, we mainly focus on how the counter \(N\) is used in the compression function \(g(N, h_{i1}, m_i)\), which is described in Fig. 2. Particularly, we emphasize that \(f\) is a deterministic function independent of the counter \(N\). Since the detailed algorithm of \(f\) is not related to our attack, we omit its description in this paper, and refer the interested reader to the original document [20, 27]. Yet we would like to point out that \(f\) shares high similarity with the compression function of Whirlpool hash function [28], which leads to the analysis results on Streebog[1, 2, 31] that share similarity with the attacks on Whirlpool [25, 29].
3 Our Observation
In this section, we propose an equivalent representation of the domain extension algorithm of Streebog, which we use in the next section to launch a secondpreimage attack on the full hash function.
First values of \(\varDelta (i)\).
\(i\):  0  1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23 
\(\varDelta (i)\):  1  3  1  7  1  3  1  15  1  3  1  7  1  3  1  31  1  3  1  7  1  3  1  15 
4 SecondPreimage Attack on Full Streebog with a Diamond
Based on the equivalent description of the Stage 2 computation of Streebog presented in the previous section, we now describe a secondpreimage attack on the full Streebog512 hash function with time complexity equivalent to \(2^{342}\) compression function evaluations for an original message of at least \(2^{179}\) blocks.
Our main observation provides a way to remove the security benefits brought by the counter of the HAIFA design in the Streebog hash function. This is due to a poor usage of this counter, which allows an adversary to reuse previously known secondpreimage techniques on the classical MerkleDarmgård construction. In particular, we can use the diamond structure introduced by Kelsey and Kohno [22] on the function \(F_{2^{s}2}\circ \cdots F_{1}\circ F_{0}\), which is reused several times. Indeed, this technique allows to construct a large multicollision set of \(2^{d}\) \(d\)block messages, all hashing to a single chaining variable \(h_{\diamond }\). This is similar to the secondpreimage attack on dithered hash functions by Andreeva et al. [3].
We first give in Sect. 4.1 a detailed explanation concerning the construction of this structure with \(2^{(n+d)/2}\) computations, and we later describe in Sect. 4.2 how to use it inside a secondpreimage attack for the full Streebog512.
4.1 The Diamond Structure
4.2 Details of the Attack
At this point, we are able to build a diamond structure, and we would like to use it for a secondpreimage attack. An overview of our attack is given in Fig. 9, where one can see that we use \(d=2^{s}1\) in order to fully control the effect of the counter. The diamond structure is constructed with the function \(F_{2^{s}1}\circ \cdots F_{1}\circ F_{0}\). Then, as in the original secondpreimage attack using the diamond structure, we use a single message block \(m_{\diamond }^{\searrow }\) to connect the root chaining value \(h_{\diamond }\) to the known message we are attacking. The connection is done after the next \(F\) function, but before the addition of the counter, i.e. we match of set of values \(\left\{ F(h_{\diamond },m)\,\, m \leftarrow \$ \right\} \), and \(\left\{ h_i \oplus i\,\, i \equiv 0~\mathrm{{mod}}~2^s \right\} \). If the original message \(m\) consists of \(t\) \(2^s\)bit blocks, we have \(l=\left\lfloor \frac{t}{2^{s}}\right\rfloor \) possible connecting points, meaning that we expect to pick about \(2^{n}/l\) random message blocks \(m_{\diamond }^{\searrow }\) before hitting a known point \(h'_{\diamond }\).
This point of connection gives the value \(l'\times 2^{s}1\) of the counter \(N\) used in Streebog at that position. Once we have found the 1block connecting message \(m_{\diamond }^{\searrow }\) at the end of the diamond structure, we need to connect one of the \(2^{d}\) leaves of the diamond structure to the \(IV\) of the hash function.
In order to overcome both of these two points, we first construct a \(2^{512}\)multicollision (with a technique similar to the one from Joux [21]) over the first \(2\times 512=1024\) message blocks so as to handle the checksum issue. This step can be performed efficiently with \(512\times 2^{n/2}\) computations using the technique described in [15]. The idea is that, at each step \(i\) of the multicollision search, we compute two sets of 2block messages: \(\{(A_{i})(A_{i})\}\), for \(2^{n/2}\) random choices of \(A_i\), and \(\{(B_{i}+2^{i})(B_{i})\}\), for \(2^{n/2}\) random choices of \(B_i\), in order to find a collision between the two sets.
Then, starting from the \(IV\), we reach a chaining value \(\tilde{h}\), such that we can find a 1024block message that verifies any given additive checksum value \(\sigma \). Indeed, the binary decomposition of \(\sigma \) gives precisely the path to follow (and incidentally the message blocks to use) in the multicollision graph we just built in order to reach \(\sigma \).
We would like now to match the correct message length \(M\). For that task, we first evaluate the number of blocks already fixed by the attack. The diamond uses \(d=2^{s}1\) blocks, the multicollision uses 1024 blocks, and we use one block for \(m_{\diamond }^{\nearrow }\) to connect to \(h'_{\diamond }\) in the original message chain. After the collision on \(h'_{\diamond }\), we use the same values as in the original message, such that we want to use exactly \(l'\times 2^{s}\) blocks between the \(IV\) and \(h'_{\diamond }\). We use an additional message block \(m_{\diamond }^{\nearrow }\) to connect to one leaf of the diamond, so that in total there are \(L=l'\times 2^{s}102412^{s}1\) blocks left between \(\tilde{h}\) and \(\tilde{h}'\). We pick random values for all those blocks, obtain the value of \(\tilde{h}'\), and then pick about \(2^{nd}\) random blocks \(m_{\diamond }^{\nearrow }\) to hit one of the \(2^{d}\) leaves of the diamond.
Finally, we compute the reduced checksum value \(\sigma \) of all the message blocks except the 1024 first ones, and we choose the correct 1024 message blocks in the graph so as to match the local checksum \(\varSigma \sigma \). At this point, the attack is over: all the message blocks are fixed, and the secondpreimage is constructed.
For shorter messages with \(2^x\) blocks and \(x < 179\), the complexity is mainly dominated by the complexity of linking \(IV\) to one leaf node of the diamond structure, which is \(2^{nd}\), and the complexity of linking \(h_{\diamond }\) to \(h'_{\diamond }\), which is \(2^{nx+\lceil \log _2(d) \rceil }\). Let \(x=d\), and we get the complexity is upper bounded by \(2x \cdot 2^{nx}\). Thus the complexity increases linearly with the decrease of the message block length (ignoring logarithmic factors).
5 SecondPreimage Attack on Full Streebog with an Expandable Message
The equivalent description of Streebog given in the previous sections can also be used to mount a variant of the attack of Kelsey and Schneier using an expandable message [23]. This gives a secondpreimage attack on the full Streebog512 hash function with time complexity equivalent to \(2^{266}\) compression function calls for an original message of at least \(2^{259}\) blocks.
We first give in Sect. 5.1 a detailed explanation concerning the construction of this structure with \(n/2 \times 2^{n/2}\) computations, and we later describe in Sect. 5.2 how to use it inside a secondpreimage attack for the full Streebog512.
5.1 The Expandable Message
In order to build an expandable message, we use the technique of [23], i.e. we build a multicollision where the messages in each colliding pair have a different length, as shown by Algorithm 2. If we have colliding pairs with length \((1,2^k+1)\), for \(0 \le k < t\), this implicitly defines a set of \(2^t\) messages with length in the range \([t, 2^t+t1]\), that all reach the same final chaining value \(x_{*}\). More precisely, one can build a message of length \(t+L\) using the binary expression of \(L\) to select a message in each pair.
However, this does not work for a HAIFA compression function: depending on which message is selected in the pair \(k\) (\(m_{k}\) or \(m_{k}'\)), the message length before the following block will be different, and the counter will have a different value. Therefore, the collision \((m_{k1}, m_{k1}')\) will only be valid in one case.
In the case, of Streebog, the weak use of the counter makes this attack still possible thanks to the equivalent representation of Sect. 3. Indeed, the sequence \(\varDelta (i)\) has a lot of regularity and repetitions (as seen in Table 1), and with a careful construction, we can ensure that the message pairs \((m_i,m_i')\) are only used at positions with same sequences of \(\varDelta (i)\). More precisely, we must build pairs with large difference first, and use differences that are powers of two, while more general constructions can be used for plain MerkleDamgård. We must also stop the construction a few steps before reaching a difference of 1 (as explained later, the smallest difference is \(O(n)\)). This means that we can only use a fraction of the intermediate states reached by the challenge message.
5.2 Details of the Attack
The second preimage attack on full Streebog512 uses an initial multicollision with \(1024\) blocks in order to adjust the checksum, like the attack of Sect. 4. Then, we build the expandable message starting for the final value of the multicollision. With the parameters of Streebog512, we use \(l=1024\), \(s=11\), \(t=258\), i.e. we build a \((1271,2^{259}777,2048)\)expandable message. After building the expandable message, the attack mostly follows the procedure given by Kelsey and Schenier. An overview of our attack is given in Fig. 11.
6 Open Discussion and Conclusion
In this article, we have studied the security of the Russian hash function standard Streebog. We showed that an attacker can find secondpreimages much faster than what is expected from an ideal hash function, even though Streebog uses HAIFA as the domain extension algorithm. Our main observation is that the counter is not very well handled in Streebog and this enables the attacker to apply a more complex variation of the now classical generic secondpreimage attacks. As a result, Streebog is only marginally stronger than a plain MerkleDamgåd iteration.
This analysis also contradicts the remark by Kelsey and Schneier that “XORing in a monotomic counter” would be sufficient to avoid the secondpreimage attacks with long messages: there is at least one way to XOR the counter that do not provide any extra security.
Our work is a good example why one should be careful when using a design framework: problems might arise if bad instances in that framework exist. In the particular case of HAIFA, it is crucial to make sure the counter is properly handled. We have the intuition that the security property that a compression function in HAIFA has to follow with regards to the counter input is quite strong (even if the counter might controlled by the adversary, he must not be able to distinguish the output). Clearly, Streebog would not meet that criteria (inserting a difference \(\delta \) in both the counter and the chaining variable input, one always get \(\delta \) on the output). It would be interesting to study what is exactly the minimal security assumption that is required on the counter input for HAIFA in order to ensure only secure instances.
Footnotes
Notes
Acknowledgment
We would like to thank the anonymous reviewers for their detailed feedback and comments. Jian Guo, Jérémy Jean, Thomas Peyrin and Lei Wang were supported by the Singapore National Research Foundation Fellowship 2012 (NRFNRFF201206).
References
 1.AlTawy, R., Kircanski, A., Youssef, A.M.: Rebound attacks on Stribog. IACR Cryptology ePrint Archive 2013, 539 (2013)Google Scholar
 2.AlTawy, R., Youssef, A.M.: Preimage attacks on reducedround stribog. In: Pointcheval, D., Vergnaud, D. (eds.) AFRICACRYPT. LNCS, vol. 8469, pp. 109–125. Springer, Heidelberg (2014)Google Scholar
 3.Andreeva, E., Bouillaguet, C., Fouque, P.A., Hoch, J.J., Kelsey, J., Shamir, A., Zimmer, S.: Second preimage attacks on dithered hash functions. In: Smart, N.P. (ed.) EUROCRYPT 2008. LNCS, vol. 4965, pp. 270–288. Springer, Heidelberg (2008)Google Scholar
 4.Aumasson, J.P., Guo, J., Knellwolf, S., Matusiewicz, K., Meier, W.: Differential and invertibility properties of BLAKE. In: Hong, S., Iwata, T. (eds.) FSE 2010. LNCS, vol. 6147, pp. 318–332. Springer, Heidelberg (2010)Google Scholar
 5.Aumasson, J.P., Henzen, L., Meier, W., Phan, R.C.W.: SHA3 proposal BLAKE. Submission to NIST (Round 3) (2010)Google Scholar
 6.Benadjila, R., Billet, O., Gilbert, H., MacarioRat, G., Peyrin, T., Robshaw, M., Seurin, Y.: SHA3 Proposal: ECHO. Submission to NIST (updated) (2009)Google Scholar
 7.Biham, E., Dunkelman, O.: A framework for iterative hash functions  HAIFA. Cryptology ePrint Archive, Report 2007/278 (2007)Google Scholar
 8.Biham, E., Dunkelman, O.: The SHAvite3 hash function. Submission to NIST (Round 2) (2009)Google Scholar
 9.Biryukov, A., Gauravaram, P., Guo, J., Khovratovich, D., Ling, S., Matusiewicz, K., Nikolić, I., Pieprzyk, J., Wang, H.: Cryptanalysis of the LAKE hash family. In: Dunkelman, O. (ed.) FSE 2009. LNCS, vol. 5665, pp. 156–179. Springer, Heidelberg (2009)Google Scholar
 10.Bouillaguet, C., Fouque, P.A.: Practical hash functions constructions resistant to generic second preimage attacks beyond the birthday bound. Submitted to Information Processing Letters (2010)Google Scholar
 11.Brassard, G. (ed.): CRYPTO 1989. LNCS, vol. 435. Springer, Heidelberg (1990)Google Scholar
 12.Bresson, E., Canteaut, A., ChevallierMames, B., Clavier, C., Fuhr, T., Gouget, A., Icart, T., Misarsky, J.F., NayaPlasencia, M., Paillier, P., Pornin, T., Reinhard, J.R., Thuillet, C., Videau, M.: Shabal, a submission to NIST’s cryptographic hash algorithm competition. Submission to NIST (2008)Google Scholar
 13.Damgård, I.: A design principle for hash functions. In: [11], pp. 416–427Google Scholar
 14.Ferguson, N., Lucks, S., Schneier, B., Whiting, D., Bellare, M., Kohno, T., Callas, J., Walker, J.: The skein hash function family. Submission to NIST (Round 3) (2010)Google Scholar
 15.Gauravaram, P., Kelsey, J.: LinearXOR and additive checksums don’t protect DamgårdMerkle hashes from generic attacks. In: Malkin, T. (ed.) CTRSA 2008. LNCS, vol. 4964, pp. 36–51. Springer, Heidelberg (2008)Google Scholar
 16.Gauravaram, P., Leurent, G., Mendel, F., NayaPlasencia, M., Peyrin, T., Rechberger, C., Schläffer, M.: Cryptanalysis of the 10round hash and full compression function of SHAvite3512. In: Bernstein, D.J., Lange, T. (eds.) AFRICACRYPT 2010. LNCS, vol. 6055, pp. 419–436. Springer, Heidelberg (2010)Google Scholar
 17.Grebnev, S., Dmukh, A., Dygin, D., Matyukhin, D., Rudskoy, V., Shishkin, V.: Asymmetrical reply to SHA3: Russian hash function draft standard. CTCrypt 2012, abstract available from http://agora.guru.ru/csr2012/files/6.pdf
 18.Guo, J.: A program confirmation of the diamond construction by Kortelainen and Kortelainen (Feburary 2014). http://guo.crypto.sg/diamond.zip
 19.Guo, J., Karpman, P., Nikolic, I., Wang, L., Wu, S.: Analysis of BLAKE2. In: Benaloh, J. (ed.) CTRSA 2014. LNCS, vol. 8366, pp. 402–423. Springer, Heidelberg (2014)Google Scholar
 20.IETF: GOST R 34.112012: Hash Function. RFC6896 (2013)Google Scholar
 21.Joux, A.: Multicollisions in iterated hash functions. Application to cascaded constructions. In: Franklin, M. (ed.) CRYPTO 2004. LNCS, vol. 3152, pp. 306–316. Springer, Heidelberg (2004)Google Scholar
 22.Kelsey, J., Kohno, T.: Herding hash functions and the nostradamus attack. In: Vaudenay, S. (ed.) EUROCRYPT 2006. LNCS, vol. 4004, pp. 183–200. Springer, Heidelberg (2006)Google Scholar
 23.Kelsey, J., Schneier, B.: Second preimages on nbit hash functions for much less than 2\(^{n}\) work. In: Cramer, R. (ed.) EUROCRYPT 2005. LNCS, vol. 3494, pp. 474–490. Springer, Heidelberg (2005)Google Scholar
 24.Kortelainen, T., Kortelainen, J.: On diamond structures and trojan message attacks. In: Sako, K., Sarkar, P. (eds.) ASIACRYPT 2013, Part II. LNCS, vol. 8270, pp. 524–539. Springer, Heidelberg (2013)Google Scholar
 25.Lamberger, M., Mendel, F., Rechberger, C., Rijmen, V., Schläffer, M.: Rebound distinguishers: results on the full whirlpool compression function. In: Matsui, M. (ed.) ASIACRYPT 2009. LNCS, vol. 5912, pp. 126–143. Springer, Heidelberg (2009)Google Scholar
 26.Merkle, R.C.: One way hash functions and DES. In: [11], pp. 428–446Google Scholar
 27.REGULATION, F.A.O.T., METROLOGY: Information technology  CRYPTOGRAPHIC DATA SECURITY  Hashfunction. GOST R 34.112012 (2012)Google Scholar
 28.Rijmen, V., Barreto, P.S.L.M.: The WHIRLPOOL hashing function. Submitted to NISSIE, September 2000Google Scholar
 29.Sasaki, Y., Wang, L., Wu, S., Wu, W.: Investigating fundamental security requirements on whirlpool: improved preimage and collision attacks. In: Wang, X., Sako, K. (eds.) ASIACRYPT 2012. LNCS, vol. 7658, pp. 562–579. Springer, Heidelberg (2012)Google Scholar
 30.GOST R 34.112012: Streebog Hash Function. https://www.streebog.net/
 31.Wang, Z., Yu, H., Wang, X.: Cryptanalysis of GOST R hash function. Cryptology ePrint Archive, Report 2013/584 (2013). http://eprint.iacr.org/