<p>This kind of attack on blind signing is indeed possible and usually called a tagging attack. In order to address it clients should verify that a consistent signing key is used.</p>
<p>The simplest way to address this is to require that the input ownership proofs commit to this key, and to broadcast these proofs to all clients who verify them before submitting an unblinded signature. None of the implementations do this.</p>
<p>Using Tor (or something similar) it's possible to mitigate: obtain the key and the blind signature using separate requests with connection isolation, and ensure that they are unlinkable. In this case a corrupt server would have to correctly partition the requests which is difficult but it's hard to reason about the difficulty of doing a targetted attack.</p>
<p>In the Schnorr blind signature based version of Wasabi 1.x the round keys (one per denomination) <a href="https://github.com/zkSNACKs/WalletWasabi/blob/f9f1a70c1bdfbfcae95c5b29e01cf96167310682/WalletWasabi/CoinJoin/Client/Clients/CoinJoinClient.cs#L1052" rel="nofollow noreferrer">are fetched</a> and are not compared to those obtained in any previous responses before requesting a blind signature. Note that for this mitigation the fact that the blind signature requests are inherently linkable to a specific previous status request due to the way the R points are handled is not a problem, the key point is that the client only reveals the input after obtaining the server key.</p>
<p>In Whirlpool the public key is part of the <a href="https://code.samourai.io/whirlpool/whirlpool-client/-/blob/d7ae218124b0443a5275fadc4b470f61b9e58e02/src/main/java/com/samourai/whirlpool/client/mix/MixProcess.java#L152" rel="nofollow noreferrer">response to input registration</a>, so there is no opportunity for such mitigation.</p>

CC BY-SA 4.0
2022-10-23T11:07:45.913Z
Thanks for the detailed answer! 

Another way to mitigate it might be to have the co-ordinator chosen at random from amongst the participants, though I guess this would potentially reduce availability... 

If you did this, you could also make the public key (for the blind signing) sharing part of the coordinator selection process.
River Satya
CC BY-SA 4.0
2022-10-16T00:11:25.313Z
2022-10-16T00:25:57.463Z
2022-10-16T00:25:57.463Z
nothingmuch
<p>I'm not an expert on Chaumian blind signatures, so forgive me if the answer to this is obvious, but I'm wondering how the coordinator can prove to the participants that it's not doing what I asked in the question.</p>
<p>If it uses a different key for each blind signing, then couldn't it just try every key against the small set of returned unblinded outputs to determine which one it used, and thus match it up against the corresponding input?</p>
<p>This seems too obvious a flaw to be the case, so I'm wondering how this is avoided.</p>
<p>Thanks!</p>

<coinjoin>
In a Chaumian Coinjoin, what prevents the coordinator from using a different private key to blind sign each output and thus map inputs to outputs?
River Satya
# In a Chaumian Coinjoin, what prevents the coordinator from using a different private key to blind sign each output and thus map inputs to outputs?

(Asked by: username_0 on 2022-10-15)

I'm not an expert on Chaumian blind signatures, so forgive me if the answer to this is obvious, but I'm wondering how the coordinator can prove to the participants that it's not doing what I asked in the question.

If it uses a different key for each blind signing, then couldn't it just try every key against the small set of returned unblinded outputs to determine which one it used, and thus match it up against the corresponding input?

This seems too obvious a flaw to be the case, so I'm wondering how this is avoided.

Thanks!

**Tags:** coinjoin


---

## 1 answers

### Answer by username_1 on 2022-10-16. Score: 2 | Accepted answer

This kind of attack on blind signing is indeed possible and usually called a tagging attack. In order to address it clients should verify that a consistent signing key is used.

The simplest way to address this is to require that the input ownership proofs commit to this key, and to broadcast these proofs to all clients who verify them before submitting an unblinded signature. None of the implementations do this.

Using Tor (or something similar) it's possible to mitigate: obtain the key and the blind signature using separate requests with connection isolation, and ensure that they are unlinkable. In this case a corrupt server would have to correctly partition the requests which is difficult but it's hard to reason about the difficulty of doing a targetted attack.

In the Schnorr blind signature based version of Wasabi 1.x the round keys (one per denomination) [are fetched](https://github.com/zkSNACKs/WalletWasabi/blob/f9f1a70c1bdfbfcae95c5b29e01cf96167310682/WalletWasabi/CoinJoin/Client/Clients/CoinJoinClient.cs#L1052) and are not compared to those obtained in any previous responses before requesting a blind signature. Note that for this mitigation the fact that the blind signature requests are inherently linkable to a specific previous status request due to the way the R points are handled is not a problem, the key point is that the client only reveals the input after obtaining the server key.

In Whirlpool the public key is part of the [response to input registration](https://code.samourai.io/whirlpool/whirlpool-client/-/blob/d7ae218124b0443a5275fadc4b470f61b9e58e02/src/main/java/com/samourai/whirlpool/client/mix/MixProcess.java#L152), so there is no opportunity for such mitigation.

> **Comments:**
> **username_0**: Thanks for the detailed answer!   Another way to mitigate it might be to have the co-ordinator chosen at random from amongst the participants, though I guess this would potentially reduce availability...   If you did this, you could also make the public key (for the blind signing) sharing part of the coordinator selection process.  

---

