Errata Search
RFC Number:		Errata ID:
Source of RFC		Status:	All/Any Verified+Reported Verified Reported Held for Document Update Rejected
Area Acronym:	All/Any app art gen int ops rai rtg sec tsv wit	Type:	All/Any Editorial Technical
WG Acronym:		Submitter Name:
Other:	All/Any IAB INDEPENDENT IRTF Legacy Editorial	Date Submitted:
Summary Table Full Records

Found 6 records.

Status: Verified (2)

RFC 9497, "Oblivious Pseudorandom Functions (OPRFs) Using Prime-Order Groups", December 2023

Source of RFC: IRTF

Errata ID: 8392
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: daxpedda
Date Reported: 2025-04-25
Verifier Name: Nick Sullivan
Date Verified: 2026-01-27

Section 4 says:

RandomScalar():  Implemented by returning a uniformly random
         Scalar in the range [0, G.Order() - 1].

It should say:

RandomScalar():  Implemented by returning a uniformly random
         Scalar in the range [1, G.Order() - 1].

Notes:

Section 2.1 (https://www.rfc-editor.org/rfc/rfc9497#section-2.1-4.12) states:
> Chooses at random a nonzero element in GF(p).

So `RandomScalar()` implementations can't return 0.

--VERIFIER NOTE--
Verified. Section 2.1 requires nonzero; this fix aligns Section 4 with that requirement. EID 8393 addresses related Section 4.7 implementation guidance (held pending fix text revision).

Errata ID: 8720
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Nick Sullivan
Date Reported: 2026-01-27
Verifier Name: Nick Sullivan
Date Verified: 2026-01-28

Section Appendix A says:

EvaluationElement

It should say:

EvaluatedElement

Notes:

The test vector field name "EvaluationElement" is inconsistent with the RFC body, which uses "evaluatedElement" throughout (Sections 3.3.1-3.3.3). The Appendix A header correctly defines "EvaluatedElement" but the test vector data entries use "EvaluationElement" instead.

Affected locations (all within Appendix A test vectors):
- A.1.1.1, A.1.1.2 (ristretto255-SHA512 OPRF): 2 occurrences
- A.1.2.1, A.1.2.2, A.1.2.3 (ristretto255-SHA512 VOPRF): 4 occurrences
- A.1.3.1, A.1.3.2, A.1.3.3 (ristretto255-SHA512 POPRF): 3 occurrences
- A.2.1.1, A.2.1.2 (decaf448-SHAKE256 OPRF): 2 occurrences
- A.2.2.1, A.2.2.2, A.2.2.3 (decaf448-SHAKE256 VOPRF): 4 occurrences
- A.2.3.1, A.2.3.2, A.2.3.3 (decaf448-SHAKE256 POPRF): 3 occurrences
- A.3.1.1, A.3.1.2 (P256-SHA256 OPRF): 2 occurrences
- A.3.2.1, A.3.2.2, A.3.2.3 (P256-SHA256 VOPRF): 4 occurrences
- A.3.3.1, A.3.3.2, A.3.3.3 (P256-SHA256 POPRF): 3 occurrences
- A.4.1.1, A.4.1.2 (P384-SHA384 OPRF): 2 occurrences
- A.4.2.1, A.4.2.2, A.4.2.3 (P384-SHA384 VOPRF): 4 occurrences
- A.4.3.1, A.4.3.2, A.4.3.3 (P384-SHA384 POPRF): 3 occurrences
- A.5.1.1, A.5.1.2 (P521-SHA512 OPRF): 2 occurrences
- A.5.2.1, A.5.2.2, A.5.2.3 (P521-SHA512 VOPRF): 4 occurrences
- A.5.3.1, A.5.3.2, A.5.3.3 (P521-SHA512 POPRF): 3 occurrences

Total: 45 occurrences across all test vectors.

Supersedes EID 8575 (rejected) which proposed fixing the header instead of the data.

--VERIFIER NOTE--
Verified. Test vector field names should match RFC body terminology.

Status: Held for Document Update (1)

RFC 9497, "Oblivious Pseudorandom Functions (OPRFs) Using Prime-Order Groups", December 2023

Source of RFC: IRTF

Errata ID: 8393
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: daxpedda
Date Reported: 2025-04-25
Held for Document Update by: Nick Sullivan
Date Held: 2026-01-27

Section 4.7 says:

4.7.1.  Rejection Sampling

   Generate a random byte array with Ns bytes and attempt to map to a
   Scalar by calling DeserializeScalar in constant time.
   ...

4.7.2.  Random Number Generation Using Extra Random Bits

   Generate a random byte array with L = ceil(((3 *
   ceil(log2(G.Order()))) / 2) / 8) bytes, and interpret it as an
   integer; reduce the integer modulo G.Order(), and return the result.

It should say:

4.7.1.  Rejection Sampling

   Generate a random byte array with Ns bytes and attempt to map to a
   Scalar by calling DeserializeScalar and checking for a nonzero Scalar
   in constant time.
   ...

4.7.2.  Random Number Generation Using Extra Random Bits

   Generate a random byte array with L = ceil(((3 *
   ceil(log2(G.Order()))) / 2) / 8) bytes, and interpret it as an
   integer; reduce the integer modulo G.Order() - 1, 1, and return the
   result.

Notes:

Section 2.1 states: "Chooses at random a nonzero element
in GF(p)." So RandomScalar() implementations can't return 0.

For rejection sampling I recommend changing DeserializeScalar()
to check for nonzero Scalar and decline those. My suggested
errata is a compromise to keep the change specific.

For "Random Number Generation Using Extra Random Bits" my
suggestion follows FIPS 186-5 A.2.1.

--VERIFIER NOTE--
Held for document update. The underlying issue (RandomScalar
must exclude zero) is valid and addressed by EID 8392, which
fixes the Section 4 range to [1, G.Order()-1]. This erratum's
proposed text for Section 4.7 is unclear ("modulo G.Order() -
1, 1"). For implementers: the correct approach per FIPS 186-5
A.2.1 is (random mod (G.Order()-1)) + 1, producing scalars in
[1, G.Order()-1].

Status: Rejected (3)

RFC 9497, "Oblivious Pseudorandom Functions (OPRFs) Using Prime-Order Groups", December 2023

Source of RFC: IRTF

Errata ID: 7925
Status: Rejected
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Stefan Santesson
Date Reported: 2024-05-07
Rejected by: Colin Perkins
Date Rejected: 2024-05-20

Section 4.3 says:

HashToScalar():  Use hash_to_field from [RFC9380] using L = 48,
         expand_message_xmd with SHA-256, DST = "HashToScalar-" ||
         contextString, and a prime modulus equal to Group.Order().

It should say:

HashToScalar():  Compute uniform_bytes using expand_message =
         expand_message_xmd, DST = "HashToScalar-" || contextString, and
         an output length of 48 bytes, interpret uniform_bytes as a
         384-bit integer in little-endian order, and reduce the integer
         modulo Group.Order().

Notes:

It is incorrect to refer to the hash_to_filed operation of RFC 9380 because the implementation of hash_to_field, as described in section 5.2 of RFC 9380 reduces the result integer mod Field order (not Group order).

7. e_j = OS2IP(tv) mod p

Where p is the characteristic of field F.

The current text imply that the existing hash_to_field implementation for P-256 can be used. But using this will cause a false result due to the mod field order operation.

The a better, and accurate way to describe this is by using the same explanation as for other curve types and specify the use of expand_message_xmd directly modulus Group.Order().
--VERIFIER NOTES--
Discussed on CFRG list. The original text is correct, see https://mailarchive.ietf.org/arch/msg/cfrg/YLqRy76LFlVzeOofGyQiYeDhAuM/

Errata ID: 7999
Status: Rejected
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Quanwei Cai
Date Reported: 2024-06-24
Rejected by: Nick Sullivan
Date Rejected: 2026-01-27

Section 3.3.3 says:

evaluatedElement = G.ScalarInverse(t) * blindedElement

It should say:

evaluatedElement = t * blindedElement

Notes:

This appears in def BlindEvaluate(skS, blindedElement, info). It seems that the evaluatedElement=t * blindedElement, which is consistent with tweakedKey = t * G.Generator()


Verified on CFRG list by co-author with note: I would also change "0" to "seq = 0"

--VERIFIER NOTES--
No change needed. RFC 9497 defines GenerateProof(k, A, B, C, D) to prove k*A = B and k*C[i] = D[i] (Section 2.2.1). In POPRF BlindEvaluate (Section 3.3.3) the proof is generated as GenerateProof(t, G.Generator(), tweakedKey, evaluatedElements, blindedElements), so the element relation being proven is t*evaluatedElement = blindedElement. This is consistent with evaluatedElement being defined as ScalarInverse(t) * blindedElement, since t*(ScalarInverse(t)*blindedElement) = blindedElement. The likely source of confusion is comparing with VOPRF, where the proof wiring uses the opposite direction for the element lists.

Errata ID: 8575
Status: Rejected
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Charles Edward Gagnon
Date Reported: 2025-09-12
Rejected by: Nick Sullivan
Date Rejected: 2026-01-27

Section Appendix A says:

"EvaluatedElement":  The evaluated element output by BlindEvaluate(),
      a serialized Element of Ne bytes long.

It should say:

"EvaluationElement":  The evaluated element output by BlindEvaluate(),
      a serialized Element of Ne bytes long.

Notes:

To match the identifier used in all subsequent test vectors. There is still a slight inconsistency, as "EvaluatedElement" is used throughout the RFC and "EvaluationElement" is used uniquely in "Appendix A. Test Vectors".
--VERIFIER NOTES--
Rejected. The proposed fix changes the header definition to match the test vector data, but the data itself is inconsistent with the RFC body, which uses "evaluatedElement" throughout the protocol specification. The correct fix is to change the test vector field names from "EvaluationElement" to "EvaluatedElement" to align with the protocol specification. A new erratum will be filed with the correct fix.

Report New Errata