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

[Christopher Wood <[e-mail]>]

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!

> 
> Section 4: "In this protocol, the server learns nothing of msg, whereas
> the client learns sig and nothing of skS.": this doesn't specify whether
> the server learns sig.  (It does not.)  This paragraph should also say
> that skS is input by the server and msg is input by the client.

That’s a good suggestion. We fixed this in the latest version.

> 
> In Section 4.1, step 1:
>    encoded_msg = EMSA-PSS-ENCODE(msg, (kLen * 8) - 1)
> doesn't look right to me.  kLen is the length of the modulus in bytes.
> What if the modulus is 2049 bits, say?  Then klen=257, and (kLen*8)-1
> is 2055, which is too large.

Great catch! We fixed this by using a function that computes the bit length for N.

> 
> Does step 5 need to be done in constant time?  Does any of this
> function (or the other ones)?  Section 8.1 talks a bit about this for
> the Sign algorithm (which protects the secret key from timing attacks),
> but the client's message (and blinding factor) also need to be protected
> from the server, no?

We added a note to the security considerations (Section 7.1) that covers this part of the threat model. Ultimately, we decided trying to make Blind (and the newly introduced Prepare) function(s) constant time did not seem fruitful for most threat models and applications, but we would be happy to hear if others disagree.

> 
> In step 6, it's a little funny to raise the error "invalid blind" as
> opposed to "Oh look we factored the server's public key!".  The text
> above the algorithm says "The probability of multiple such errors in
> sequence is negligible." but in fact the probability of even one such
> error is negligible.

Fair point. We added a note about how applications can deal with these errors in Section 6.1.

> 
> Section 5: "randommization" -> "randomization"
> 
> Section 8: the term "RSA-FDH" is used in the first sentence, but not
> defined until Section 8.6.
> 
> Section 8.1 says that implementations SHOULD verify that the signature
> is correct.  Finalize in Section 4.3 already does this explicitly.  Did
> you mean that BlindSign should also do this before returning blind_sig?
> Is there a reason not to explicitly write it in, as with Finalize?

We decided to add this step explicitly to BlindSign, and expanded Section 7.1 to note that this fault check step can be removed or skipped if not applicable to your threat model. 

> 
> Section 8.3: "to learn information about low-entropy with input
> messages": should "with" be removed?
> 
> Section 8.4 is interesting; it says the implementation shouldn't let the
> client pass the salt value because the client might embed some sensitive
> data in it.  But the client could just as easily (in many cases) embed
> that data in the message, no?  I'd be more worried about the other way
> around: the implementation embedding secret data about the client
> without the client's knowledge (algorithm substitution attacks,
> kleptography, etc.).

Good points. We generalized this section to cover this better.

Can you please let us know if the latest version addresses your comments?

Best,
Chris