RFC 7091
GOST R 34.10-2012: Digital Signature Algorithm
GOST R 34.10-2012: Digital Signature Algorithm 💖
Okay bestie, so this is RFC 7091 🦋 It's titled "GOST R 34.10-2012: Digital Signature Algorithm," and it's an Independent Submission, not a standards-track thing. V. Dolmatov (the Ed.) and A. Degtyarev wrote it, both from Cryptocom, Ltd. It's Informational, dated December 2013, with ISSN 2070-1721. The only relationship it lists is that it updates RFC 5832. Super clear! 🎀
Abstract ✨
This doc is basically a guide to the Russian federal standard for digital signatures, GOST R 34.10-2012. That's one of the Russian cryptographic standard algorithms (the ones people call GOST algorithms) 🌸 Russian cryptography is showing up in Internet applications more and more, so this doc is here to help developers and users of GOST R 34.10-2012 with signature generation and verification. It updates RFC 5832.
Status of This Memo ✨
Not a Standards Track spec, ngl. It's published just for information 💜
This is a contribution to the RFC Series, separate from any other RFC stream. The RFC Editor picked to publish it at their discretion and makes no statement about its value for implementation or deployment. Docs the RFC Editor approves for publication are not candidates for any level of Internet Standard. See Section 2 of RFC 5741 for that.
Info about the current status, any errata, and how to give feedback is at http://www.rfc-editor.org/info/rfc7091.
Copyright Notice ✨
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. 🔒
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Read those carefully, because they spell out your rights and restrictions for this doc 🙈
Table of Contents 📜
1. Introduction ....................................................2
1.1. General Information ........................................2
1.2. The Purpose of GOST R 34.10-2012 ...........................3
1.3. Requirements Language ......................................3
2. Scope ...........................................................3
3. Definitions and Notations .......................................4
3.1. Definitions ................................................4
3.2. Notations ..................................................6
4. General Statements ..............................................7
5. Mathematical Conventions ........................................8
5.1. Mathematical Definitions ...................................9
5.2. Digital Signature Parameters ..............................10
5.3. Binary Vectors ............................................12
6. Main Processes .................................................12
6.1. Digital Signature Generation Process ......................13
6.2. Digital Signature Verification ............................13
7. Test Examples (Appendix to GOST R 34.10-2012) ..................14
7.1. The Digital Signature Scheme Parameters ...................15
7.2. Digital Signature Process (Algorithm I) ...................17
7.3. Verification Process of Digital Signature (Algorithm II) ..18
8. Security Considerations ........................................19
9. References .....................................................19
9.1. Normative References ......................................19
9.2. Informative References ....................................201. Introduction ✨
1.1. General Information 💅
- GOST R 34.10-2012 [GOST3410-2012] was developed by the Center for Information Protection and Special Communications of the Federal Security Service of the Russian Federation, with participation from the open joint-stock company "Information Technologies and Communication Systems" (InfoTeCS JSC).
- GOST R 34.10-2012 was approved and introduced by Decree #215 of the Federal Agency on Technical Regulating and Metrology on 07.08.2012.
- GOST R 34.10-2012 replaces GOST R 34.10-2001 [GOST3410-2001], a national standard of the Russian Federation.
Okay so GOST R 34.10-2001 got superseded by GOST R 34.10-2012 from 1 January 2013 🌈 That means every new system that gets presented for certification MUST use GOST R 34.10-2012, and it MAY also use GOST R 34.10-2001 to stay compatible with existing systems. Current systems are allowed to keep using GOST R 34.10-2001 for at least a 5-year period. Main character timeline, fr 👑
This document updates RFC 5832 [RFC5832].
This document is an English translation of GOST R 34.10-2012. [RFC6986] is an English translation of GOST R 34.11-2012, and [RFC5832] is an English translation of GOST R 34.10-2001. 🍓
The terms and concepts in this standard line up with these international standards:
- ISO 2382-2 [ISO2382-2],
- ISO/IEC 9796 [ISO9796-2][ISO9796-3],
- series of standards ISO/IEC 14888 [ISO14888-1] [ISO14888-2] [ISO14888-3] [ISO14888-4], and
- series of standards ISO/IEC 10118 [ISO10118-1] [ISO10118-2] [ISO10118-3] [ISO10118-4].
1.2. The Purpose of GOST R 34.10-2012 🧚
GOST R 34.10-2012 describes how digital signatures get generated and verified. It's built on operations with an elliptic curve points group, defined over a prime finite field. Iconic math, no notes 🔥
Why make this standard? Digital signatures need to come in different levels of resistance, because computer technology keeps growing. Digital signature security rests on two things: how hard it is to compute discrete logarithms in an elliptic curve points group, and the security of the hash function it uses (according to GOST R 34.11-2012 [GOST3411-2012]). Both have to hold up 🛡️
1.3. Requirements Language 💜
Okay, the big requirement words in this doc are "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL". They get read the way RFC 2119 [RFC2119] describes ✨
2. Scope 🎀
GOST R 34.10-2012 defines an electronic digital signature (or just digital signature) scheme. It also covers how to generate and verify digital signatures for a given message (document). This is meant for messages sent over insecure public telecommunication channels, in data processing systems with all kinds of purposes 🦋
Using a digital signature based on GOST R 34.10-2012 makes transmitted messages more resistant to forgery and loss of integrity, compared to the digital signature scheme from the previous standard. That's a real upgrade, bestie 💅
GOST R 34.10-2012 is recommended for creating, operating, and modernizing data processing systems of various purposes. 🌸
3. Definitions and Notations 📖
3.1. Definitions 🧠
Here are the terms the standard uses. Let's get into it 💖
appendix: bit string that is formed by a digital signature and by the arbitrary text field [ISO14888-1].
signature key: element of secret data that is specific to the subject and used only by this subject during the signature generation process [ISO14888-1].
verification key: element of data mathematically linked to the signature key data element that is used by the verifier during the digital signature verification process [ISO14888-1].
domain parameter: element of data that is common for all the subjects of the digital signature scheme, known or accessible to all the subjects [ISO14888-1].
signed message: a set of data elements that consists of the message and the appendix, which is a part of the message [ISO14888-1].
pseudorandom number sequence: a sequence of numbers that is obtained during some arithmetic (calculation) process, used in a specific case instead of a true random number sequence. 🎲
random number sequence: a sequence of numbers of which none can be predicted (calculated) using only the preceding numbers of the same sequence. 🔮
verification process: a process that uses the signed message, the verification key, and the digital signature scheme parameters as initial data, and that gives the conclusion about digital signature validity or invalidity as a result [ISO14888-1].
signature generation process: a process that uses the message, the signature key, and the digital signature scheme parameters as initial data, and that generates the digital signature as the result [ISO14888-1].
witness: element of data that states to the verifier whether the digital signature is valid or invalid.
random number: a number chosen from the definite number set in such a way that every number from the set can be chosen with equal probability. 🎰
message: string of bits of a limited length [ISO14888-1].
hash code: string of bits that is a result of the hash function [ISO14888-1].
hash function: the function that maps bit strings onto bit strings of fixed length, observing the following properties:
- it is difficult to calculate the input data that is the pre-image of the given function value;
- it is difficult to find another input data that is the pre-image of the same function value as is the given input data; and
- it is difficult to find a pair of different input data that produces the same hash function value.
[ISO14888-1]
Notes:
- Property 1 in the context of the digital signature area means that it is impossible to recover the initial message using the digital signature. Property 2 means that it is difficult to find another (falsified) message that produces the same digital signature as a given message. Property 3 means that it is difficult to find a pair of different messages that both produce the same signature. 🕵️♀️
- In this standard, the terms "hash function", "cryptographic hash function", "hashing function", and "cryptographic hashing function" are synonymous, to provide terminological succession to native legal documents currently in force and scientific publications. 🌈
(electronic) digital signature: string of bits that are obtained as a result of the signature generation process [ISO14888-1].
Notes:
- A string of bits that is a signature may have an internal structure, depending on the specific signature generation mechanism. 🧩
- In this standard, the terms "electronic signature", "digital signature", and "electronic digital signature" are synonymous, to provide terminological succession to native legal documents currently in force and scientific publications. ✨
3.2. Notations ✨
okay so this is the notation cheat sheet 🎀 every symbol the spec uses, all in one place, so you don't have to guess what the letters mean 🧚
V_l set of all binary vectors of an l-bit length
V_all set of all binary vectors of an arbitrary finite length
Z set of all integers
p prime number, p > 3
GF(p) finite prime field represented by a set of integers {0,
1, ..., p - 1}
b (mod p) minimal non-negative number, congruent to b modulo p
M user's message, M belongs to V_all
(H1 || H2 ) concatenation of two binary vectors
a, b elliptic curve coefficients
m points of the elliptic curve group order
q subgroup order of group of points of the elliptic curve
O zero point of the elliptic curve
P elliptic curve point of order q
d integer - a signature key
Q elliptic curve point - a verification key
zeta digital signature for the message M
^ the power operator
/= non-equality
sqrt square root4. General Statements 💖
a commonly accepted digital signature scheme (model) is made of three processes, and we're going to be obsessed with all of them 🔥
- generation of a pair of keys (for signature generation and for signature verification),
- signature generation, and
- signature verification.
so here's the tea: GOST R 34.10-2012 does not define a process for generating that pair of keys (for signature and verification) 🙈 instead, the characteristics and the ways to realize that process are left to the involved subjects, who work out the corresponding parameters by agreement 🤝
the digital signature mechanism itself is defined by two main processes (Section 6) 💅
- signature generation (Section 6.1), and
- signature verification (Section 6.2).
the digital signature is meant for authenticating the signatory of the electronic message ✍️ on top of that, using a digital signature gives you a few more properties during signed message transmission, which is honestly iconic:
- realization of control of the transmitted signed message integrity,
- proof of the authorship of the signatory of the message, and
- protection of the message against possible forgery.
here's a little picture of the signed message, Figure 1 🦋
appendix
|
+-------------------------------+
| |
+-----------+ +------------------------+- - - +
| message M |---| digital signature zeta | text |
+-----------+ +------------------------+- - - +
Figure 1: Signed Message Schemethe "digital signature" field gets a buddy, the "text" field 👯 it can hold things like identifiers of the signatory of the message and/or a time label ⏰
the digital signature scheme defined in GOST R 34.10-2012 must be implemented using operations of the elliptic curve points group, defined over a finite prime field, and also with the use of the hash function. 🔥
the cryptographic security of the scheme rests on two things 🔐: how hard it is to solve the discrete logarithm problem in the elliptic curve points group, and the security of the hash function being used. the hash function calculation algorithm is defined in GOST R 34.11-2012 [GOST3411-2012] 🌈
the digital signature scheme parameters needed for signature generation and verification are defined in Section 5.2 ✨ this standard gives you the option of picking one of two options for the parameter requirements, which is giving flexibility 💜
GOST R 34.10-2012 doesn't determine the process for generating those parameters either 🙈 possible sets of them are defined, for example, in [RFC4357] 🎀
the digital signature, which is a binary vector of a 512- or 1024-bit length, must be calculated using a definite set of rules, as stated in Section 6.1 💖
and when a message comes in, its digital signature is accepted or denied following the set of rules stated in Section 6.2 🫶
5. Mathematical Conventions 🌸
to define a digital signature scheme, you need to describe the basic mathematical objects that get used in the signature generation and verification processes 🧠 this section lays out the basic mathematical definitions and the requirements for the scheme's parameters, so buckle up bestie 🎢
5.1. Mathematical Definitions 🧮
suppose a prime number p > 3 is given. then an elliptic curve E, defined over a finite prime field GF(p), is the set of number pairs (x,y), where x and y belong to Fp, satisfying this identity:
y^2 = x^3 + a * x + b (mod p), (1)where a, b belong to GF(p), and 4 * a^3 + 27 * b^2 is not congruent to zero modulo p 💫
there's an invariant of the elliptic curve, J(E), which satisfies this equality:
4 * a^3
J(E) = 1728 * ------------------ (mod p) (2)
4 * a^3 + 27 * b^2the coefficients a, b of the elliptic curve E are defined from the invariant J(E) like this 🪄
| a = 3 * k (mod p),
| (3)
| b = 2 * k (mod p),
J(E)
where k = ----------- (mod p), J(E) /= 0 or 1728
1728 - J(E)the pairs (x, y) that satisfy identity (1) are called "the elliptic curve E points" 💜 x and y are called the x- and y-coordinates of the point, correspondingly 📍
we'll write elliptic curve points as Q(x, y) or just Q 💅 two elliptic curve points are equal if their x- and y-coordinates are equal 🫶
now the addition operation, denoted by "+", on the set of all elliptic curve E points 🎀 for two arbitrary points Q1 (x1, y1) and Q2 (x2, y2), there are several variants, so let's go through them 🧚
first up, suppose the coordinates of points Q1 and Q2 satisfy the condition x1 /= x2. then their sum is a point Q3 (x3, y3), with coordinates defined by these congruences ✨
x3 = lambda^2 - x1 - x2 (mod p),
(4)
y3 = lambda * (x1 - x3) - y1 (mod p),
y1 - y2
where lambda = -------- (mod p).
x1 - x2next, if x1 = x2 and y1 = y2 /= 0, then the Q3 coordinates are defined like this 🔥
x3 = lambda^2 - x1 * 2 (mod p),
(5)
y3 = lambda * (x1 - x3) - y1 (mod p),
3 * x1^2 + a
where lambda = ------------ (mod p)
y1 * 2and if x1 = x2 and y1 = -y2 (mod p), then the sum of Q1 and Q2 is called the zero point O, and its x- and y-coordinates are not determined 🌌 in this case, point Q2 is called the negative of point Q1 🪞 for the zero point, these equalities hold:
O + Q = Q + O = Q, (6)where Q is an arbitrary point of elliptic curve E 💖
the set of all points of elliptic curve E, zero point included, forms a finite abelian (commutative) group of order m under the addition operation we just defined 🎉 for m, these inequalities hold:
p + 1 - 2 * sqrt(p) =< m =< p + 1 + 2 * sqrt(p) (7)last one in this section 💅 a point Q is called "a point of multiplicity k", or just "a multiple point of the elliptic curve E", if for some point P, this equality holds:
Q = P + ... + P = k * P (8)
-----+-----
k5.2. Digital Signature Parameters 🎀
the digital signature parameters are these, and they're kind of the whole main character cast 👑
- prime number p is an elliptic curve modulus.
- elliptic curve E, defined by its invariant J(E) or by coefficients a, b belonging to GF(p).
- integer m is an elliptic curve E points group order.
- prime number q is an order of a cyclic subgroup of the elliptic curve E points group, which satisfies these conditions:
m = nq, n belongs to Z, n >= 1
(9)
2^254 < q < 2^256 or 2^508 < q < 2^512- point P /= O of an elliptic curve E, with coordinates (x_p, y_p), satisfying the equality q * P = O.
- hash function h(.):V_all -> V_l, which maps messages represented as binary vectors of arbitrary finite length onto binary vectors of an l-bit length. the hash function is defined in GOST R 34.11-2012 [GOST3411-2012].
if 2^254 < q < 2^256, then l = 256. if 2^508 < q < 2^512, then l = 512.
every user of the digital signature scheme must have its own personal keys 🔑
- signature key, which is an integer d, satisfying the inequality 0 < d < q;
- verification key, which is an elliptic curve point Q with coordinates (x_q, y_q), satisfying the equality d * P = Q.
the parameters we just introduced have to meet these requirements, no exceptions 🙅♀️
- it is necessary that the condition p^t /= 1 (mod q) holds for all integers t = 1, 2, ..., B, where
B = 31 if 2^254 < q < 2^256, or B = 131 if 2^508 < q < 2^512;
- it is necessary that the inequality m /= p holds;
- the curve invariant must satisfy the condition J(E) /= 0, 1728.
5.3. Binary Vectors 🦋
to define the digital signature generation and verification processes, you have to map the set of integers onto the set of binary vectors of an l-bit length 🧩 consider this binary vector of an l-bit length, where the low-order bits sit on the right and the high-order ones sit on the left 👀
H = (alpha[l-1], ..., alpha[0]), H belongs to V_l (10)where alpha[i], i = 0, ..., l-1 are equal to 1 or to 0. the number alpha, which belongs to Z, is mapped onto the binary vector h if this equality holds 🔢
alpha = alpha[0]*2^0 + alpha[1]*2^1 + ... + alpha[l-1]*2^(l-1) (11)for two binary vectors H1 and H2 ✌️
H1 = (alpha[l-1], ..., alpha[0]),
(12)
H2 = (beta[l-1], ..., beta[0]),which correspond to integers alpha and beta, we define a concatenation (union) operation like so 🫶
H1||H2 = (alpha[l-1], ..., alpha[0], beta[l-1], ..., beta[0]) (13)the result is a binary vector of 2*l-bit length, made of the coefficients of the vectors H1 and H2 🌈 and the formulae above also give you a way to split a binary vector H of 2*l-bit length back into two binary vectors of l-bit length, since H is the concatenation of the two 🧠
6. Main Processes 👑
in this section, we get into the digital signature generation and verification processes of a user's message 💫
to make these processes work, all users need to know the digital signature scheme parameters, and those parameters must satisfy the requirements of Section 5.2 🎀
on top of that, every user must have the signature key d and the verification key Q(x_q, y_q), and those keys also must satisfy the requirements of Section 5.2 🫶
6.1. Digital Signature Generation Process ✨
okay so, to make a digital signature for a message M that lives in V_all, you run through these steps. This is Algorithm I 💅
Step 1. Hash the message to get the hash code M 🔥:
H = h(M) (14)Step 2. Turn the binary vector H into an integer alpha, then find e 🧮:
e = alpha (mod q) (15)If e = 0, then set e = 1. 🫶
Step 3. Make a random (or pseudorandom) integer k that fits this inequality 🎲:
0 < k < q (16)Step 4. Work out the elliptic curve point C = k * P and get r 🦋:
r = x_C (mod q), (17)where x_C is the x-coordinate of the point C. If r = 0, go back to step 3. 🔁
Step 5. Calculate s 💖:
s = (r * d + k * e) (mod q) (18)If s = 0, go back to Step 3. 🙈
Step 6. Turn r and s into the binary vectors R and S, then glue them together with concatenation to get the digital signature zeta = (R || S) 👑.
The inputs here are the signature key d and the message M you want to sign. The output is the digital signature zeta. ✨
6.2. Digital Signature Verification 🌸
To check a digital signature on a received message M, do these steps. This is Algorithm II 🧚
Step 1. Work out the integers r and s from the received signature zeta. If 0 < r < q and 0 < s < q both hold, move on to the next step. Otherwise, the signature is invalid 💀.
Step 2. Hash the received message M 🍓:
H = h(M) (19)Step 3. Turn the binary vector H into an integer alpha, then check e 🫶:
e = alpha (mod q) (20)If e = 0, then set e = 1.
Step 4. Calculate the inverse 🦋:
v = e^(-1) (mod q) (21)Step 5. Calculate the two values 💜:
z1 = s * v (mod q), z2 = -r * v (mod q) (22)Step 6. Calculate the elliptic curve point C = z1 * P + z2 * Q and get R 🌈:
R = x_C (mod q), (23)where x_C is the x-coordinate of the point.
Step 7. If R = r holds, the signature is accepted. Otherwise, the signature is invalid 😭.
The inputs are the signed message M, the digital signature zeta, and the verification key Q. The output is the witness of whether the signature is valid or invalid. 🎀
7. Test Examples (Appendix to GOST R 34.10-2012) 🧪
okay this section is an appendix to GOST R 34.10-2012. It's there as a reference, but it isn't officially part of the standard 🙈
The values here for the parameters p, a, b, m, q, P, the signature key d, and the verification key Q are recommended only for testing whether your real implementations of the algorithms in GOST R 34.10-2012 are correct 💅.
Every number is shown in decimal and hexadecimal. Numbers starting with 0x are in hex. The symbol "\" means the number keeps going on the next line. For example, this:
12345\\
67890
0x499602D2is 1234567890 in decimal and 0x499602D2 in hex 🍓.
7.1. The Digital Signature Scheme Parameters 💖
These are the parameters you use to generate and verify a digital signature (see Section 5.2) 🔥.
7.1.1. Elliptic Curve Modulus
Here's the value for p in this example ✨:
p = 57896044618658097711785492504343953926\\
634992332820282019728792003956564821041
p = 0x8000000000000000000000000000\\
0000000000000000000000000000000004317.1.2. Elliptic Curve Coefficients
Here are the values for a and b 🦋:
a = 7
a = 0x7
b = 43308876546767276905765904595650931995\\
942111794451039583252968842033849580414
b = 0x5FBFF498AA938CE739B8E022FBAFEF40563\\
F6E6A3472FC2A514C0CE9DAE23B7E7.1.3. Elliptic Curve Points Group Order
Here's the value for m 🧚:
m = 5789604461865809771178549250434395392\\
7082934583725450622380973592137631069619
m = 0x80000000000000000000000000000\\
00150FE8A1892976154C59CFC193ACCF5B37.1.4. Order of Cyclic Subgroup of Elliptic Curve Points Group
Here's the value for q 👑:
q = 5789604461865809771178549250434395392\\
7082934583725450622380973592137631069619
q = 0x80000000000000000000000000000001\\
50FE8A1892976154C59CFC193ACCF5B37.1.5. Elliptic Curve Point Coordinates
Here are the coordinates for point P 🌈:
x_p = 2
x_p = 0x2
y_p = 40189740565390375033354494229370597\\
75635739389905545080690979365213431566280
y_p = 0x8E2A8A0E65147D4BD6316030E16D19\\
C85C97F0A9CA267122B96ABBCEA7E8FC87.1.6. Signature Key
For this example, we pretend the user has this signature key d 🔐:
d = 554411960653632461263556241303241831\\
96576709222340016572108097750006097525544
d = 0x7A929ADE789BB9BE10ED359DD39A72C\\
11B60961F49397EEE1D19CE9891EC3B287.1.7. Verification Key
For this example, we pretend the user has the verification key Q with these coordinates 🫶:
x_q = 57520216126176808443631405023338071\\
176630104906313632182896741342206604859403
x_q = 0x7F2B49E270DB6D90D8595BEC458B5\\
0C58585BA1D4E9B788F6689DBD8E56FD80B
y_q = 17614944419213781543809391949654080\\
031942662045363639260709847859438286763994
y_q = 0x26F1B489D6701DD185C8413A977B3\\
CBBAF64D1C593D26627DFFB101A87FF77DA7.2. Digital Signature Process (Algorithm I) 🔥
Say you've done Steps 1-3 of Algorithm I (Section 6.1). You end up with these values 💅:
e = 2079889367447645201713406156150827013\\
0637142515379653289952617252661468872421
e = 0x2DFBC1B372D89A1188C09C52E0EE\\
C61FCE52032AB1022E8E67ECE6672B043EE5
k = 538541376773484637314038411479966192\\
41504003434302020712960838528893196233395
k = 0x77105C9B20BCD3122823C8CF6FCC\\
7B956DE33814E95B7FE64FED924594DCEAB3The multiple point C = k * P has these coordinates ✨:
x_C = 297009809158179528743712049839382569\\
90422752107994319651632687982059210933395
x_C = 0x41AA28D2F1AB148280CD9ED56FED\\
A41974053554A42767B83AD043FD39DC0493
y[C] = 328425352786846634770946653225170845\\
06804721032454543268132854556539274060910
y[C] = 0x489C375A9941A3049E33B34361DD\\
204172AD98C3E5916DE27695D22A61FAE46EThe parameter r = x_C (mod q) comes out to 🦋:
r = 297009809158179528743712049839382569\\
90422752107994319651632687982059210933395
r = 0x41AA28D2F1AB148280CD9ED56FED\\
A41974053554A42767B83AD043FD39DC0493The parameter s = (r * d + k * e)(mod q) comes out to 🧚:
s = 57497340027008465417892531001914703\\
8455227042649098563933718999175515839552
s = 0x1456C64BA4642A1653C235A98A602\\
49BCD6D3F746B631DF928014F6C5BF9C407.3. Verification Process of Digital Signature (Algorithm II) 🌸
Say you've done Steps 1-3 of Algorithm II (Section 6.2). You get this value 💖:
e = 2079889367447645201713406156150827013\\
0637142515379653289952617252661468872421
e = 0x2DFBC1B372D89A1188C09C52E0EE\\
C61FCE52032AB1022E8E67ECE6672B043EE5Then the parameter v = e^(-1) (mod q) comes out to 🫶:
v = 176866836059344686773017138249002685\\
62746883080675496715288036572431145718978
v = 0x271A4EE429F84EBC423E388964555BB\\
29D3BA53C7BF945E5FAC8F381706354C2The parameters z1 = s * v (mod q) and z2 = -r * v (mod q) come out to 💜:
z1 = 376991675009019385568410572935126561\\
08841345190491942619304532412743720999759
z1 = 0x5358F8FFB38F7C09ABC782A2DF2A\\
3927DA4077D07205F763682F3A76C9019B4F
z2 = 141719984273434721125159179695007657\\
6924665583897286211449993265333367109221
z2 = 0x3221B4FBBF6D101074EC14AFAC2D4F7\\
EFAC4CF9FEC1ED11BAE336D27D527665The point C = z1 * P + z2 * Q has these coordinates 🌈:
x_C = 2970098091581795287437120498393825699\\
0422752107994319651632687982059210933395
x_C = 0x41AA28D2F1AB148280CD9ED56FED\\
A41974053554A42767B83AD043FD39DC0493
y[C] = 3284253527868466347709466532251708450\\
6804721032454543268132854556539274060910
y[C] = 0x489C375A9941A3049E33B34361DD\\
204172AD98C3E5916DE27695D22A61FAE46EThen the parameter R = x_C (mod q) comes out to 👑:
R = 2970098091581795287437120498393825699\\
0422752107994319651632687982059210933395
R = 0x41AA28D2F1AB148280CD9ED56FED\\
A41974053554A42767B83AD043FD39DC0493Since R = r holds, the digital signature is accepted 🎉.
8. Security Considerations 🔐
This entire document is about security considerations. 😱
9. References 📚
9.1. Normative References
[GOST3410-2001] "Information technology. Cryptographic data
security. Signature and verification processes of
[electronic] digital signature", GOST R 34.10-2001,
Gosudarstvennyi Standard of Russian Federation,
Government Committee of Russia for Standards, 2001.
(In Russian)
[GOST3410-2012] "Information technology. Cryptographic data
security. Signature and verification processes of
[electronic] digital signature", GOST R 34.10-2012,
Federal Agency on Technical Regulating and
Metrology, 2012.
[GOST3411-2012] "Information technology. Cryptographic Data
Security. Hashing function", GOST R 34.11-2012,
Federal Agency on Technical Regulating and
Metrology, 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4357] Popov, V., Kurepkin, I., and S. Leontiev,
"Additional Cryptographic Algorithms for Use with
GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001,
and GOST R 34.11-94 Algorithms", RFC 4357, January
2006.9.2. Informative References 📚
okay so this is the reading list bit, and these are the extra docs the spec points to for background 🤓 none of them are required to get the main ideas, but they're where the deeper stuff lives 💅
[ISO2382-2]ISO, "Data processing - Vocabulary - Part 2: Arithmetic and logic operations", ISO 2382-2, 1976.[ISO9796-2]ISO/IEC, "Information technology - Security techniques - Digital signatures giving message recovery - Part 2: Integer factorization based mechanisms", ISO/IEC 9796-2, 2010.[ISO9796-3]ISO/IEC, "Information technology - Security techniques - Digital signature schemes giving message recovery - Part 3: Discrete logarithm based mechanisms", ISO/IEC 9796-3, 2006.[ISO14888-1]ISO/IEC, "Information technology - Security techniques - Digital signatures with appendix - Part 1: General", ISO/IEC 14888-1, 2008.[ISO14888-2]ISO/IEC, "Information technology - Security techniques - Digital signatures with appendix - Part 2: Integer factorization based mechanisms", ISO/IEC 14888-2, 2008.[ISO14888-3]ISO/IEC, "Information technology - Security techniques - Digital signatures with appendix - Part 3: Discrete logarithm based mechanisms", ISO/IEC 14888-3,2006.[ISO14888-4]ISO/IEC, "Information technology - Security techniques - Digital signatures with appendix - Part 3: Discrete logarithm based mechanisms. Amendment 1. Elliptic Curve Russian Digital Signature Algorithm, Schnorr Digital Signature Algorithm, Elliptic Curve Schnorr Digital Signature Algorithm, and Elliptic Curve Full Schnorr Digital Signature Algorithm", ISO/IEC 14888-3:2006/Amd 1, 2010.[ISO10118-1]ISO/IEC, "Information technology - Security techniques - Hash-functions - Part 1: General", ISO/IEC 10118-1, 2000.[ISO10118-2]ISO/IEC, "Information technology - Security techniques - Hash-functions - Part 2: Hash-functions using an n-bit block cipher algorithm", ISO/IEC 10118-2, 2010.[ISO10118-3]ISO/IEC, "Information technology - Security techniques - Hash-functions - Part 3: Dedicated hash-functions", ISO/IEC 10118-3, 2004.[ISO10118-4]ISO/IEC, "Information technology - Security techniques - Hash-functions - Part 4: Hash-functions using modular arithmetic", ISO/IEC 10118-4, 1998.[RFC5832]Dolmatov, V., Ed., "GOST R 34.10-2001: Digital Signature Algorithm", RFC 5832, March 2010.[RFC6986]Dolmatov, V., Ed., and A. Degtyarev, "GOST R 34.11-2012: Hash Function", RFC 6986, August 2013.
Authors' Addresses 🫶
Okay, the people behind this spec, and where to find them 💖
Vasily Dolmatov (editor)
Cryptocom, Ltd.
14 Kedrova St., Bldg. 2
Moscow, 117218
Russian Federation
EMail: dol@cryptocom.ru
Alexey Degtyarev
Cryptocom, Ltd.
14 Kedrova St., Bldg. 2
Moscow, 117218
Russian Federation
EMail: alexey@renatasystems.org📦 where this page comes from
- ietf: rfc7091 2013-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms