# RFC Errata

Found 5 records.

## Status: Verified (5)

### RFC 7836, "Guidelines on the Cryptographic Algorithms to Accompany the Usage of Standards GOST R 34.10-2012 and GOST R 34.11-2012", March 2016

Source of RFC: INDEPENDENT
Errata ID: 6197

**Status: Verified
Type: Technical
Publication Format(s) : TEXT**

Reported By: Billy Brumley

Date Reported: 2020-06-03

Verifier Name: Adrian Farrel

Date Verified: 2020-07-01

Section 3 says:

When a point on an elliptic curve is given to an input of a hash function, affine coordinates for short Weierstrass form are used (see Section 5): an x coordinate value is fed first, a y coordinate value is fed second, both in little-endian format.

It should say:

When a point on an elliptic curve is given to an input of a hash function, affine coordinates for short Weierstrass form are used (see Section 5): an x coordinate value is fed first, a y coordinate value is fed second, both in little-endian format. If the point to be fed to the hash function is zero point, the calculation MUST NOT be performed and an error SHOULD be reported on a protocol level.

Notes:

A new sentence added at the end of the paragraph explicitly defines the processing in case when the zero point is fed to the hash function.

Errata ID: 6198

**Status: Verified
Type: Technical
Publication Format(s) : TEXT**

Reported By: Billy Brumley

Date Reported: 2020-06-03

Verifier Name: Adrian Farrel

Date Verified: 2020-07-01

Section 4.3.1 says:

KEK_VKO (x, y, UKM) is calculated using the formulas: KEK_VKO (x, y, UKM) = H_256 (K (x, y, UKM)), K (x, y, UKM) = (m/q*UKM*x mod q)*(y*P),

It should say:

KEK_VKO (x, y, UKM) is calculated using the formulas: KEK_VKO (x, y, UKM) = H_256 (K (x, y, UKM)), K (x, y, UKM) = (m/q*(UKM*x mod q))*(y*P),

Notes:

For now the original text may be interpreted in the wrong way that both multiplications inside the brackets should be performed modulo q. However, multiplication by m/q must be a simple integer multiplication, without reduction modulo q, to eliminate small subgroup component of the input elliptic curve point. The proposed text modification clarifies the correct types and order of multiplication.

Errata ID: 6199

**Status: Verified
Type: Technical
Publication Format(s) : TEXT**

Reported By: Billy Brumley

Date Reported: 2020-06-03

Verifier Name: Adrian Farrel

Date Verified: 2020-07-01

Section 4.3.2 says:

KEK_VKO (x, y, UKM) is calculated using the formulas: KEK_VKO (x, y, UKM) = H_512 (K (x, y, UKM)), K (x, y, UKM) = (m/q*UKM*x mod q)*(y*P),

It should say:

KEK_VKO (x, y, UKM) is calculated using the formulas: KEK_VKO (x, y, UKM) = H_512 (K (x, y, UKM)), K (x, y, UKM) = (m/q*(UKM*x mod q))*(y*P),

Notes:

For now the original text may be interpreted in the wrong way that both multiplications inside the brackets should be performed modulo q. However, multiplication by m/q must be a simple integer multiplication, without reduction modulo q, to eliminate small subgroup component of the input elliptic curve point. The proposed text modification clarifies the correct types and order of multiplication.

Errata ID: 6200

**Status: Verified
Type: Technical
Publication Format(s) : TEXT**

Reported By: Billy Brumley

Date Reported: 2020-06-03

Verifier Name: Adrian Farrel

Date Verified: 2020-07-01

Section 4.3.1 says:

where m and q are the parameters of an elliptic curve defined in the GOST R 34.10-2012 [GOST3411-2012] standard (m is an elliptic curve points group order, q is an order of a cyclic subgroup), P is a non- zero point of the subgroup; P is defined by a protocol.

It should say:

where m and q are the parameters of an elliptic curve defined in the GOST R 34.10-2012 [GOST3411-2012] standard (m is an elliptic curve points group order, q is an order of a cyclic subgroup), P is a non- zero point of the subgroup; P is defined by a specification of an elliptic curve or by a protocol. Note that in most practical cases the private key y is unknown so the point (y*P) is just a pair of coordinates, which MUST be checked for satisfying the curve equation before calculating the K value.

Notes:

The proposed text clarifies the P point specification ways and the need to check the public key of one side for belonging to the elliptic curve used by the opposite side.

Errata ID: 6201

**Status: Verified
Type: Technical
Publication Format(s) : TEXT**

Reported By: Billy Brumley

Date Reported: 2020-06-03

Verifier Name: Adrian Farrel

Date Verified: 2020-07-01

Section 4.3.2 says:

where m and q are the parameters of an elliptic curve defined in the GOST R 34.10-2012 [GOST3411-2012] standard (m is an elliptic curve points group order, q is an order of a cyclic subgroup), P is a non- zero point of the subgroup; P is defined by a protocol.

It should say:

where m and q are the parameters of an elliptic curve defined in the GOST R 34.10-2012 [GOST3411-2012] standard (m is an elliptic curve points group order, q is an order of a cyclic subgroup), P is a non- zero point of the subgroup; P is defined by a specification of an elliptic curve or by a protocol. Note that in most practical cases the private key y is unknown so the point (y*P) is just a pair of coordinates, which MUST be checked for satisfying the curve equation before calculating the K value.

Notes:

The proposed text clarifies the P point specification ways and the need to check the public key of one side for belonging to the elliptic curve used by the opposite side.