Wabisabi Deanonymization Vulnerability “Disclosed”

GingerWallet, the fork of WasabiWallet maintained by former zkSNACKs employees after the shut down of the Wasabi coinjoin coordinator, has received a vulnerability report from developer drkgry. This vulnerability would allow the total deanonymization of users inputs and outputs in a coinjoin round, giving a malicious coordinator the ability to completely undo any privacy gains from coinjoining by performing an active attack.

Wasabi 2.0 was a complete re-design of how Wasabi coordinated coinjoins, moving from the Zerolink framework utilizing fixed denomination mix amounts, to the Wabisabi protocol allowing dynamic multi-denomination amounts. This process involved switching from homogenous blinded tokens to register outputs to claim your coins back, to a dynamic credentials system called Keyed Verification Anonymous Credentials (KVACs). This would allow users to register blinded amounts that prevented theft of other users’ coins without revealing to the server plain-text amounts that could be correlated and prevent linking ownership of separate inputs.

When users begin participating in a round, they poll the coordinator server for information regarding the round. This returns a value in the RoundCreated parameters, called maxAmountCredentialValue. This is the highest value credential the server will issue. Each credential issuance is identifiable based on the value set here.

To save bandwidth, multiple proposed methods for clients to cross-verify this information were never implemented. This allows a malicious coordinator to give each user when they begin registering their inputs a unique maxAmountCredentialValue. In subsequent messages to the coordinator, including output registration, the coordinator could identify which user it was communicating with based on this value.

By “tagging” each user with a unique identifier in this way, a malicious coordinator can see which outputs are owned by which users, negating all privacy benefits they could have gained from coinjoining.

To my knowledge drkgry discovered this independently and disclosed it in good faith, but the members of the team who were present at zkSNACKs during the design phase of Wabisabi were absolutely aware of this issue.

“The second purpose of the round hash is to protect the clients from tagging attacks by the server, the credential issuer parameters must be identical for all credentials and other round metadata should be the same for all clients (e.g. to ensure that the server isn’t trying to influence clients to create some detectable bias in registrations).”

It was brought up in 2021 by Yuval Kogman, also known as nothingmuch, in 2021. Yuval was the developer to design what would become the Wabisabi protocol, and one of the designers in actually specifying the full protocol with ‪István András Seres‬.

One final note is the tagging vulnerability is not actually addressed without this suggestion from Yuval as well as full ownership proofs bound to actual UTXOs as proposed in his original pull request discussing tagging attacks. All of the data being sent to clients isn’t bound to a specific round ID, so a malicious coordinator is still capable of pulling a similar attack by giving users unique round IDs and simply copying the necessary data and re-assigning each unique round ID per-user before sending any messages. 

This is not the only outstanding vulnerability present in the current implementation of Wasabi 2.0 created by the rest of the team cutting corners during the implementation phase.