CC BY
2
2024 Математические методы криптографии № 64
МАТЕМАТИЧЕСКИЕ МЕТОДЫ КРИПТОГРАФИИ
УДК 519.7 DOI 10.17223/20710410/64/3
STREEBOG AS A RANDOM ORACLE
L. R. Akhmetzvanova, A. A. Babueva, A. A. Bozhko CryptoPro, Moscow, Russia E-mail: {lah, babueva, bozhko}@cryptopro.ru
The random oracle model is an instrument used for proving that protocol has no structural flaws when settling with standard hash properties is impossible or fairly difficult. In practice, however, random oracles must be instantiated with some specific hash functions that are not random oracles. Therefore, in the real world an adversary has broader capabilities than considered in the random oracle proof: it can exploit the peculiarities of a specific hash function to achieve its goal. In a case when a hash function is based on some building block, one can go further and show that even if the adversary has access to that building block, the hash function still behaves like a random oracle under some assumptions made about the building block. Thereby, the protocol can be proved secure against more powerful adversaries under less complex assumptions. The notion of indifferentiability formalizes that approach. In this paper, we show that Streebog, a Russian standardized hash function, is indifferentiable from a random oracle under an ideal cipher assumption for the underlying block cipher.
Keywords: Streebog, GOST, random oracle, indifferentiability.
«СТРИБОГ» КАК СЛУЧАЙНЫЙ ОРАКУЛ
Л. Р. Ахметзянова, А. А. Бабуева, А. А. Божко Крипт,оПро, г. Москва, Россия
Модель со случайным оракулом используется для доказательства стойкости криптографических протоколов в случае, когда стандартные предположения об использующейся хеш-функции не позволяют этого сделать. Однако на практике для реализации случайного оракула в конкретном протоколе используется некоторая детерминированная хеш-функция, которая, безусловно, не является случайным оракулом. Следовательно, в реальном мире нарушитель обладает более широкими возможностями, чем предполагалось в доказательстве — он может использовать особенности конструкции конкретной хеш-функции для осуществления угрозы. Если используемая хеш-функция строится на основе некоторого другого примитива (например, блочного шифра), можно рассмотреть нарушителя, который имеет доступ напрямую к этому примитиву, и показать, что даже относительного такого нарушителя используемая хеш-функция ведёт себя как случайный оракул в предположении об идеальности используемого примитива. Таким образом можно доказать стойкость протокола относительно более сильных нарушителей в менее сильных предположениях об использующихся примитивах. Хеш-функции,
при использовании которых можно достичь такого результата, называются неразличимыми от случайного оракула. В данной работе показано, что хеш-функция «Стрибог» неразличима от случайного оракула в модели идеального блочного шифра.
Ключевые слова: Стрибог, ГОСТ, случайный оракул, неразличимость.
1. Introduction
The random oracle model introduced in [1] assumes that each party of the protocol and an adversary has access to a random oracle, which is used instead of a hash function. A random oracle [1] is an ideal primitive that models a random function. It provides a random output for each new query, and identical input queries produce the same answer. The random oracle model makes it possible to prove that the protocol has no structural flaws in situations when it is impossible or very difficult to deal with standard hash properties, which is the case for many efficient and elegant solutions. For example, such protocols and mechanisms as TLS [2], IPSec [3], and Schnorr signature [4, 5] were analyzed in the random oracle model; Russian standardized versions of TLS [6] and IPSec [7], as well as SESPAKE protocol [8, 9], shortened ElGamal signature [10], to-be-standardized ESBS blind signature [11], and postquantum Shipovnik signature [12] are also analyzed in the random oracle model.
In practice, however, being idealized primitives, random oracles do not exist and have to be instantiated with some specific hash functions that are not random oracles. Therefore, in the real world, an adversary has broader capabilities than those considered in the random oracle proof: it can exploit the peculiarities of a specific hash function to achieve its goal. To address such a situation, one can go further and consider the design of the hash function to show that, under some less complex and more specific assumptions than the whole function being a random oracle, it behaves like a random oracle. To do that, one must first understand what "behaves like a random oracle" means and what assumptions you need to make.
These questions for a particular class of hash functions are addressed by J. S. Coron et al. in [13, 14]. They study the case when an arbitrary-length hash function is built from some fixed-length building block (like an underlying compression function or a block cipher). They propose a definition based on Maurer et al.'s notion of indifferentiabilitv [15] of what it means to implement a random oracle with such a construction under the assumption that the building block itself is an ideal primitive. The definition is chosen in a way that any hash function satisfying it can securely instantiate a random oracle in a higher-level application1 (under the assumption that the building block is an ideal primitive). Hence, idealized assumptions are made about less complex lower-level primitive and, as a result, more adversarial capabilities are taken into account.
In this paper, we study whether Streebog, a Russian standardized hash function [16], can instantiate a random oracle. We recall that Streebog has always been a popular target for analysis. An overview of the results which study standard properties of the algorithm can be found in [17]. A recent paper [18] studies keyed version of Streebog as a secure pseudorandom function in a related-kev resilient PRF model for an underlying block cipher, highlighting some important high-level design features of Streebog.
1We note that, as shown in [19], it only directly applies to cryptographic protocols which admit the so-called "single-stage security proofs."
Since Streebog is a modified Merkle — Damgard construction based on LSX-stvle block cipher in Miyaguchi—Preneel mode, we adopt the notion of Coron et al. The paper's
Streebog
random oracle under an ideal cipher assumption for the underlying block cipher. We benefit greatly from the work done in [13, 14] since their analysis is focused on Merkle — Damgard
Streebog
features and a different structure of the compression function do not allow us to use the paper's results and pose several challenges,
2. Definitions
Let |a| be the bit length of the string a G {0,1}*, the length of an empty string is equal to 0, For a bit string a we denote bv |a|n = [|a|/n] the length of the string a in n-bit blocks. Let 0u be the string consisting of u zeroes.
For a string a G {0,1}* and a positive integer l ^ |a| let msbl(a) be the string consisting of the leftmost l bits of a. For nonnegative integers l and i, let str (i) be l-bit representation of i with the least significant bit on the right, let int(M) be an integer ¿such th at str(i) = M, For bit strings a G {0,1}^n and b G {0,1}^n we denote by a + b a string strn((int(a) + + int(b)) mod 2n), If the value s is chosen uniformly at random from a set S, then we denote
it s S,
A block cipher E with a block size n and a key size k is the permutation family (EK G Perm({0,1}n) : K G {0,1}fc), where K is a key,
2,1, Streebog hash function
Streebog Streebog
a prefix-free encoding of the message; in that we follow the approach of [13, 14], We will
Streebog Streebog
length of an internal state in Merkle — Damgard construction is n = 512 and the length of k
Let us define a compression function h : {0,1}n x {0,1}n ^ {0,1}n, which is based on 12-rounds LSX-like block cipher E : {0,1}n x {0,1}n ^ {0,1}n, where the first argument is a key, in Miyaguchi — Preneel mode:
h(y, x) = E(y, x) © x © y.
We also define a prefix-free encoding g : {0,1}* ^ ({0,1}n, {0,1}n)*, which takes as an input a message X:
g(X) = (xi, Ai)|(x2, A2)||... ||(x'|| 10n-1-|x11, Ai)||(L,0)||(E,0),
where L = |X^ l = [L/nJ + 1 X = xi| ... ||x', xi,...,x^-i G {0,1}n, x' G {0,1}<n, and x' is an empty string if L is already divisible by n; Aj = strn(in) © strn((i — 1)n), l l-i
Aj = strn((i — 1)n^d E = xi + (x'||10n-i-|xi|). The encoding pads the message with
i=i
10n-i-\x'l^ ^ the message in blocks of length n, computes the counter value
L
checksum E, which correspond to the finalizing step of Streebog,
Finally, we define the hash function Streebog on Fig. 1, where IV, |IV| = 512, is a predefined constant, different for k = 256 and k = 512. On Fig, 2 Streebog is depicted schematically.
We will call a sequence of triples (yi,x\,zi), (y2, x2, z2),..., (yi+2,xi+2, zi+2), where zi = = h(yi,xi) © yi © xi; which appears during a computation of Streebog on an input X, a computational chain for X,
Streebog(X)
i ^ l|x|/nj +1
(xi,ci )y(X2,C2)y ... ||(xi ,ci )\\(Xi+i,Ci+i)\\(Xi+2,Ci+2) ^ )
yi ^ IV
for i = 1 ...i + 2 do :
yi+i ^ h(yi,Xi) © Ci
return msbfc (yi+3)
Fig. 1. Streebog hash function
T_
A2 4111^-0 A3
X\ Ai X2
—
IV~r E —o—®-r E—#—&—r E —#—E 0 ■ E 0 'H
E
h
Fig. 2. Streebog computation, i = 3
2.2. Indifferentiability The following strategy is often applied to prove the security of a cryptosystem with some component (or primitive). First, it is proven that the system is secure in case of using idealized primitive. Secondly, we prove that the real primitive is indistinguishable from an idealized one. Informally, two algorithms A and B are computationally indistinguishable if no (efficient) algorithm D is able to distinguish whether it is interacting with A or B,
We consider two types of the ideal primitives: random oracles and ideal ciphers. A random oracle |1| is an ideal primitive that models a random function. It provides a random output for each new query, identical input queries produce the same answer. An ideal cipher is an ideal primitive that models a random block-cipher E : {0,1}K x {0,1}n ^ {0,1}n, each key K E {0,1}K defines a random permutation on {0,1}n, The ideal cipher provides oracle access to E and E-1; that is, on query (+,K,x), it answers c = E(K, x), and on query (—, K, c), it answers x such that c = E(K, x).
Obviously, a random oracle (ideal cipher) is easily distinguishable from a hash function (block cipher) if one knows its program and the public parameter. Thus, in |15| the extended notion of indistinguishability — indifferentiability — was introduced. It was proven, that if a component A is indifferentiable from B, then the security of any cryptosystem C(A) based on A is not affected when replacing A by B, According to the authors, indifferentiability is the weakest possible property that allows security proofs of the generic type described above. Thus, to prove the security of some cryptosystem using hash function, we may prove its security in the random oracle model, and then prove that hash function is indifferentiable from a random oracle within some underlying assumptions. We assume that the base block cipher is modelled as an ideal cipher.
Let us define formally what the indifferentiability from an ideal primitive means. We give the definition directly for the hash function (based on the ideal cipher) and random oracle.
This definition is a particular case of more general indifferentiability notion introduced in [15].
Definition 1. A hash function H with oracle access to an ideal cipher E is said to be (TD , qH , qE, e)-indifferentiable from a random oracle H if there exists a simulator S such that for any distinguisher D with binary output it holds that:
| Pr [DH'E ^ 1 ] — Pr [DH'S ^ 1 ] | < e.
The simulator has oracle access to H. The distinguisher runs in time at most TD and makes at most qH and qE queries to its oracles.
The indifferentabilitv notion is illustrated in Fig. 3. The distinguisher interacts with two oracles, further we denote them by left and right oracles respectively. In one world,
H
E
HS
H
S
H
H
Fig. 3. The indifferentiability of hash function H and random oracle H Streebog
Streebog
indifferentiable from a random oracle in the ideal cipher model for the base block cipher. First, we discuss the choice of the underlying assumption. Indeed, the straightforward Streebog
is a random oracle. Although such proof may be constructed much easier than in the ideal cipher model, we show that the Mivaguchi — Preneel compression function cannot be modeled as a random oracle. Indeed, for this function the following condition always holds:
x = E-i(y, h(y, x) © x © y).
Thus, the distinguisher can easily identify whether it interacts with the real compression function or the random one by making the query (y,x) to the left oracle and the query (—, y, h(y, x) © x © y) to the right oracle.
Streebog
the Streebog variant with output size k = 512. For the shortened Streebog variant argumentation is completely similar. Formally, the only thing which has to be adjusted is the construction of the simulator; we will highlight the difference in the proof. The general structure of the proof and some techniques are adopted from [13, 14].
Theorem 1. The hash function Streebog with k = 512 or 256 using a cipher E : {0,1}n x {0,1}n ^ {0,1}n is (tD, qH, qE, e)-indiiferentiable from a random oracle in the ideal cipher model for E for any tD with
(1 + 1m)q , (1 + n + /m)q
2
+
2«—4 2™—7
where q = qE + qH (1m + 2^d is the maximum message length (in blocks, including padding) queried by the distinguisher to its left oracle.
Proof. The main goal of the proof is to show that no distinguisher can tell apart two
Streebog
an underlying block cipher and to the ideal cipher itself; in the second one it has access to a random oracle and a simulator. The first step of the proof is to present a simulator for which it would be possible to achieve that goal.
Our simulator for the ideal cipher E is quite elaborate. On every distinguisher query, it
Streebog
If this is the case, it chooses the answer consistently with the random oracle; otherwise, it chooses the answer randomly.
The simulator. Before we proceed with the simulator itself, let us define an auxiliary function g0 : {0,1}* ^ ({0,1}n, {0,1 }"")*:
go(X) = (xi, Ai) || (x2, A2) ||... || (xj || 10™-1—1x11, A1) || (L, 0), where L = |X|, l = LL/nJ +1 X = x1| ... ||xj, x1,... ,x1—1 e {0,1}n, xj e {0,1}<n, and
1—1
x' is an empty string if L is already divisible by n. Clearly, if £ = x» + (x'|| 10n—1—|x11),
then go(X)||(£,0)= g(X)
The simulator accepts two types of queries: either a forward ideal cipher query (+, y, x), where x e {0,1}n corresponds to a plaintext and y e {0,1}n to a cipher key, on which it returns a ciphertext z e {0,1}™; or an inverse query (—,y,z), on which it returns a plaintext x. The simulator maintains a table T, which contains triples (y, x,z) e {0,1}n x x {0,1}n x {0,1}n.
(+, y, x) T
for a triple (y, x, z) for some z. It returns z if such a triple exists. If there is no such triple, the simulator chooses z randomly, puts the triple (y, x, z) in the table, and returns z to the distinguisher. Additionally, in that case the simulator proceeds with the following routine. It looks up the table for a sequence (y1,x1,z1),..., (yj) of length l = Lint(x)/nJ + 1 such that:
— there exists X such that g0(X) = (x1, A1)|(x2, A2)|| ... || (xz, A1 )||(x, 0);
— it is the case that y1 = IV;
— for each i = 2,..., /, it is the case that y» = xi—1 © yi—1 © zi—1 © Ai—1;
— it is the case that y = xz © yz © zz ©
If such sequence exists, the simulator forms a pair (y1+2 ,x1+2) such that y1+2 = x © l—1
© y © z and x1+2 = x» + x^ where X = x1|... ||x^. It is easy to see that g(X) =
i=1
= (x1, A1)| ... ||(xz, )|(x, 0)|(x1+2, 0), The simulator does nothing if there already exists a triple (y1+2 ,x1+2, z') for some z' in the table T, Otherwise, it computes z' to form a triple (yz+2, x1+2, z'^, which will ^e consistent with a random oracle output on X, in advance. To do
this, it queries the random oracle to get the output Z = H(X), computes z' = Z©xl+2©yl+2 and stores the triple (yl+2,xl+2, z') in the table T2,
Inverse query. On an inverse query (—, y, z) the simulator acts almost similarly. It looks up the table T for a triple (y, x, z) for some x. It returns x if such triple exists. If there is no such triple, the simulator chooses x randomly, puts the triple (y,x,z) in the table, and x
as described above.
We will denote the number of entries in the table T by q, It is clear that qE ^ q ^ 2qE, since for each adversarial query to S, at most one additional record can be added to the T
Proof of indifferentiability. Due to the definition of indifferentiabilitv, if the following inequality holds for every distinguisher V:
\ Pr [VH'£ ^ 1 ] - Pr [VH'S ^ 1 ] \ ^ £,
V
between these two words except with probability e, We will do that using the game hopping technique, starting in the world with the random oracle H and the simulator S and moving through the sequence of indistinguishable games to the world with the Streebog construction and the ideal cipher E,
Game 1 ^ Game 2. The Game 1 is the starting point, where V has access to the random oracle H and the simulator S, In the Game 2 (Fig, 4), we give V access to the relay algorithm R0 instead of direct access to H. R0, in its turn, has access to the random oracle and on distinguisher's queries simply answers with H(X), Let us denote by Gi the events that V returns 1 in Game i, It is clear that Pr[Gi ] = Pr[G2],
Fig. 4. Game 2
Game 2 ^ Game 3. In the Game 3, we modify the simulator S by introducing failure conditions. The simulator explicitly fails (i.e., returns an error symbol when answering to the distinguisher's query, if it computes the response satisfying one of the following failure conditions. Let S0 denote the modified simulator.
We introduce two types of failure conditions. Each condition captures different relations between the simulator's answers that could be exploited by the distinguisher. By failing, the simulator "gives" the distinguisher an immediate win. Our longterm goal is to show that, unless the failure happens, distinguisher cannot tell apart Game 2 form the ideal cipher world. The simulator S0 chooses response to the forward or inverse query similarly to the simulator S and then checks the resulting triple (y,x,z) for the conditions defined below. For each type of conditions we also provide a brief motivation behind it, i.e., how the distinguisher can exploit corresponding situations to tell apart two worlds,
2 In the case of k = 256, the simulator first pads Z with 256 randomly chosen bits and then computes
z' = Z © xl+2 © yl+2.
Conditions of type 1. Conditions of type 1 are cheeked if the answer to the query was chosen randomly or the discriminator was first returned with a value selected by the simulator as corresponding to a random oracle and previously tabulated:
1) Condition Bn: x © y © z = IV,
2) Condition B12: there exists I e {1,..., 1m} such that x © y © z © Az = IV,
3) Condition B13: there exist a triple (y', x', z') e T and i e {1,..., — 1} such that x © y © z = x' © y' © z' © Aj. Note that |{A, : i e {1, 2,...}}, ^ n.
4) Condition B14: there exist a triple (y',x',z') e T and I e {1,...,1m} such that x © y © z = x' © y' © z' © AI.
5) Condition B15: there exists a triple (y', x', z') e T such that x © y © z = x' © y' © z'.
The type 1 conditions correspond to the situation when the internal states of two Streebog
that situation in a number of ways, for example, it can force these two chains to end with the same block, which will give the same result for two different messages. From this, the distinguisher can easily distinguish between the two worlds by querying its left oracle with these messages. Other bad situations which correspond to this type of conditions are analyzed in the proof of Lemma 1,
Conditions of type 2. Conditions of type 2 are checked if only the answer to the query was chosen by the simulator randomly (i.e., the answer was not taken from the table):
1) Condition B21: there exists a triple (y', x', z') e T such that x © y © z = y',
2) Condition B22: there exist a triple (y', x', z') e T and i e {1,..., — 1} such that x © y © z = y' © Aj.
3) Condition B23: there exist a triple (y',x',z') e T and I e {1,...,1m} such that x © y © z = y' © A I.
The conditions of type 2 correspond to a situation when some block in the computational chain is queried sometime after the query corresponding to the next block was made. In this case, this query can be made even after the query for the last block in the chain was. The distinguisher can then easily tell two worlds apart, because the simulator did not choose the answer to the last query to be consistent with the random oracle. Notice that conditions of that type are only checked when the simulator chooses the answer randomly itself. Otherwise, the distinguisher can easily force the failure event using the random oracle, for example, it can choose an arbitrary X, query the random oracle for Z = H(X), then query the right oracle with (+, Z, x) for some x, and finally compute the Streebog construction for X using its right oracle. The simulator would then fail due to condition B21 when answering for the last block of the computational chain. However, such a situation will not help the distinguisher, since this is in a sense an extension of the computational message chain with new blocks, which will not lead to another valid computational chain due to our prefix-free encoding g, Bad situations which correspond to this type of conditions are analyzed in the proof of Lemma 2,
The probability of the event that the simulator fails due to one of the failure conditions is estimated as follows:
Pr [So fails] ^ (1 + 1"1)qE + (1 + n+4UqE. L 0 J 2™—1 2™—4
That bound directly follows from Lemma 3 with qS = qE, which is given in Appendix Appendix A, The proof of this statement is rather technical and is also provided in Appendix Appendix A,
Since Game 2 and Game 3 are different only in situations, where the simulator S0 fails, it is clear that
| Pr[G2] - Pr[G3] | ^ Pr[So fails] ^ + (1 + .
Now, before we proceed to the next game, our aim is to show that unless the simulator fails, its outputs are always consistent with random oracle outputs, i.e., it does not matter
Streebog
some unsual way) or queries the random oracle, the results would be the same. To do this, we prove two lemmas, where Lemma 2 formalizes the outlined goal,
T
corresponding to computational chains with two different inputs such that the last block of
S0
S0 T
two different sequences of triples (y1,x1,z1^, ,,,, (yl+2, xl+2, zl+2) and (y1,x1 ,z1), ,,,, (yP+2, xP+2, zp+2), where /,p ^ such that the following conditions hold:
— there exist X and X' such that g(X) = (x1, A1)|... ||(xl+1,0)||(xl+2,0) and g(X') = = (x1, A1)|| ... ||(xp+1, 0)|(xp+2, 0);
— it is the case that y1 = y1 = IV;
— for each i = 2,..., / and j = 2,... ,p, it is the case that yi = xi_1 © yi_1 © zi_1 © Ai_1 and yj = xj_1 © yj_1 © zj_1 © Aj_1;
— it is the case that yl+1 = xi © yl © zi © Al and y^+1 = x^ © y^ © z^ © Ai;
— it is the case that yl+2 = xi+1 © yl+1 © zi+1 and y^+2 = x^+1 © y^+1 © z^+1;
— there exists s G (1,..., / + 2} such th at (ys, xs, zs) = (y^+2, x^+2, z^+2).
Proof. Let us suppose that there exist two sequences (y1, x1, z1),..., (yl+2, xl+2, zl+2) and (y1, x1, z1),..., (yP+2, xp+2, zp+2) in the table T, which satisfy conditions of the lemma. Then there exists the maximum r G (1,..., min(s,p + 2)} such that
(ys_i, xs_i, zs_i) = (yp_2_i, xp_2_i, zp_2_i), i = 0, . . . , r — 1
In other words, r is the length of the subsequence of equal triples ending with (ys,xs, zs) = = (yP+2, xP+2, z^+2). We will now consider several cases depending on values of r and /. Notice that r ^ s ^ / + 2.
The case r = 1. Since it is true that (ys,xs,zs) = (y^+2, x^+2,z^+2), we can deduce that one of the following equalities has to hold:
1) if s = 1, then ys = IV, Hence, x^+1 © y^+1 © z^+1 = y^+2 = ys = IV;
2) if s G (2,..., /}, then ys = xs_1 © ys_1 © zs_1 © Hence, x^+1 © y^+1 © z^+1 =
= xs_1 © ys_1 © zs_1 © As_1;
3) if s = / + 1, then ys = xs_1 © ys_1 © zs_1 © As_1- Hence, x^+1 © y^+1 © z^+1 =
= xs_1 © ys_1 © zs_1 © Ai;
4) if s = /+2, then ys = xs_1 ©ys_1 ©zs_^. Hence, x^+1 ©y^+1 ©z^+1 = xs_1 ©ys_1 ©zs_1-However, it is easy to see that the above equalities correspond to the failure conditions
B11, B13, B14, B15, respectively. Therefore, one of these failure conditions would have been triggered if a forward or inverse query which corresponds to the triple (ys_1, xs_1, zs_1) or (yp+1, xp+1, z^+1) (depending on which of them was made later) was made.
The case r ^ 2, /> 1 and r = 3 / = 1. Since r ^ 2, it is easy to see that the same inequality holds for s. Thereof, from y^+2 = ys and the lemma statement we have
that xp+1 © yP+1 © zp+1 © 0 = xs-1 © ys-1 © zs—1 © c for some c e {A1,..., Aj—1, Az, 0}, However, since from r ^ 2 we have (ys—1 ,xs—1 ,zs—1) = (y^+1, x^+1, zp+1), the const ant c has to be equal to 0, It is also easy to see that none of the values {A1,..., A1—1, Az} is equal to 0 whe n l > 1, Hence, due to the en coding g, it is only possible that t he triple (ys, xs, zs) is the last one in the sequence and s = l + 2,
Thereof, x1+1 = xp+1, where, due to the definition of g, x1+1 and x^+1 are equal to |X| and |X'| correspondingly. Consequently, since by definition l = L|X|/nJ p = L|X'|/nJ +1,
we have that p = I.
Finally, consider triples (yz+2—r, x1+2_r, z1+2—r) = (y1+2—r, xJ+2—r, zz'+2—r). Notice that r < < l + 2 or else the considered sequences are equal (that excludes the r = 3 l = 1 case at all). Since yz+2—r+1 = yz'+2—r+1, the following equality has to hold:
y1+2—r © x1+2—r © z1+2—r © c = y1+2—r © x1+2—r © z1+2—r © c,
where c is equal either to Az+2—r or Az+2—r. However, it is easy to see that in either way the equality matches the failure condition B15, Therefore, it would have been triggered if a forward or inverse query which corresponds to the triple (yz+2—r ,xz+2—r, zz+2—r) or (y'+2—r, xj+2—r, z'+2—r) (depending on which of them was made later) was made.
The case r = 2 and l = 1. We have that Az is equal to 0, hence two situations are possible. The first one is when s = 3, the reasoning here is exactly the same as in the last case, since equal triples are the last two triples in the sequences.
The second one is when s = 2. From that and since r = 2, we have that (y1,x1,z1) = = (yP+1, xp+1, zp+1^. From the lemma statement, y1 = IV and y^+1 = x^ © y'v © z^ © Ap, thereof the following equality has to hold:
xp © yp © zp © Ap = IV.
However, it is easy to see that the equality matches the failure condition B12, Hence, it would have been triggered, when a forward or inverse query which corresponds to the triple (yp,xp,zp) was made.
We have considered all possible pairs (r, /), Hence, we can conclude that no such sequences can exist if the simulator S0 does not fail. ■
Now we prove that the outputs of the simulator are consistent with the random oracle unless it fails. To do this, we show that if the distinguisher at some point computes the Streebog
computational chain being consistent with the random oracle.
Lemma 2. Consider any sequence of triples (y1, x1, z^, ..., (yz+2,xz+2,zz+2), where l ^ Zm, from the table T such that the following conditions hold:
— there exists X such that g(X) = (x1, A1)| ... ||(xz+1, 0)||(xz+2, 0);
— it is the case that y1 = IV;
— for each i = 2,..., /, it is the case that y» = xi—1 © yi—1 © zi—1 © Aj—1;
— it is the case that yz+1 = xz © yz © zz © Af,
y +2 = x +1 © y +1 © z +1 If the simulator S0 does not fail, then it must be the case the triples (y1,x1,z1), ,,,, (yz+1,x1+1,z1+1) were put in the table T exactly in that order and answers to the corresponding queries were chosen randomly by the simulator. It is also necessary that the triple (yz+2,xz+2,zz+2) was put in the table simultaneously with the triple (yz+1,x1+1,z1+1), chosen to be consistent with the random oracle output H(X),
Proof. Let us suppose that there exists i E (1,..., / + 1} such that the t riple (y, Xj, Zj) was put in the table as a result of the corresponding forward or inverse query, when the triple (yi+1,xi+1, zi+1) already existed in the table T, For that pair of triples the following equality holds:
Vi © Xj © Zj © c = yi+i,
where c is one of the values (Ai, A^ 0} depending on the value of i. From Lemma 1 it follows that the triple (yi,xi,zi) could not be the last in the computational chain of some message X' = X, In other words, the answer to the corresponding query was not chosen to be consistent with the random oracle, but was chosen randomly by the simulator. Hence, on the query corresponding to the triple (yi,xi,zi) one of the failure conditions of type 2 would have been triggered.
Thereby, when the query corresponding to the triple (y1+1, xi+1, zi+1) is made, triples (y1, x1, z1),..., (y, xi, Zi) already exist in the table and the triple (yi+2, xi+2, zi+2) does not. These triples satisfy the conditions of the simulator's routine and it has to choose the triple (yi+2,xi+2,zi+2) to be consistent with the random oracle and put it in the table with the triple (vi+1, xi+1 ,Z|+1). ■
Game 3 ^ Game 4- In Game 4 (Fig, 5), we modify the relav algorithm R0, Let R1 denote the modified algorithm. It does not have access to the random oracle. On a distinguisher query X R1 applies the Streebog construction to X using the simulator for the block cipher E Notice that now at most + (/m + 2) queries are made to S0,
Fig. 5. Game 4
Let fail3 and fai/4 denote the events when the simulator fails in the corresponding game. From Lemma 2 it follows that, unless the simulator does not fail, answers of the modified relay algorithm R1 are exactly the outputs of the random oracle on corresponding messages, since the simulator's answers are consistent with the random oracle. Hence, if the simulator does not fail in either world, the view of the distinguisher remains unchanged from Game 3 to Game 4:
Pr [Ga | 7013] =Pr [G4 | TO/4] .
Probability of the event fai/a was estimated earlier in the transition from Game 2 to Game 3, Probability of the event fai/4 is estimated from Lemma 3, where = + (/m + 2), Thus, we have:
| Pr [Ga ] - Pr [G4 ] | = | Pr [Ga | 70i3 ] Pr [7013 ] + Pr [Ga | fai/a ] Pr [fai/a ] -
- Pr [G4 | TO/4] Pr [TO/4] - Pr [G4 | fai/4 ] Pr [Tai/4 ] 1 ^ Pr [Ga | To/3] ■ 1 Pr [To/3] -- Pr [TO/4] 1 + 1 Pr[Ga | fai/a ] Pr [fai/a ] - Pr[G4 | fai/4 ] Pr [fai/4 ] 1 ^ ^ 1 Pr [fai/4 ] - Pr [fai/a ] 1 + 1 Pr[Ga | fai/a ] Pr [fai/a ] - Pr [G4 | fai/4 ] Pr [fai/4 ] 1 ^ ^ max(Pr [fai/a ], Pr [fai/4 ])+max(1- Pr [fai/a ] -0- Pr [fai/4 ] , 0- Pr [fai/a ]+!• Pr [fai/4 ]) ^
< 2max(Pr[/ai/3 ], Pr/az/4 ]) < 2 V ' H " +
(1+lm)(qE+qH (lm+2)) , (1+n+/m)(qE+qH (/m+2))
2-
2«-i 2™—4 I
Game 4 ^ Game 5. In Game 5 (Fig, 6) we modify the simulator. Let S1 denote the modified simulator. It does not consult the random oracle when answering the query, it still maintains a table T of triples (x,y,z), On a forward query (+,y,x), it searches the table T for a triple (y, x, z) for some z, It returns z if such triple exists. If there is no such triple, the simulator chooses z randomly, puts the triple (y, x, z) in the table and returns z to the distinguisher. It acts similarly to answer the inverse query (—,y,z), but chooses a x
Fig. 6. The ideal cipher world and Game 5
The simulator responses in both games are identical except for the S0 failure condition. This is true because even when S0 chooses the answer using the random oracle, all its answers look uniformly distributed to the distinguisher as it does not have a direct access to the random oracle in Game 4, Hence, the view of the distinguisher is identical in both games if the simulator does not fail in Game 4, and if in Game 5 the simulator does not give a response, which would have led to failure in Game 4, The probabilities of these events are equal, since the number of queries to the simulators in both games is the same, and the distribution of the responses of the simulators is identical. Let us denote the event "Si should have failed" by /ai/5, Hence, the following inequality holds:
| Pr [G4 ] - Pr [G5 ] | = | Pr [G4 | /a/4] Pr [/aiZI] + Pr [G4 | /00/4 ] Pr [/a^ ] -- Pr [G5 | 7015] Pr [/ai/5] - Pr [G5 | /ai/5 ] Pr [/ai/5 ] | = = 1 Pr[G4 | /ai/4 ] Pr[/ai/4 ] - Pr[G5 | /02/5 ] Pr/a^ ] 1 < < Pr[G4 | /ai/4 ] Pr[/ai/4 ] + Pr[G5 | /ai/5 ] Pr[/ai/5 ] < Pr[/ai/4 ] + Pr[/ai/5 ] =
= 2Pr/ 7 ] < 2 ((1 + /m )(gE + gg (/m + 2)) + (1 + n + /m)(gg + (/m + 2))2 [/ 4 ] < I 2™—1 + 2™—4
Game 5 ^ Game 6. In the final game we replace the simulator S1 with the ideal cipher E. Since the relay algorithm R1 is the Streebog construction and now it uses the ideal cipher for E, the Game 6 is exactly the ideal cipher model.
We now have to show that the view of the distinguisher remains almost unchanged. The outputs of the ideal cipher and the simulator S1 have different distributions: the ideal cipher is a permutation for each key and S1 chooses its answers randomly. Hence, the distinguisher can tell apart two games only if forward/inverse outputs of the simulator collide for the same key. The probability of that event is at most the birthday bound through all queries. Thus, we have
| Pr[G5] - Pr[G6] | < (qE + + 2))2.
Finally, combining all the transitions and since Game 6 is exactly the ideal cipher model, we can deduce that
I Pr ^ 11 - Pr fDH'S ^ 1(1 + + (1 + +
IL J L J I x 2"—1 2™—4
+4 , (1 + + gg (¿m + 2)) + (1 + n + ¿m)(gE + gg (¿m + 2))2 \ + (qE + qg (¿m + 2))2
2™—1 2™-4 j ' 2
The statement of Theorem 1 hence follows, ■
4. Conclusion Streebog
oracle under the ideal cipher assumption for the underlying block cipher. From a practical point of view, under this assumption Streebog can be considered as a random oracle as long as computational power of the adversary remains much less than 2n/2 operations. However,
Streebog
and other hash functions under idealized assumptions for even lower-level objects than a block cipher.
Acknowledgement
The authors are very grateful to Vitalv Kirvukhin for useful discussions and valuable comments, which greatly contributed to the quality of the paper, as well as for verifying the results,
REFERENCES
1. Bellare M. and Rogaway P. Random oracles are practical: A paradigm for designing efficient protocols. Proc. 1st ACM Conf. CCS'93, N.Y., ACM, 1993, pp. 62-73.
2. Rescorla E. The Transport Layer Security (TLS) Protocol Version 1.3. RFC 8446, August 2018, https://datatracker.ietf.org/doc/html/rfc8446.
3. Kaufman C., Hoffman P., Nir Y., et al. Internet Key Exchange Protocol Version 2 (IKEv2). RFC 7296, October 2014, https://datatracker.ietf.org/doc/html/rfc7296.
4. Schnorr C.P. Efficient identification and signatures for smart cards. LNCS, 1990, vol.435, pp.239-252.
5. Pointcheval D. and Stern J. Security proofs for signature schemes. LNCS, 1996, vol. 1070, pp.387-398.
6. Smyshlyaev S., Alekseev E., Griboedova E., et al. GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.3. RFC 9367, February 2023, https: //datatracker. ietf . org/doc/rfc9367.
7. Smyslov V. Using GOST Ciphers in the Encapsulating Security Pavload (ESP) and Internet Key Exchange Version 2 (IKEv2) Protocols. RFC 9227, March 2022, https ¡//datatracker. ietf.org/doc/rfc9227.
8. Smyshlyaev S., Alekseev E., OshkinL, and Popov V. The Security Evaluated Standardized Password-Authenticated Key Exchange (SESPAKE) Protocol. RFC 8133, March 2017, https://datatracker.ietf.org/doc/html/rfc8133.
9. Alekseev E. K. and Smyshlyaev S. V. O bezopasnosti protokola SESPAKE [On security of the SESPAKE protocol]. Prikladnava Diskretnava Matematika, 2020, no. 50, pp. 5-41. (in Russian)
10. Akhmetzyanova L. R., Alekseev E. K., Bahueva A. A., and Smyshlyaev S. V. On methods of shortening ElGamal-tvpe signatures. Mat. Vopr. Kriptogr., 2021, vol.12, no. 2, pp. 75-91.
11. Tessaro S. and Zhu C. Short pairing-free blind signatures with exponential security. LNCS, 2022, vol.13276, pp. 782-811.
12. Vysotskaya V. V. and Chizhov I. V. The security of the code-based signature scheme based on the Stern identification protocol. Prikladnava Diskretnava Matematika, 2022, no. 57, pp.67-90.
13. Coron J. S., Dodis Y., Malinaud C., and Puniya P. Merkle-Damgard revisited: How to construct a hash function. LNCS, 2005, vol.3621, pp.430-448.
14. Coron J. S., Dodis Y., Malinaud C., and Puniya P. Merkle-Damgard revisited: How to construct a hash function. Full version, 2005. https://cs.nyu.edu/~dodis/ps/merkle.pdf.
15. MaurerU.M., Renner R., and Holenstein C. Indifferentiabilitv, impossibility results on reductions, and applications to the random oracle methodology. LNCS, 2004, vol.2951, pp.21-39.
16. GOST R 34.11-2012. Informatsionnava tekhnologiva. Kriptograficheskava zashchita informatsii. Funktsiva kheshirovaniva [Information Technology. Cryptographic Data Security. Hash Function]. Moscow, Standartinform Publ., 2012. (in Russian)
17. Smyshlyaev S. V., Shishkin V.A., Marshalko G. B., et al. Obzor rezul'tatov analiza khesh-funktsii GOST R 34.11-2012 [Overview of hash-function GOST R 34.11-2012 crvptoanalvsis]. Problemv Informatsionnov Bezopasnosti. Komp'vuternye Sistemv, 2015, vol.4, pp. 147-153. (in Russian)
18. Kiryukhin V. Keyed Streebog is a Secure PRF and MAC. 2022, Cryptologv ePrint Archive, 2022. https://eprint.iacr.org/2022/972.
19. Ristenpart T., Shacham H., and Shrimpton T. Careful with composition: Limitations of the indifferentiabilitv framework. LNCS, 2011, vol.6632, pp.487-506.
20. Guo J., Jean J., Leurent G., et al. The usage of counter revisited: Second-preimage attack on new Russian standardized hash function. LNCS, 2014, vol.8781, pp. 195-211.
Appendix A. Probability of the simulator's failure event
S0
S0
conditions B11,..., B23, defined in the proof of Theorem 1, satisfies the following bound:
Pr[So fails] = (1 + /"1)qs + (1 + n+4/m)qS,
L 0 J 2n-1 2™—4
where qS is a number of queries made to the simulator.
Proof. Let us denote bv q the maximum number of entries in the table T < q <
< 2qS, To estimate the desired probability, we consider each failure condition and bound
the probability that there exists a query to the simulator satisfying the condition. Let us
begin with conditions of type 1.
— Condition Bn. It is the probability that one of at most q random n-bit strings (where the randomness is due to either the simulator's random choice or the random oracle output) is equal to fixed IV, Hence,
q
Pr[3 query satisfying B11 ] < —.
— Condition B12. It is the probability that one of at most q random n-bit strings is equal to one of /m strings IV © Ah / e {1,..., /m}:
Pr[3 query satisfying B12 ] < /mq.
Condition Bi3. To estimate the probability of this event, we will consider three separate situations.
The first one is that there exists a query satisfying the condition, the answer to which was chosen by the simulator randomly. The probability of that situation is the probability that one of at most qS ^ q random n-bit strings is equal to one of less than nq strings x' © y' © z' © Aj, (y',x' ,z') e T, i e {1,.. .,lm —1} (recall that |{A»: i e {1,2,.. .}| ^ n). Hence,
n q2
Pr[3 query satisfying Bi3 and Situation 1] ^ .
The second one is that there exists a query satisfying the condition, the answer to which was chosen by the simulator to be consistent with the random oracle (then x © y © z is exactly the random oracle output), and the triple (y',x',z') e T was constructed independently from the random oracle (the answer to the corresponding query was chosen randomly by the simulator itself). The probability of that situation is the probability that one of at most qS ^ q random oracle n-bit outputs is equal to one
of less than nq strings x' © y' © z' © Aj, (y', x',z') e T, i e {1,... ,lm — 1}, Hence,
n q2
Pr[3 query satisfying Bi3 and Situation 2] ^ .
The third one is that there exists a query satisfying the condition, the answer to which was chosen by the simulator to be consistent with the random oracle, and the triple
(y , x , z ) e T
x © y © z and x' © y' © z' are the random oracle outputs on different messages ^^d X' (they are different since both triples have to be the last blocks of some computational
X
situation is the probability that two random oracle outputs Z and Z' from at most
qS ^ q satisfy any of the less than n equalities Z © Z' = Aj. Hence,
n q2
Pr[3 query satisfying Bi3 and Situati on 3] ^ . Finally, it is easy to see that
Pr[3 query satisfying Bi3 ] ^ Pr[3 query satisfying Bi3 and Situation 1] + + Pr[3 query satisfying Bi3 and Situati on 2] + Pr[3 query satisfying Bi3 and Situati on 3]
Hence,
n q2
Pr[3 query satisfying Bi3 ] ^ 3 .
Condition Bi4. The probability of that event is estimated similarly to the previous one with the difference that |{A i : l = 1,..., lm}| = lm. Hence,
lm q2
Pr[3 query satisfying Bi4 ] ^ 3 —.
2n
Condition Bi5. The probability of that event is estimated similarly to the previous two:
q2
Pr[3 query satisfying Bi5 ] ^ 3—.
2n
We proceed with conditions of type 2:
— Condition B2i. It is the probability that one of at most qS < q random n-bit strings, where the randomness is due to either the simulator's random choice or the random oracle output and is independent of the distinguisher's random tape, is equal to one of q strings y', (y',x',z') e T, where all y' are chosen by the distinguishes Hence,
q2
Pr[3 query satisfying B2i ] < —.
B22
with the only difference that there are at most nq different strings y'© Ai; (y', x', z') e T, i e {1,... ,lm — 1}. Hence,
n q2
Pr[3 query satisfying B22 ] < ——.
2n
B23
with the difference that there are at most lm q different strings y' © Ai; (y',x',z') e T, l e {1,..., lm}. Hence,
lm q2
Pr[3 query satisfying B23 ] < .
Finally, we estimate the probability of the event that the simulator fails:
Pr[S0 fails] < Pr[3 query satisfying some bad condition] <
< (1 + lm)q (4 + 4n + 4lm)q2 = (1 + lm)qs (1 + n + lm)qS ^ 2n + 2nn 2n-i + 2n-4 ,
where the last inequality is due to q < 2qS. ■
