[CFRG] G.HashToScalar - Errata for OPRF (RFC 9497) ?

[Stefan Santesson <[e-mail]>]

After successfully implementing RFC 9380 (hash2Curve) with very minor 
issue, I really got stuck trying to get the test vectors of OPAQUE and 
OPRF to work.

After sorting the issue (by reading the details of the code in the 
reference implementation) I think the OPRF document has some issues 
(possibly errata).


Here was the root of my implementation problems.


1) DST as input elements in G.HashToScalar(x)

In section 2 HashToScalar is said to have one input (x). However in 
section 3.2.1 (DeriveKeyPair) it has 2 inputs (x, and the DST to use).

In section 4 HashToScalar is said to always have the DST = 
"HashToScalar-" || contextString, It is therefore very confusing to find 
this function with 2 input values in 3.2.1 specifying another DST.

I didn't know how to interpret that and ended up implementing it wrong 
(With "DeriveKeyPair" as part of the input x).

Shouldn't HashToScalar be defined to have 2 input values (x , dst) as 
implemented in the reference, and as specified in 3.2.1, where dst 
defaults to "HashToScalar-" || contextString if absent ?


2) Curve order of Field order?

The second thing that threw me off the wagon was that for OPRF(P-256, 
SHA-256) the definition was:

"Use hash_to_field from [RFC9380] using L = 48"

The problem here is that hash_to_field (RFC 9380) reduces the scalar mod 
Field order (characteristics), while OPRF requires this to be reduced to 
mod Curve (Group) order.

Yes, the text is right there in your face ("and a prime modulus equal to 
Group.Order()") but it so easily missed.


I think the correct/better way to say this is how this is expressed for 
e.g. ristretto255

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

This text more clearly focus on the use of the expand_message_xmd 
function instead of hash_to_field, escaping the issue the hash_to_field 
reduces the result to the Field characteristic. But this text has the 
problem of saying that the DST is always "HashToScalar-" || 
contextString which is not always true (see above).


I don't know if any of these should be fixed in an errata? I leave that 
up to you. If you think so, I could help write one.


-- 
________________
Stefan Santesson