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

[Christopher Wood <[e-mail]>]

Thanks for the review, Franziskus! Please see inline below.

> On Nov 29, 2022, at 8:47 AM, Franziskus Kiefer <[e-mail]> wrote:
> 
> Chris asked me to review the draft.
> Apologies if some items were discussed already, I didn't follow the discussion closely.
> 
> The draft looks good to me. I only found some minor editorial issues.
> I also addressed a few issues here https://github.com/cfrg/draft-irtf-cfrg-blind-signatures/pull/154.
> 
> Section 3.
> random_integer_uniform: The use of boundaries M <= R < N confused me a little. Not thoroughly reading this section and then generating r = random_integer_uniform(1, n) I can see that someone might implement this as  M <= R <= N. But maybe that's just me.

We addressed this in the latest version by being more explicit with words.

> 
> Section 4.1
> Errors: The RSAVP1 can throw an error that is not mentioned here. It can't actually be thrown because of the way the input (r) is defined. But mentioning that the error can't be raised might be useful.

Good catch — we fixed this.

> 
> Section 4.2
> I wonder if the error handling here makes sense. RSASP1 checks the following: "If the message representative m is not between 0 and n - 1, output "message representative out of range" and stop."
> This makes steps 1 and 3 unnecessary unless I'm missing something.
> Consistently raising errors from the functions called from RFC 8017 in all these sections would be nice so implementers know how to handle them.

We also fixed this. We removed redundant errors introduced by this spec and defer them to RFC8017 functions where appropriate. 

> 
> Section 5 comes a little out of the blue without explanation why this is here and who should use it. Would it make sense to either have this as an optional step in section 4 or move it to section 6 where it is used?

As noted in my responses to Martin and Scott, we fixed this with a reformulation of the protocol. In particular, we now have a “message preparation” step that adds randomness for those variants that require it, else does nothing for those that do not.

> 
> Section 8 (last paragraph)
> The draft states that PSS with a zero salt is equivalent to FDH such that the results from BNPS03 apply. But it doesn't say what security to expect from the salted version. Is there anything that could be said here?

We added a note that Lys22 covers the analysis for other variants. 

> 
> Appendix A
> Most values are encoded as "hexadecimal string" but some are prefixed with 0x and others are not. To make it easier for applications to use the test vectors a consistent encoding would be nice.

Nice catch! This has been fixed so that all test vector values are consistent.

Can you please let us know if the new version addresses all of your comments?

Best,
Chris

> 
> Best,
> Franziskus
> 
> On Fri, 25 Nov 2022 at 18:16, Scott Hendrickson <[e-mail]> wrote:
> As promised in the adoption call, I've reviewed the document. It looks good to me, with a few notes provided below.
> 
> I've sent one editorial nit in https://github.com/cfrg/draft-irtf-cfrg-blind-signatures/pull/152
> 
> Section 1
>  - Consider citing the voting [1] and authentication (maybe the g1vpn whitepaper [2] or private relay explainer [3] examples). It may feel like over-embellishment from our perspective, but someone reading this may not have the same context building systems like this as the authors do. I appreciate the review of other blind signing alternatives later on for the same reason.
> 
> Section 3
>  - In the description of random_integer_uniform(M, N), cryptographic security isn't mentioned, but is mentioned for random(n). Should this mention that the random source needs to be cryptographically secure?
> 
> Section 4.1
>  - All RSABSSA variants from Section 6 appear to use SHA-384 as the hash function, and MGF1. Should we indicate hash and mgf as parameters if they are held constant? I see that they are options in RFC8017, but if they are held constant in the RSABSSA uses, I'd avoid listing them as options until they need to vary.
> 
> Section 4.2
>  -  [editorial pr] blinded_msg, encoded and blinded message to be signed, an byte string -> *a* byte string
>  
> Section 4.3
>  - Same notes on hash and MGF1 from 4.1 feedback
> 
> Section 5
>  - Should this section be placed before section 4, so this reads in order? Randomize, blind, etc
>  - Consider defining || 
> 
> Best,
> Scott
> 
> On Mon, Nov 21, 2022 at 6:06 PM Christopher Wood <[e-mail]> wrote:
> This version of the document incorporates feedback received thus far in the RGLC. The primary change is the introduction of named variants to replace the old API guidance text. It’s our hope that these address the concerns raised by others and would greatly appreciate confirmation one way or another.
> 
> Best,
> Chris, for the editors
> 
> > On Nov 21, 2022, at 5:14 PM, [e-mail] wrote:
> > 
> > 
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> > This draft is a work item of the Crypto Forum RG of the IRTF.
> > 
> >        Title           : RSA Blind Signatures
> >        Authors         : Frank Denis
> >                          Frederic Jacobs
> >                          Christopher A. Wood
> >  Filename        : draft-irtf-cfrg-rsa-blind-signatures-06.txt
> >  Pages           : 31
> >  Date            : 2022-11-21
> > 
> > Abstract:
> >   This document specifies an RSA-based blind signature protocol.  RSA
> >   blind signatures were first introduced by Chaum for untraceable
> >   payments [Chaum83].  It extends RSA-PSS encoding specified in
> >   [RFC8017] to enable blind signature support.
> > 
> > Discussion Venues
> > 
> >   This note is to be removed before publishing as an RFC.
> > 
> >   Source for this draft and an issue tracker can be found at
> >   https://github.com/chris-wood/draft-wood-cfrg-blind-signatures.
> > 
> > 
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-irtf-cfrg-rsa-blind-signatures/
> > 
> > There is also an HTML version available at:
> > https://www.ietf.org/archive/id/draft-irtf-cfrg-rsa-blind-signatures-06.html
> > 
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-irtf-cfrg-rsa-blind-signatures-06
> > 
> > 
> > Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
> > 
> > 
> > _______________________________________________
> > CFRG mailing list
> > [e-mail]
> > https://www.irtf.org/mailman/listinfo/cfrg
> 
> _______________________________________________
> CFRG mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg
> _______________________________________________
> CFRG mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg
> _______________________________________________
> CFRG mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg