RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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.

Report New Errata