Round Public Key is Shared too late

[nopara73]

Phase 2. Start Round

In this phase, the server replies back to the player who just joined and shares:

1. The round public key that the server will use for the blind signatures.

As a server if I want to deanonymize my users I can reply with different public keys to every player, with that I can check which privkey I signed the blind message.

This attack is not possible if it is impossible to tell from the blind message that to which pubkey this message was blinded to. But if I can, this attack is possible. Anyone with more crypto knowledge can settle this?

[markblundeberg]

Yes, it's definitely possible for the server to tell different things to players and use that to discriminate which covert pieces belong to which player:

• round pubkey
• covert connection point (port)
• timings
• transaction components (changing ordering, maybe add an extra component of its own)
• some other things I'm not remembering at the moment

We basically treated all of those as one problem, and what we do is hash all the information into a commitment hash that gets put as OP_RETURN as the first output. That way if the server does say different things, while it may learn about which player did which thing, it will at least cause the fusion to fail because the various players will produce signatures on different transactions.

It's not ideal, but we also figure that (in general) we can't do any better than that. :/

[markblundeberg]

But for sure yeah, if you have 20 pubkeys that have been handed out then you can definitely figure out, worst case using 20 signature verifications, which signature is for which pubkey.

The round pubkey changing on every round is quite important though, since the blind signatures are like tokens, and on each round the server needs to issue fresh tokens and not have to worry about having old tokens generated from prior rounds being used in later rounds.

[nopara73]

We basically treated all of those as one problem, and what we do is hash all the information into a commitment hash that gets put as OP_RETURN as the first output.

That's clever. Closing this issue.

Surely not reusing the pubkey is essential. In Wasabi we figured to keep polling the pubkey and other round params with monitoring Tor identities, so the server cannot keep lying consistently.

Anyhow, lately I've been thinking that some kind of deterministic derivation scheme could be utilized in some way to make it easier, as this idea suggest in the Dining Cryptographer Networks paper:

We claim that if we initially exchange key generators rather than continually exchanging the keys itself, the network only requires a linear amount of bandwidth in n.

[markblundeberg]

Yeah deterministic derivation does have its pitfalls though. The blind signing process allows clients to not just produce a signature not just from the server's private key, but also from any client-chosen offset of the server key! So something like this can happen:

• On round 1 the server chooses private key x, public key X = xG. On round 2 the server will choose x + d where everyone knows d (like in a BIP32 unhardened derivation), i.e., everyone knows the pubkey on round 2 will be X + dG.
• On round 1, Eve connects as two players.
• One player generates honest behaviour, but the other generates tokens for the next round.
• The bad player gets blamed, then round 2 starts.
• Now the good player submits honest tokens plus the sneaky tokens generated last round.

[markblundeberg]

There is also something else even more annoying called 'Wagner's attack' which means if you are serving hundreds of blind signing requests in parallel (just as in fusion), then someone can carefully craft N requests out of which they get N+1 valid signatures! The amount of work they have to do is not small (billions of iterations) but it is computationally feasible -- much much easier than cracking a key. Fortunately, the worst they can do to cashfusion is cause a round to fail because too many components were submitted, and there is not any economic gain from this nontrivial work.

[nopara73]

Such attack is traditionally mitigated by shortening the timeframe, and here round is fast enough to probably not have to worry about it anyway. Although it warrants some calculations to make sure.

Interestingly this calculation potentially gives a maximum limit to this question (if bandwidth didn't give already) -

Next, we set a requirement that each player must covertly announce exactly 23 components. Why 23? It could be anything,