Re: [bitcoindev] Reiterating centralized coinjoin (Wasabi & Samourai) deanonymization attacks

[Yuval Kogman <nothingmuch@woobling.org>]

On Mon, 6 Jan 2025 at 14:08, Sjors Provoost <sjors@sprovoost.nl> wrote:

> Do we know based on observations or published server-side code whether
> this key was:

> 1) the same for all time; or
> 2) unique for each round; or
> 3) unique for each registration request
>
> In case of (1) and (2) it would have been possible to detect a targeted* attack,
> of course only if you were on the lookout.

Only (2) would be correct behavior. If (3) was performed, then that is
just the tagging attack. If (1) was done, then that would have allowed
clients to stockpile blind signatures in earlier rounds, and register
excess outputs during the output registration phase of later ones to
disrupt them (wasabi 1 had this bug FWIW).

if the archived code is considered reliable, then it seems (2) was the
implemented behavior:

https://github.com/Archive-Samourai-Wallet/whirlpool-server/blob/develop/src/main/java/com/samourai/whirlpool/server/beans/Mix.java#L67

> Perhaps if the app kept sufficient logs, it would still be possible to retroactively
> check this.

I'm not aware of any such observation efforts. They would require
modifying the client, at least with the archived version that I saw
the `blindingParams` member is not used that way (there are other
debug logs in the whirlpool client, but not with this data).

However, since the public key is only given in response to input
registration, i.e. after the server has learned of the intended UTXO,
and because in many cases an xpub linking that coin may have also been
revealed to the server, and the server controls the grouping of coins
into sets of 5, it seems to me that if it was controlled by a rational
attacker it would not use the overt key tagging attack when covert
ways of deanonymizing are available and just as effective.

> * = I’m thinking of an active attacker who wants to track specific UTXOs.
>      They could preemptively “persuade” the coordinator server to provide
>      a different RSA key or round ID if they ever try to join a round.

While this is certainly possible, maintaining plausible deniability is
easier if the server merely maliciously control the placement of
UTXOs, ensuring that targeted UTXOs end up only with xpub-revealed
and/or adversary controlled peers.

> Are these round IDs logged by clients?

In the case of wasabi, both my recollection and a cursory search
indicates that yes:

https://github.com/WalletWasabi/WalletWasabi/blob/42e7963d7fffc7f8f37fd9b6e8973235859ee7fb/WalletWasabi/WabiSabi/LoggerTools.cs#L36

I did not check in detail where this information is logged, and I
don't think a list of all published round IDs is logged.

I would not encourage users to share such logs, or their data, without
careful considerations. Even if logs were scrubbed, revealing a/the
set of rounds in which a user participated can significantly harm
privacy, especially since participation in rounds and coin selection
does not take into account history intersection attacks. See also
these issues re log scrubbing
https://github.com/WalletWasabi/WalletWasabi/issues/6770
https://github.com/WalletWasabi/WalletWasabi/issues/6670 (first was
closed without fixing, deemed duplicate of 2nd - i'd say it isn't -
which is still open...).

One of the developers still working on wasabi indicated that there
will finally be some efforts to mitigate this class of attack:

1. redundant queries from isolated tor circuits of the round status
information where round IDs are published, and consistency checks for
the data returned
2. use of deterministic shuffling in the transaction, ensuring that
signatures can only be aggregated in the absence of equivocation
(assuming the corresponding Lehmer code has enough bits of entropy)

Since round IDs are published ahead of time in the status requests,
and clients explicitly choose which round to join before revealing any
of their intended inputs, the first mitigation is straightforward and
would present a significant barrier.

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAAQdECCq5n7zkRJboVwjLMWkGUP7-G2U7tK4Ekf5M9NqLypLQA%40mail.gmail.com.