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

[Christopher Wood <[e-mail]>]

> 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.

If it’s not the interactive nature of verifiability, can you clarify the problem here?

Thanks again,
Chris

> 
>> Can you please let us know if the latest version addresses your comments?
> 
> I'll add it to my queue.  :-)
> -- 
> Ian Goldberg
> Canada Research Chair in Privacy Enhancing Technologies
> Professor, Cheriton School of Computer Science
> University of Waterloo