RFC9497 OPRF works + integrating output

[wmcelderry]

Hi All,

Thanks for making and sharing such a useful repository!

I wanted to flag that I've followed the OPRF RFC 9497 and been able to achieve the (2!) test vector results for 'OPRF mode' with sodium using ristretto255 and the h2c functions on the master thread, and discuss how to feed back to the project.

It has involved one minor tweak to your code to get it matching the test vectors.

There are two things I think could be useful to the project:

1. Code to modify/overload the h2c functions implemented on the master branch to take an extra ctx_len parameter.
2. Using the test vectors from the RFC.

While these are both trivial, if these are useful let me know and I'll explore how I can support.

More detail:

The h2c functions need an extra parameter: the length of the context 'string'. I have code, can share if useful.

The current implementation on the `master` branch calculates the string length using strlen/the null byte, but (frustratingly) the DST in the RFC9497 can have a null byte in the middle of the string for the OPRF mode (designated 'mode 0' and the `0` gets written as a binary byte in the middle of the DST - confirmed by matching output from the test vectors).

1. Will you integrate this tweak (in any form) into your library, or is it going to be a project specific fork?
2. [if you will integrate the mods] Do you want to overload the functions with and without a ctx length or drop the length calculating API and only have an API which provides the length?
3. Would you like me to make a PR? (I've implemented the modified h2c functions that replace the original so they require a ctx_len parameter, but trivial to overload and chain the implementation)
4. What is required to get the h2c functions in to the stable build? (test-vectors: see next point)

Are the test vectors useful? If so how should I make them available?

I saw another discussion saying test vectors are not available for ristretto255 H2C, but they are implied by the test vectors in RFC9497.

This is true, the test vectors given are for known 'blinded' elements, with specified blinding factor, so not quite verbatim. It is trivial to recover the originals as the blind is given too. I can confirm that h2c must work (for ristretto255-SHA512) to get the blinded element, but what is the best (set) of tests?

• I can provide code to take the values in the RFC and (at test time) they can be dynamically unblinded. This would allow readable and verifiable public data to be used, but the test would be on two steps (the unblind and the h2c). That could cause confusion should a test fail.
• I can unblind the element and use it to create a test vector based on the input to h2c creating the correct element, but this is obviously not a well-known test value as it is not the published test vector.
• I can implement a test that uses h2c and then blinds with the same factor, but like the first point this test multiple factors in a single test
• I can implement a multi-step test that (for example) uses h2c and confirms that the output matches the manually unblinded test vector, then blinds it with the blinding value and confirms that it matches the published test vector. I could reverse it and start with the published test vector, calculate the unblinding factor and unblind it, then verify that gets the expected output, then verify the h2c gets the matching output.
• I can implement some other combination of the above all thoughts welcome.

[jedisct1]

The context can be binary (and therefore has a defined length), but are there protocols where the context is not a string? From what I’ve seen so far, H2C always uses a fixed string.

More test vectors can be certainly be added to core_ed25519_h2c.c

[wmcelderry]

sorry, I've posted a reply to this as a new comment below. I hadn't understood there were different ways to reply until I accidentally replied to my own comment.

[wmcelderry]

Yes, my understanding is the context is binary, not just the content. That is supported by the matching text vectors (assuming I haven't got matching test vectors through a very confusing bug!).

Please do sanity check though! - a few explanatory excerpts from rfcs (click to unfold)

RFC9497

3.1

3.1.  Configuration

   Each of the three protocol variants are identified with a one-byte
   value (in hexadecimal):

                            +===========+=======+
                            | Mode      | Value |
                            +===========+=======+
                            | modeOPRF  | 0x00  |
                            +-----------+-------+
                            | modeVOPRF | 0x01  |
                            +-----------+-------+
                            | modePOPRF | 0x02  |
                            +-----------+-------+

                             Table 1: Identifiers
                            for Protocol Variants

   Additionally, each protocol variant is instantiated with a
   ciphersuite or suite.  Each ciphersuite is identified with an ASCII
   string identifier, referred to as identifier; see Section 4 for the
   set of initial ciphersuite values.

   The mode and ciphersuite identifier values are combined to create a
   "context string" used throughout the protocol with the following
   function:

   def CreateContextString(mode, identifier):
     return "OPRFV1-" || I2OSP(mode, 1) || "-" || identifier

1.2

1.2.  Notation and Terminology

   The following functions and notation are used throughout the
   document.

   ...

   *  I2OSP(x, xLen) converts a nonnegative integer x into a byte array
      of specified length xLen, as described in [RFC8017].  Note that
      this function returns a byte array in big-endian byte order.

RFC8017

[4.1](https://www.rfc-editor.org/rfc/rfc8017#section-4.1).  I2OSP

   I2OSP converts a nonnegative integer to an octet string of a
   specified length.

   I2OSP (x, xLen)

   Input:

      x        nonnegative integer to be converted

      xLen     intended length of the resulting octet string

   Output:

         X corresponding octet string of length xLen

   Error:  "integer too large"

   Steps:

      1.  If x >= 256^xLen, output "integer too large" and stop.

      2.  Write the integer x in its unique xLen-digit representation in
          base 256:

             x = x_(xLen-1) 256^(xLen-1) + x_(xLen-2) 256^(xLen-2) + ...
             + x_1 256 + x_0,

          where 0 <= x_i < 256 (note that one or more leading digits
          will be zero if x is less than 256^(xLen-1)).

[jedisct1]

libsodium.js is really the area where help would be most valuable. I’m having a hard time with it.

The wrapper code is difficult to follow, the packages are hard to maintain, and the generated output could be more efficient. It would be great to have separate WebAssembly-only and JavaScript-only builds, explore wasm32-freestanding builds that work everywhere without Emscripten, and possibly make the codebase more modular.

[wmcelderry]

Slight misunderstanding: I was meaning specifically with the H2C functions. I was hoping that supporting development of the current or next version of the H2C code may get something to stable pretty quickly.

I wish I had the time to help more with the other things on your list, they sound interesting, but bills need paying and family need supporting: that doesn't really leave me with much time to call my own!

I was intending to get OPAQUE working, but without the H2C components being stable anytime soon, that may be a problem.

I'd love to know what is stopping the H2C code from being released as 'stable'? Can you share any more detail about why you don't like it?

[jedisct1]

The API cannot change any more after it's designed and I'm not sure it can currently cover all the use cases.

For example, implementing HPKE without dynamic allocations cannot currently be done, because the label to integer function requires a steaming interface.

As currently implemented, it also depends on internal edwards25519 changes that haven't been properly tested.

I also have limited time and also have bills to pay. I need to carefully review that code and the APIs, but things like libsodium.js and PQC are competing with it, and seems to be a more common need than H2C.

But for Opaque, have you looked at https://github.com/stef/libopaque ?

[wmcelderry]

Hi again,

Sorry for the delay in replying!

Thank you for the libopaque link: I had not seen that and it looks interesting. It looks like they've used libsodium and written their own H2C function to get it running, so I guess another option is to use their hash to curve.

I do not understand your comment about HPKE without dynamic allocations/streaming interface (sorry).

Are you referring to RFC9180 or something else? If RFC9180, I do not understand what the 'label to integer' function is, perhaps LabeledExtract? (though I do not see how that affects the H2C functionality as it's part of a KDF isn't it?)

And for clarity, why is dynamic allocation bad in your context? Is it for performance, resource constrained devices, making it hard/impossible to provide guarantees or some other reason?

As for your motivations: I totally understand your rationale for what you list - it seems very sensible to me, however I think we've had a couple of misunderstandings in this thread that I think would be worthy of clearing up. I'm not trying to convince you to change your mind, I just want you to be in possession of the facts, to avoid my poor explanation meaning something useful to you is being discarded.

Here's my fork for comparison with your stable branch for ristretto255_h2c:

And another for ed25519_h2c (including the ristretto255_h2c work)

What you can see in those commits:

1. I've not had to update ed25519 at all to get ristretto255 h2c working. It has been working since 2021, but hasn't had any test vectors to demonstrate that, until now (I haven't found any invocation of crypto_core_ristretto255_from_string in the code base, but could have missed it?)
2. I've kept the commits to a set of related changes per commit so you can probably cherry-pick the commits nicely to apply to master or stable, as you choose. The identified related changes I identified are:
   2.1. pull code from master
   2.2. remove any obsolete code that doesn't compile
   2.3. make updates to code from master.
   2.3.1. implementation changes
   2.3.2. changes to test code
   2.4. create any new tests
   2.5. update build input files
   2.6. update build output files
3. I've followed this pattern twice, once to get ristretto255_h2c working, and once to get ed25519_h2c working - the latter does requires more changes and affects the ristretto255 codebase, but definitely is not required for the ristretto_h2c to work.

Hope that all makes sense!

[wmcelderry]

I'm guessing the last post is a bit long and you're busy.

I believe the ristretto255 tests are useful so I'm going to create a pull request for them to the master branch.

I'm not meaning to be pushy, so if you don't want it just reject it!