Blind signing?

[dirvine]

Would you consider adding blind signing capabilities as mentioned in the paper (from the readme). A nice & concise overview here https://crypto.stackexchange.com/a/12832/10693

[burdges]

We used RSA blind signatures in https://taler.net/en/ because the verification runs much much faster. Arguably RSA blind signatures have a more fragile implementation since people might omit either of the two the FDHs.

Actually deploying blind BLS signatures comes with pitfalls, like nasty DoS attacks. Implementing blind singing is trivial once you have BLS of course, but not sure if a good interface exists that reduces the downsides. I'd do them in bls-like if I knew the answers to questions like: Should you batch verify with a traitor tracing algorithm?

There is now a good defense against the attacks on Schnorr blind signatures, so if you can tollerate three round trips then that's likely the fastest: https://github.com/w3f/schnorrkel/issues/46

[afck]

Thank you for pointing out those issues, @burdges! Yes, we're open to accepting a blind signing PR in principle, if those questions are resolved.

[kobigurk]

@burdges, could you provide a reference for possible attacks on blind BLS signatures?

[burdges]

There are no known attacks on the BLS signatures scheme security as a signature scheme, but..

We have no conservative curve choices for BLS, only fast curves designed for systems than can be upgraded relatively easily. All pairing based curves have vaguely RSA-like security due to the pairing itself, so they slowly should grow weaker as years go by, unlike regular curves. All this sounds fine for blind signatures since blind signature deployments have an upgrade path due to rolling over the key periodically (see Taler's refresh protocol).

The main problem with BLS signatures is the verification being super slow. Aggregation solves this by amortizing the cost.

The main attack on BLS signatures is simply spamming the verifier with invalid signatures. It's fine if your BLS signers are all staked validator nodes. If validators DoS other validators with invalid signatures then you could detect this from the authenticated channel between them and your governance process could vote to manually slash the validators running the DoS attack.

It's problematic if your nodes accept BLS signatures from an open network, but blind signatures always come from an open network since anonymity is the entire point. Aggregation does not help much because the signatures run over different messages. Also initial aggregation pass before verification only makes the DoS attack worse.

[dirvine]

Nice description @burdges but I wonder. Is the attack you mention not something that all signing schemes that accept messages from unknown nodes suffer from? I know BLS is much slower for single sigs (ignoring batching). Or is there a bit more I am missing? Sorry for more questions.

[afck]

I'd say that's no reason to exclude blind signatures from this crate, is it? It's rather about using them correctly. We should probably add some warning to the docs about the performance characteristics.