Re: [CFRG] I-D Action: draft-irtf-cfrg-rsa-blind-signatures-06.txt

[Christopher Wood <[e-mail]>]

Do you think there’s a more clear way to describe this property? If not, maybe we could give an example (maybe as described in this thread) to illustrate the idea.

On Thu, Dec 8, 2022, at 9:34 PM, Ian Goldberg wrote:
> On Thu, Dec 08, 2022 at 09:03:51PM -0500, Christopher Wood wrote:
>> 
>> 
>> > On Dec 8, 2022, at 8:57 PM, Christopher Wood <[e-mail]> wrote:
>> > 
>> > 
>> > 
>> >> On Dec 8, 2022, at 1:29 PM, Ian Goldberg <[e-mail]> wrote:
>> >> 
>> >> On Thu, Dec 08, 2022 at 12:37:55PM -0500, Christopher Wood wrote:
>> >>> Thanks, Ian! Please see inline below.
>> >>> 
>> >>>> On Nov 29, 2022, at 5:59 PM, Ian Goldberg <[e-mail]> wrote:
>> >>>> 
>> >>>> On Tue, Nov 29, 2022 at 01:47:40PM +0000, Franziskus Kiefer wrote:
>> >>>>> Chris asked me to review the draft.
>> >>>> 
>> >>>> Me as well.  My notes are below.
>> >>>> 
>> >>>> In Section 1, [I-D.irtf-cfrg-voprfs] is a broken reference.
>> >>>> Interestingly, Section 1 motivates this document with, "Specifically,
>> >>>> VOPRFs are not necessarily publicly verifiable", but
>> >>>> draft-irtf-cfrg-voprf-16 (which is presumably what the dangling link is
>> >>>> supposed to point to) _is_ publicly verifiable
>> >>>> (https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-voprf-16#section-2.2.2)
>> >>>> Is there another motivation for using RSA instead of
>> >>>> draft-irtf-cfrg-voprf-16?  Is it just the "in such a way that the
>> >>>> resulting (unblinded) signature can be verified with a standard RSA-PSS
>> >>>> library"?  As you point out here, VOPRFs are strongly related to
>> >>>> deterministic blind signatures.  Should VOPRFs be discussed in Section
>> >>>> 8.7?
>> >>> 
>> >>> We decided not to make a change here. The full text reads:
>> >>> 
>> >>>  Recently, interest in blind signatures has grown to address
>> >>>  operational shortcomings from applications that use Verifiable
>> >>>  Oblivious Pseudorandom Functions (VOPRFs) [VOPRF], such as Privacy
>> >>>  Pass [PRIVACY-PASS].  Specifically, VOPRFs are not necessarily
>> >>>  publicly verifiable, meaning that a verifier needs access to the
>> >>>  VOPRF private key to verify that the output of a VOPRF protocol is
>> >>>  valid for a given input.
>> >>> 
>> >>> 
>> >>> The important bit here is that the private key is needed to verify the VOPRF value, which is what publicly verifiable means in this context. We determined this was clear enough as-is, but if you have concrete suggestions for how to improve it further, please do share!
>> >> 
>> >> But that's exactly what I'm saying is _not_ true for
>> >> https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-voprf-16#section-2.2.2
>> >> since you only need the public key (A and B), not the private key (k) to
>> >> verify.
>> > 
>> > I’m still not sure I see the confusion, so please bear with me as we zero in on it. I wonder if it’s the non-interactive nature of this property that we’re missing? In an attempt to clarify, let me try to explain my thinking (and apologies in advance if this is all obvious).
>> > 
>> > In this draft, public verifiability means that anyone with the output of the protocol (the signature) can _non-interactively_ verify it using the input of the protocol (the message that was signed and the public key). For Blind RSA, this property trivially holds, since the output is a digital signature that anyone with the public key and message can verify. For the VOPRF case, the output (y) is the PRF result and the input (x) is the PRF input and public key (g^k). The only way to non-interactively verify this output, i.e., to check that y = H(x, H2C(x)^k)), is with access to the VOPRF private key.
>> 
>> Oh, I should that by “anyone with the output of the protocol” I mean, importantly, someone that did not run the protocol in the first place. You’re right in that the client which runs the protocol can verify the VOPRF output. But the important point here is that the client verifying the output is not the client that ran the protocol to produce the output, which is why we describe it as being “publicly verifiable."
>> 
>> By the way, please do let us know if there’s a better or more accurate term to describe this property.
>
> Ah, I see what you're getting at now. The VOPRF protocol in
> https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-voprf-16#section-3
> would prove to anyone that evaluatedElement is the correct answer for
> the input blindedElement, but not that the final output is the correct
> answer for the original input; only the client that ran the protocol
> knows that connection between input and blindedElement.
>
> Sounds good to me.