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

[Ian Goldberg <[e-mail]>]

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?

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.

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.

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?

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.

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?

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.).
-- 
Ian Goldberg
Canada Research Chair in Privacy Enhancing Technologies
Professor, Cheriton School of Computer Science
University of Waterloo