# RFC Errata

Found 6 records.

## Status: Verified (1)

### RFC 6090, "Fundamental Elliptic Curve Cryptography Algorithms", February 2011

Source of RFC: IETF - NON WORKING GROUPArea Assignment: sec

Errata ID: 3920

**Status: Verified
Type: Technical
**

Reported By: Watson Ladd

Date Reported: 2014-03-15

Verifier Name: Kathleen Moriarty

Date Verified: 2014-07-01

Section Appendix F says:

Then, the product P3=(X3,Y3,Z3) = P1 * P2 is given by: if P1 is the point at infinity, P3 = P2 else if P2 is the point at infinity, P3 = P1 else if u is not equal to 0 but v is equal to 0, P3 = (0,1,0) else if both u and v are not equal to 0, X3 = v * (Z2 * (Z1 * u^2 - 2 * X1 * v^2) - v^3) Y3 = Z2 * (3 * X1 * u * v^2 - Y1 * v^3 - Z1 * u^3) + u * v^3 Z3 = v^3 * Z1 * Z2 else // P2 equals P1, P3 = P1 * P1 w = 3 * X1^2 + a * Z1^2 X3 = 2 * Y1 * Z1 * (w^2 - 8 * X1 * Y1^2 * Z1) Y3 = 4 * Y1^2 * Z1 * (3 * w * X1 - 2 * Y1^2 * Z1) - w^3 Z3 = 8 * (Y1 * Z1)^3

It should say:

Then, the product P3=(X3,Y3,Z3) = P1 * P2 is given by: if P1 is the point at infinity, P3 = P2 else if P2 is the point at infinity, P3 = P1 else if P1=-P2 as projective points P3 = (0,1,0) else if P1 does not equal P2 X3 = v * (Z2 * (Z1 * u^2 - 2 * X1 * v^2) - v^3) Y3 = Z2 * (3 * X1 * u * v^2 - Y1 * v^3 - Z1 * u^3) + u * v^3 Z3 = v^3 * Z1 * Z2 else // P2 equals P1, P3 = P1 * P1 w = 3 * X1^2 + a * Z1^2 X3 = 2 * Y1 * Z1 * (w^2 - 8 * X1 * Y1^2 * Z1) Y3 = 4 * Y1^2 * Z1 * (3 * w * X1 - 2 * Y1^2 * Z1) - w^3 Z3 = 8 * (Y1 * Z1)^3

Notes:

The original algorithm was wrong and produces incorrect answers. There are several fixes that could take place.

## Status: Held for Document Update (5)

### RFC 6090, "Fundamental Elliptic Curve Cryptography Algorithms", February 2011

Source of RFC: IETF - NON WORKING GROUPArea Assignment: sec

Errata ID: 2777

**Status: Held for Document Update
Type: Technical
**

Reported By: Annie Yousar

Date Reported: 2011-04-11

Held for Document Update by: Sean Turner

Section 7.2 says:

KT-I is mathematically and functionally equivalent to ECDSA, and can interoperate with the IEEE [P1363] and ANSI [X9.62] standards for Elliptic Curve DSA (ECDSA) based on fields of characteristic greater than three. KT-I signatures can be verified using the ECDSA verification algorithm, and ECDSA signatures can be verified using the KT-I verification algorithm.

It should say:

For many hash functions KT-I is mathematically and functionally equivalent to ECDSA, and can interoperate with the IEEE [P1363] and ANSI [X9.62] standards for Elliptic Curve DSA (ECDSA) based on fields of characteristic greater than three. KT-I signatures can be verified using the ECDSA verification algorithm, and ECDSA signatures can be verified using the KT-I verification algorithm (refer to Section 10.4).

Notes:

If the hash function h generates a bit string that has a bit length greater than the bit length of the elliptic curve group order, ECDSA as specified in P1363 uses a truncation of the hash value to the left-most bits. The KT-I algorithm does not use this truncation but reduces modulo q. Therefore ECDSA and KT-I with SHA-384 on the P-256 curve result in different signature values. Add a corresponding note in 10.4: The output of the hash used in KT signatures should truncated to the left-most bits if its bit-length is longer than the bit-length of the group order.

Errata ID: 2773

**Status: Held for Document Update
Type: Editorial
**

Reported By: Annie Yousar

Date Reported: 2011-04-11

Held for Document Update by: Sean Turner

Section 2.2 says:

Sometimes an alternative called additive notation is used, in which a * b is denoted as a + b, and a^N is denoted as N * a.

It should say:

Sometimes an alternative called additive notation is used, in which a * b is denoted as a + b, and a^N is denoted as Na.

Notes:

The original text refers to Appendix E some sentences later:

"Appendix E elucidates the correspondence between the two notations."

In the Appendix E the notation "Na" is used, whereas the original text uses the notation "N*a".

Errata ID: 2774

**Status: Held for Document Update
Type: Editorial
**

Reported By: Annie Yousar

Date Reported: 2011-04-11

Held for Document Update by: Sean Turner

Section 2.2 says:

By convention, a^0 is equal to the identity element for any a in G.

It should say:

By convention, a^0 is equal to the identity element and a^1 is equal to a itself for any a in G.

Notes:

Without this convention the explanation on the next page: "... for any integers X and Y: a^(X+Y) = (a^X)*(a^Y) ..." would be incomplete, as being undefined for the integers X=1 and/or Y=1.

Errata ID: 2775

**Status: Held for Document Update
Type: Editorial
**

Reported By: Annie Yousar

Date Reported: 2011-04-11

Held for Document Update by: Sean Turner

Section 2.2 says:

Note that a^M is equal to g^(M modulo R) for any non-negative integer M.

It should say:

Note that a^M is equal to a^(M mod R) for any non-negative integer M.

Notes:

g is a typo. The result of the modulo operation is always denoted in the text by "mod". The notation "modulo" identifies the operation and not the result.

Errata ID: 2776

**Status: Held for Document Update
Type: Editorial
**

Reported By: Annie Yousar

Date Reported: 2011-04-11

Held for Document Update by: Sean Turner

Section 6.2 says:

The integer x shall be converted to an octet string S of length k as follows. The string S shall satisfy k y = SUM 2^(8(k-i)) Si . i = 1

It should say:

The integer y shall be converted to an octet string S of length k as follows. The string S shall satisfy k y = SUM 2^(8(k-i)) Si . i = 1 Note that the conversion fails if y >= 2^(8*k).

Notes:

Typo corrected. The integer y can not be converted, if the octet string is to short.