Together with #354 , this PR addresses all the comments by JH posted here.
The best way to review this PR is going commit by commit.
Comments Addressed
"Verifiable POPRF": the verifiability property is not optional in the
draft, but the fact that it is sometimes called "verifiable POPRF" hints
that it is. Why not avoid any confusion by calling it VPOPRF throughout
the document?
Section 1.3 introduces PrivateInput and PublicInput as the exact same
data types. What distinguishes them? The terms Private and Public hint
at something, but it seems never spelled out in the document.
In general the distinction between "Input" and "Parameters" in the
function descriptions confused me. What are the semantics here? First I
thought Parameters are implementation-wide and fixed objects, like the
Group, but then the OPRF key skS appears as a Parameter of
BlindEvaluate. Since the document also hints that keys can be updated
during the run of the protocol ("key rotation"), skS does not seem to be
a long-term parameter to me. Sometimes both the terms Input and
Parameter are mixed, for example when "PublicInput contextString"
appears under Parameters. Another example is in the flow diagram of
POPRF, where both Inputs (info) and Parameters (pkS,skS) appear in
parantheses after a party's name.
Overall it would be good to clarify why the function descriptions
distinguish between "Inputs" and "Parameters", as otherwise implementors
might interpret their own meaning to these terms.
Explain the list notation []
Section 3, protocol overviews: skS and pkS appear as input to the
parties but are not used in the protocols. E.g., it should be
BlindEvaluate(skS,blindedElement) instead of BlindEvaluate(blindedElement).
"client and server augment the pkS and skS, respectively, using the
info value": this could be modified to explain the (otherwise
unexplained) "tweakedKey" term that appears in the protocol overview.
Maybe "client and server tweak their pkS and skS, respectively, using
the info value"?
If I would implement this, I would wonder about Input "opaque
seed[Ns]". Ns is an integer, and this seed appears to be a list of Ns
opaque values. In the text it says "randomly generated seed". The seeds
suggested in the test vector section do not appear very random to me ;)
Not sure if this is underspecified or just common knowledge.
"Recall that servers may batch multiple client inputs to
BlindEvaluate." - Maybe one more sentence how this is done? Just
repeated execution of BlindEvaluate and concatenating the
evaluatedElements in the message to the client?
"certain public inputs that map to invalid public keys for server
evaluation." I could not parse "public key for server evaluation" here.
I could not make any sense of 5.2, but again, not an implementor...
Partial obliviousness: I don't understand this definition. Everything
but the last sentence are properties of any OPRF, as described already
in the other properties. The sentence "Both client and server learn the
public input (info)" does not seem to have any meaning, since info is
input to both parties and hence they of course learn it. The partial
obliviousness property rather seems to enforce usage of info in an
evaluation.
I was also surprised that partial obliviousness is equivalent to
unlinkability. Are OPRFs linkable, in the sense of linkability described
in the draft?
In reference [SJKS17] typos in Jareckiy, Krawczykz
No change
Still protocol overviews: I find the term "evaluatedElement" computed
by the server a bit misleading, as it sounds like the server is learning
the evaluation. On the other hand I don't have a better idea.
BlindedEvaluatedElement would indicate more precisely what happens, but
is probably too long.
We remain using evaluatedElement for the output of the server computation.
Together with #354 , this PR addresses all the comments by JH posted here.
The best way to review this PR is going commit by commit.
Comments Addressed
No change
We remain using
evaluatedElementfor the output of the server computation.