Re: [Taler] [CFRG] IACR ePrint "RSA Blind Signatures with Public Metadata"

[Kevin Yeo]

Hi Jeff,

Thanks for your thoughts on our work!

We note that enabling public metadata is a trade-off between anonymity and functionality. In particular, we only prove anonymity amongst groups of signatures that utilize the same public metadata (this is inevitable since the metadata is **public**). In our academic paper, this is realized in the unlinkability experiment in Figure 2 (page 7) considering signatures for one choice of public metadata D.

I think there are two aspects here. One is that an explicit goal of our construction was to enable flexibility for public metadata coming from arbitrarily large universes that do not need to be decided at the start (for example, the universe of all strings). However, the number of *valid* public metadata enabled by the application using the primitive should be limited to ensure that there is sufficient number of signatures per public metadata (for example, this could simply be countries). Our construction enables the first whereas the second has to be enforced at the application-level. We also discuss this in more detail in Section 7.3 of our draft specifications. There are discussions on limiting metadata occuring in the context of privacypass, for example.

We also want to point out that our experiments are all executed using a single thread (as explained in the experimental setup).

Best,

Kevin

On Fri, Aug 11, 2023 at 4:43 AM Jeff Burdges <burdges@gnunet.org> wrote:

There is an anonymity leakage when doing RSA blind signed payments with
different public keys for different denominations, what you call one key
for each public metadata.  I think GNU Taler views this positively, in
that it prevents moving larger amounts non-anonymity, but many parties
view this negatively, like zcash, even if they cannot really move large
amounts anonymously either in practice.

Anyways, I'm dubious you've any anonymity left if your "universe of
public metadata is very large" (page 2), certainly if your VPN design
(GoogleOne?) requires spending multiple tokens in a linkable way.

It'd maybe be different for Tor where each new circuit should try being
really independent from the previous ones, and accesses only one site,
although even then traffic fingerprinting plus the a denomination or
metadata likely deanonymizes. 

You pay a large CPU cost for doing metadata in the exponent like this,
vs say e=3, so you should closely evaluate using one key per metadata,
even if Google has no real interest in VPN users' anonymity.

In fact, you could enforce correct metadata using a cut & choose
protocol, vaguely like how GNU Taler enforces taxability, which then
permits using OPRFs like privacy pass.  If your metadata is not too
sensitive, then this is going to be much less CPU and bandwidth than
anything else.  This would not be strong enough if your metadata is
currency denominations in a payment scheme.  Also OPRFs make key
management much worse.

Jeff

p.s.  I'm afraid zero-knowledge proof people always pervert their
benchmarks with multi-threading (ugh!), so maybe I'm wrong about this
point, but..

Your verifier CPU time sounds only twice as fast as verifying similar
paring based schemes, but your signer CPU time sounds much higher. 
There maybe a second verifier in a typical blind signed token scheme,
but not usually for a VPN one, and never more than two, ignoring
blockchains. 

I'd therefore suspect pairing based schemes have less total CPU time,
although maybe your users pay this signer CPU time, maybe your verifiers
cannot have much CPU time available, etc.  And maybe I'm just confused
by people doing multi-threaded benchmarks.



On Aug 11 2023, at 12:37 am, Ghous Amjad
<gamjad=40google.com@dmarc.ietf.org> wrote:

> Dear CFRG participants,
> 
> Our paper titled "RSA Blind Signatures with Public Metadata" can now
> be found on ePrint (https://eprint.iacr.org/2023/1199)) which details
> our cryptographic assumptions and security proofs supporting
> the associated draft: https://datatracker.ietf.org/doc/draft-amjad-cfrg-partially-blind-rsa/01/.
> 
> Please feel free to reach out to me or Kevin Yeo (CCed) if you have
> any questions or concerns regarding the paper.
> 
> Best,
> Ghous Amjad

_______________________________________________
CFRG mailing list
CFRG@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg