taler
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Taler] [CFRG] RSA blind signatures


From: Christopher Wood
Subject: Re: [Taler] [CFRG] RSA blind signatures
Date: Wed, 24 Feb 2021 15:25:18 -0800
User-agent: Cyrus-JMAP/3.5.0-alpha0-141-gf094924a34-fm-20210210.001-gf094924a

Hi Jeff,

Thanks for the feedback! Please see inline below.

On Wed, Feb 24, 2021, at 12:03 AM, Jeff Burdges wrote:
> 
> It’s critically important the blinding factor r be a uniformly random 
> integer mod n, which I think deserves more emphasis than you give.  
> There is an easy deanonymization attack if r were say generated a 
> random integer mod 2^{floor(log2 n)}.  You hould emphasize that 
> random_integer should be instantiated with a CSPRNG and rejection 
> sampling, maybe even specify the rejection sampling algorithm starting 
> with shake or chacha.  

Indeed -- we can definitely sharpen the language here to emphasize the 
importance of this point:

   https://github.com/chris-wood/draft-wood-cfrg-blind-signatures/issues/55

> If I recall, RSA-PSS depends upon signer randomness for its security 
> arguments.  As such, one should ideally not base an RSA blind signature 
> off PSS but instead specify a full domain hash (FDH).  

Is this a useful distinction? Blind RSA in general requires randomness for it 
to be useful (as you carefully point out above). 

In any case, the rationale for PSS was two-fold:

1) It's widely supported in libraries. (To my knowledge FDH is not widely 
supported... yet.)
2) One can basically replicate FDH with a zero-length salt, even though some 
APIs make it difficult to do so.

> At this point, one could specify the blinding factor be produced by 
> applying the FDH to system randomness.  This is what I did for Taler’s 
> blind RSA signatures: https://taler.net/en/
> 
> Initially I wanted to point you to the RSA-FDH-VRF in 
> https://datatracker.ietf.org/doc/draft-irtf-cfrg-vrf/ except..  
> Actually the RSA-FDH-VRF draft does not properly specify the FDH 
> either, but only points to https://tools.ietf.org/html/rfc8017 which 
> does not specify the FDH.
> 
> An FDH is a pretty easy notion but people get this wrong.  Also, there 
> might be interoperability advantages in specifying it more fully. 

Quite true! Perhaps a more clean specification of FDH would address (1) above?

Best,
Chris

> p.s.  I think one should not deploy RSA-FDH-VRF but instead work 
> through all the tricks to make Rabin-Williams deterministic.  It’s not 
> too hard but not as easy as RSA-FDH-VRF.  I’ve no looked at wether 
> Rabin-Williams could be adopted to blind signatures, but I think some 
> issues arose beyond what one alters for a Rabin-Williams VRF. 
> 
> 
> 
> 
> 
> > On 23 Feb 2021, at 18:37, Christopher Wood <caw@heapingbits.net> wrote:
> > 
> > There are a growing number of use cases where we need something like VOPRFs 
> > but with public verifiability [1,2]. Given the results in 2020/945 [3], it 
> > seems prudent to try and fill the gap with something we know is reasonably 
> > safe. To that end, here's a draft describing RSA-based blind signatures:
> > 
> >   
> > https://chris-wood.github.io/draft-wood-cfrg-blind-signatures/draft-wood-cfrg-rsa-blind-signatures.html
> > 
> > (I missed the deadline yesterday, so apologies for not having an actual 
> > datatracker draft to point at.)
> > 
> > Obviously, something better than RSA (in terms of bandwidth and overall 
> > messages) would be great. But it's not clear what that is right now.
> > 
> > Time permitting, I'd like to request some time on the agenda to present 
> > this to the group at IETF 110.
> > 
> > Thanks,
> > Chris
> > 
> > [1] https://github.com/ietf-wg-privacypass/base-drafts/issues/40
> > [2] https://github.com/privacycg/private-click-measurement/issues/27
> > [3] https://eprint.iacr.org/2020/945.pdf
> > 
> > _______________________________________________
> > CFRG mailing list
> > CFRG@irtf.org
> > https://www.irtf.org/mailman/listinfo/cfrg
> 
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]