Chris P.'s review: Editorial

[cjpatton]

Some editorial feedback on the current version.

1

• The verifiability property of VOPRFs sounds similar to VRFs. Since there is a draft for this, it's probably a good idea to reference as related work.

• Quote:

  A Verifiable OPRF (VOPRF) is an OPRF wherein the server can prove to the client that F(k, x) was computed using the key k.

  For this to make sense the client needs to know something about k. What about: "A Verifiable OPRF (VOPRF) is an OPRF wherein the server also proves to the client that F(k, x) was produced by the key k corresponding to the public key the client knows.

• The term "verifiable POPRF" is used in this section. The word "verifiable" is redundant since, if I understand correctly, POPRF is an extension of a VOPRF. This inconsistency is a bit confusing, so I would just write "POPRF".

• Quote:

  This document specifies OPRF, VOPRF, and POPRF protocols built upon prime-order groups based on the 2HashDH [JKKX16] and 3HashSDHI [TCRSTW21] designs, respectively.

  It's not clear what type of primitive 2HashDH and 3HashSDHI are, since three things (OPRF, VOPRF, and POPRF) can't be in 1:1 correspondence with two things (2DHashDH and 3HashSDHI).

2

• Quote:

  A cryptographic hash function that is indifferentiable from a Random Oracle.

  I don't think that "indifferentiable from a RO" is something you can meaningfully assert about a hash function. To me this statement is only meaninfgul in the context of a security analysis. In particular you'd need to add something like "when modeling the underlying compression function as a random oracle".

  It would be sufficient to just say here that Hash is a cryptograpphic hash function. If you want to talk about its security considerations here, you could say something this: "A cryptographic hash function, modeled as a random oracle in {{JKKX16}} and {{TCRSTW21}}."

  Regarding indifferentiability: I'm not sure if this comes up in these papers (I haven't checked): Indifferentiability from an RO (when the underlying compression function is modeled as an RO) does not hold for all hash functions (e.g., SHA-2). But whether this leads to an attack depends ultimately on the application. It might be that length-extension attacks against SHA-2 aren't exploitable in an attack against the constructions in this draft.

  Finally, I wouldn't capitalize "Random Oracle".

2.1

• Part of this section is dedicated to enumerating the laws of any algebraic group. Is this necessary? I ask because I haven't seen a CFRG document do this before.

• Quote:

  The fundamental group operation is addition + with identity element I.

  In the remainder, 0 is used to denote the identity.

3

• The three figures don't show which steps depend on pkS and skS. Presumasbly Evaluate() takes in skS and, for the verifiable modes, Finalize() takes in pkS? Why not pass them to the functions that use them?

3.1

• nit: RFC editor note and context string are out-of-sync. The former says draft-08 and the latter says draft-09.

• In the definition of DeriveKeyPair(), did you mean to write

  pkS = GG.ScalarBaseMult(skS)

  instead of

  pkS = ScalarBaseMult(skS)

3.3.3

• ScalarBaseMult(m)/GG.ScalarBAseMult(m)?

4

• Quote:

  Hash: A cryptographic hash function that is indifferentiable from a Random Oracle, whose output length is Nh bytes long.

  Same comment as in Section 2.

• Editorial: The names of the ciphersuites have the format OPRF(GG, Hash). This convention is slightly misleading, since a ciphersuite is also applicable to the VOPRF and POPRF.

7

• nit: s/Privacy Pass team/Privacy Pass working group/