Re: [CFRG] Does OPRF/OPAQUE require full implementation of RFC 9380

[Jack Grigg <[e-mail]>]

Hi all,

On Sat, Mar 30, 2024 at 6:56 AM Stefan Santesson <[e-mail]> wrote:

> Section 2.1 in OPR (RFC 9497) states:
>
> "HashToGroup(x):  Deterministically maps an array of bytes x to an element
> of Group.  The map must ensure that, for any adversary receiving R =
> HashToGroup(x), it is computationally difficult to reverse the mapping."
> [..]
>
> It continues to say that "Security properties of this function are
> described in [RFC9380]".
> [..]
>
> I would really appreciate help. Has this been discussed already to any
> detail. Is there any guidance available?
>
As Mike Hamburg alludes to in another message in this thread, the security
property of HashToGroup relied upon here is that the output of the function
must be a uniformly random element of the group, with no easily-determined
relation to any canonical generator of the group (more precisely,
HashToGroup should be indifferentiable from a random oracle; see Sections
2.2.3 and 10.1 of RFC 9380). The proposed approach in your email makes
inputScalar a known quantity, which directly breaks this property
(inputScalar is the easily-determined relation to the canonical generator,
because outputElement = [inputScalar] G).

Regardless of RFC 9497 using "must" instead of "MUST" when describing it,
its reliance on this security property is clear; see Sections 2.1, 4.6, and
7.2.1 of RFC 9497 for further details.

> If this is not good enough. Can you take any simpler path than full RFC
> 9380 implementation?
>
If you use ristretto255 or decaf448, then most of the work should already
be done by the libraries implementing the group (see below). See Section
4.1 of RFC 9497 for an OPRF ciphersuite instantiated over ristretto255 and
SHA-512.

For other groups (such as elliptic curves), there are other approaches like
"try-and-increment", but these are not constant-time and may have other
side-channel vulnerabilities in your setting; you would need to consult a
cryptographer.

On Sat, Mar 30, 2024 at 7:37 AM stef <[e-mail]> wrote:

> tbh i also think this is overkill since for some groups, like ristretto255
> for
> example there is a widely used hashtogroup available in most big
> implementations (like crypto_scalarmult_ed25519 and
> crypto_core_ristretto255_from_hash in libsodium).
>

Just to clarify here for wider benefit: RFC 9496 (which specifies
ristretto255, as well as decaf448) includes an Element Derivation function
(in Section 4.3.4), which when paired with a hash function can be used to
build a hash-to-group operation (which I believe is what library functions
like crypto_core_ristretto255_from_hash in libsodium provide). Appendix B
of RFC 9380 documents precisely how this should be done to be compatible
with it (specifically using an expand_message function that conforms to
Section 5.3 of RFC 9380).

Cheers,
Jack