Found 4 records.

Status: Reported (3)

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

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

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"

Errata ID: 8392
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: daxpedda
Date Reported: 2025-04-25

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.

Errata ID: 8393
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: daxpedda
Date Reported: 2025-04-25

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 (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.

For rejection sampling I actually recommend changing `DeserializeScalar()` instead to check for nonzero Scalar and decline those. My suggested errata is just a compromise to keep the change as specific as possible. Changing `DeserializeScalar()` might need a separate discussion, but I will await feedback for that.

For "Random Number Generation Using Extra Random Bits" my suggestion is to follow FIPS 186-5 A.2.1 (https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf#%5B%7B%22num%22%3A154%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C70%2C586%2C0%5D), which is described in my errata. I found no standard referring to Ristretto255, but the one provided by FIPS for ECDSA works as well here.

Status: Rejected (1)

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

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/

Report New Errata