[CFRG] Re: [Technical Errata Reported] RFC9497 (7925)

[Jack Grigg <[e-mail]>]

Hi all,

On Tue, May 7, 2024 at 2:34 PM RFC Errata System <[e-mail]>
wrote:

> The following errata report has been submitted for RFC9497,
> "Oblivious Pseudorandom Functions (OPRFs) Using Prime-Order Groups".
>
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7925
>
> --------------------------------------
> Type: Technical
> Reported by: Stefan Santesson <[e-mail]>
>
> Section: 4.3
>
> Original Text
> -------------
> 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().
>
> Corrected Text
> --------------
> 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).
>

This is a misreading of both RFC 9380 and RFC 9497.

RFC 9380 Section 5.2 defines the hash_to_field parameters. These parameters
in particular are relevant:

> - F, a finite field of characteristic p and order q = p^m.
> - p, the characteristic of F (see immediately above).
> - m, the extension degree of F, m >= 1 (see immediately above).

I'll use F.p, F.q, and F.m to reference these below.

RFC 9497 Section 2.1 defines Group.Order() (somewhat tautologically) as the
order of the group (p). It then defines scalars thusly:

> Scalar multiplication by r is equivalent to the repeated application of
the group operation on an element A with itself r - 1 times; [..] The set
of scalars corresponds to GF(p), a prime field of order p.

It is therefore correct to refer to hash_to_field in RFC 9497 in the
context of producing a scalar of the Group. The Field order F.q of that
scalar field is precisely Group.Order() by definition, and because it is
also prime by definition (and thus has no factors), this forces F.m = 1 and
thus F.p = F.q.


>  7.     e_j = OS2IP(tv) mod p
>
> Where p is the characteristic of field F.
>

Per above, F.p here is precisely Group.Order().

Cheers,
Jack


>
> 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().
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". (If it is spam, it
> will be removed shortly by the RFC Production Center.) Please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> will log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC9497 (draft-irtf-cfrg-voprf-21)
> --------------------------------------
> Title               : Oblivious Pseudorandom Functions (OPRFs) Using
> Prime-Order Groups
> Publication Date    : December 2023
> Author(s)           : A. Davidson, A. Faz-Hernandez, N. Sullivan, C. A.
> Wood
> Category            : INFORMATIONAL
> Source              : Crypto Forum Research Group
> Stream              : IRTF
> Verifying Party     : IRSG
>
> _______________________________________________
> CFRG mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>