On Mon, 6 Jan 2025 at 14:08, Sjors Provoost <[email protected]> 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAAQdECCq5n7zkRJboVwjLMWkGUP7-G2U7tK4Ekf5M9NqLypLQA%40mail.gmail.com.
