Ashigaru Response

response.md

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512

Thank you for taking the time to detail us your findings. We are happy for you to share our response below on your Github and/or blog. We hope that this scrutiny, and our response to it, encourages users to gain more confidence with our new implementation of Whirlpool.

So far, we have had two users email us to highlight concerns that have been raised on social media such as BitcoinTalk and X. We have responded to these queries but are not aware if those users have publicized our responses. Those that have leveled criticism have not contacted us directly.

Overall, we have been pleased to see the reactions to our release. It is unfortunate that because we have forked and built upon a project that some of these developers have had animosity towards in the past, that they expect malicious intent from us. We have already demonstrated that we will make changes to our codebase based on user concern as can be seen by our efforts on reproducibility.

General criticism

Initial conclusions drawn by 1440000bytes on key tagging were based on looking at the wrong repository. This was not a "helpful review" of our codebase. 1440000bytes subsequently raised concerns about DoS issues. We acknowledge that DoS chances have increased on our implementation of Whirlpool compared to Samourai but we reject the assertion that Yuval Kogman made that it is a regression to Wasabi 1's trivial DoS vulnerability as the structure of the coinjoins are different. We believe we are able to mitigate DoS issues by the server storing signed messages from the client although this is a secondary concern to resolving linkability.

1440000bytes links to posts made by Yuval Kogman further down the thread which criticises our verification of RSA signatures. We believe Kogman's main concern is the key tagging and the way this could be used by the coordinator to undermine the privacy benefits of a coinjoin cycle. We are internally testing a remediation of this attack vector now where the client provides a message consisting of a base64 of a pool ID and a block hash during a recent time range. The server will validate and sign this and the client subsequently validate.

Whilst not mentioned in your article, we are also aware of criticism around our coordinator being able to attack other theoretical Whirlpool coordinators as well as that the client can apparently “steal your money’. Firstly, we are not interested in encouraging additional coordinators in the way Wasabi/Wabisabi does as it splits liquidity and any new coordinator could implement pool registration in their own way or use different pool denominations. Secondly, the client (e.g. Ashigaru Terminal user) has full control over their funds and the code can be verified that it presents the user an accurate summary of the Transaction Zero, including anti-Sybil and mining fees, prior to the user choosing to manually broadcast the transaction. We have no intention to deprecate the SCODE functionality. Whilst we are not making use of it now and don’t intend to use it for marketing, it offers opportunities for decentralization of coordination.

Blog post recommendations

Our primary recommendation is for the Ashigaru development team to implement per-round RSA key rotation while maintaining the protection against per-client differentiation. This would involve generating fresh RSA keypairs for each mixing round while ensuring all participants in the same round receive the same key.

We have not seen a way to achieve this and believe a single RSA key is still the best approach, albeit with enhancements we will add in our next release.

Additionally, we recommend implementing shorter key lifetimes as an interim measure, such as daily or weekly key rotation

This is something we could look at implementing in the “Ashigaru Hanzaki” manner, although we would need to consider any RSA key rotation carefully to avoid reintroducing the key tagging attack.

The development team should also consider implementing the full ZeroLink specification with proper anonymity set isolation between rounds and forward security properties that protect past mixing sessions even if current keys are compromised.

We are aware of this and this but these are outdated and the implementations have since deviated from the theory. Can you reference where in the ZeroLink specification this is stated?

Email recommendations

The only good solution for a truly trustless zerolink coordinator relies on a system allowing clients to have access to all messages received by the coordinator. It's the only solution allowing clients to fully check that the coordinator isn't cheating during its operations like, for example, during the selection of the freeriders. As long as some information available to the coordinator are hidden to clients, there will be opportunities for cheating.

We would caution against using definitive statements such as “only” in this context. There would be privacy trade-offs to such a system should client-server communication be, essentially, public. The current architecture allows users to only disclose to the coordinator when they are online and they can rely on their own remixes to judge whether the coordinator is acting honestly. Nevertheless, we intend to provide more data to inform users about available Whirlpool liquidity and rounds of mixes that have occurred.

It was the direction taken by Samourai Wallet with the project to decentralize Whirlpool and the exchange of messages over Soroban.

We are not sure how using Soroban would guarantee that all messages submitted by a client to the server could be seen by other clients and therefore audited. Further detail on this would be welcome should the expert you mention be willing to share.

Decentralization of Whirlpool is something we wish to further improve upon but we are not sure how Soroban assists in this yet. We are not aware of how successful the discovery of replacement coordinator servers were in the weeks following this announcement and there are still central databases and anti-Sybil fee wallets that are not easily shared and remain a central component to the Whirlpool architecture.

I hope that projects (like Ashigaru) that try to resuscitate whirlpool will continue on this path.

The Ashigaru Open Source Project is not trying to “resuscitate [Samourai’s] whirlpool”. Whilst we have forked Samourai’s codebase, we have made a number of changes, and open sourced our own version/implementation, hence the name “Ashigaru Whirlpool”.

To “continue on this path” of any sort of Samourai’s vision, there are many unknowns which were not publicly shared and of which the Ashigaru Open Source Project is not privy to. For example: how many further steps of decentralization were there to be, and the scope of each step.

It is our goal to continue to iterate on an already thoughtful and complex codebase from which we forked. We will continue to better our software in the best way we see fit, taking into consideration any and all responsible disclosures and feedback. (Please remind your audience that we hold no social media presence, and may be contacted via email following the instructions on our website). -----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEERF+AeZb3BYa3Fce4oTgGsfoqZ2sFAmh2HrgACgkQoTgGsfoq Z2vE+RAAin787XCnxk+LUyXLBWXgR8uB0b1PRbtLok5XJHLVZ5ZaP4W3L1PC0C5j uRCGlgX00Gzv23dYLeLEo4ZKmQSsa3gxJWrw5LTatu9/p3sCKy9PP/D4nKhiAlWW D0/E24q40YFSb1wr6aRZElWiy3KEpViLldbA9+N8oyYYw0MEMCNyPTmYrj0G62AX yHJqGYlk8Im6kuYfnOrEALazB+m12hkahXbjmpZ7CoBAYWOptaCR1iyOL+wvCMtw 7yqyk3VvBTB6Uosb5i9XcDEePxDvxWi0oZCtCm1VCGlng0PFGH1kVOVzKF8PrFkf XK/QZ2P2aByMaoBGGt/4lNm+1OTDN8kwYYoM0EndedW0BtE+KhDhOr1XEMp+fptl P+V37jv5OpgVUxUPLrMwilRgR0lPUa956rv15dmCXrJc5EV8iVOUrA/Y3EJPn6jN /AahLPhVtDUt/NUKeMoVRE59TPlWZrSkmjBGHFuyBrJSmAtNLUnGLUVj9Fz4n7ak k3xdI6bzWY30CkXx2QAV9tziEbhzSMUF0c/tyyGQ2YNUrd/s0GkhPeWedUiGBaKp U/n0u7+STKtxK9ilW4tk8ocJZ2viQVfn4mUQ0vldlwlvFy6oXYSWoWzXY46z9tEY /y8NkIZx2e2gtJ32T+RnZhG4yY4fg4OakvSOstVBQQj6eZLuM10= =hc7O -----END PGP SIGNATURE-----

The "expert" mentioned was LaurentMT on X.

Verify yourself using:

gpg --verify response.md

OR:

Use the raw format with https://keybase.io/verify to check that the message is authentic.

A coordinator shouldn't have any privileged information about participants. Besides, if making some information public is considered as a threat to users' privacy then it means that the coordinator can use this same (private) information against users.

For instance, it has been known for a while that a malicious Whirlpool coordinator may run a targeted sybil attack against specific UTXOs allowing the coordinator to link an input of a mix to an output with 100% certainty. This attacks costs little and is almost undetectable as is. In order to protect themselves against this kind of attacks, all participants to the round should be able to independently verify that the coordinator is honestly applying a random selection of remixed UTXOS among all registered freeriding UTXOs.

In order to achieve this, we need 3 things:

• Coordinator committing to the entropy that will be used for the random selection of remixed UTXOs and making this information public when a new round of mixing is initialized (e.g. Three random decimals (0<=x<1) published with the information related to the round.
• Participants publicly registering their inputs. This information should be received by all participants to the round without any interference from the coordinator. Soroban plays the role of a communication bus allowing all participants to get this information.
• A deterministic algorithm describing how the random selection should be applied by the coordinator and verified by all participants (e.g. Sort all registered freeriding UTXOs by alphanumeric order of TXIDs then select 3 remixed UTXOs by using the committed decimals).

Participants can verify that the coordinator is honest at protocol level with their client software validating that:

• the list of registered freeriding UTXOs doesn't differ by more than a small percentage from the list provided by the coordinator when it notifies participants of its selection.
  -the coordinator has honestly applied the random selection of remixed UTXOs.

Those that have leveled criticism have not contacted us directly.

that is because contacting directly requires jumping through unnecessary hoops

We believe we are able to mitigate DoS issues by the server storing signed messages from the client although this is a secondary concern to resolving linkability.

1. mallory registers input A to mix 1
2. mallory successfully confirms input A, obtaining a blinded signature S_B
3. mallory times out without registering an output
4. mallory later registers input B to mix 2
5. mallory succesffully confirms input B, obtaining blinded signature S_B
6. mallory races some other user to register two outputs with the unblinded S_A and S_B
7. if mallory wins the race, the other user is blamed for not signing

We are internally testing a remediation of this attack vector now where the client provides a message consisting of a base64 of a pool ID and a block hash during a recent time range. The server will validate and sign this and the client subsequently validate.

i'm referring to the fact that the (blind) signature is never verified to be a valid signature by the public key.

this mitigation idea seems to attempt to address a separate concern, which is the replayability of ownership proofs, raised by Lucas Ontivero.

including anti-Sybil and mining fees,

coordination fees only "anti-Sybil" if the coordinator is assumed to be trusted, which makes a sybil attack [edit: by a malicious coordinator] for n-1 deannonymization out of scope by definition. if the protocol were actually trustless, then the coordinator earning a revenue can subsidize sybil attacks. [edit: if the coordinator is not trusted and can be malicious, deanonymization would require controlling seemingly honest inputs, which is not costless]

We have not seen a way to achieve this and believe a single RSA key is still the best approach, albeit with enhancements we will add in our next release.

generate a per mix RSA key

sign the per mix key with the static key.

this does not address key consistency, but does address the DoS concern.

---

none of the above matters given that mixid is a cleartext tagging vector and the ownership proofs do not commit to it.

a rather invasive change to the protocol would be to register inputs in two phases, requiring two ownership proofs.

the first proof would prove to the coordinator that the client is the rightful owner of the input. it is required for mixid assignment to be DoS resistant.

the second proof would also commit to the assigned mixid and the per mix key.

all clients must then receive the previous transactions, and the ownership proofs, and verify that they they are all valid and commit to the same mixid and per mix key prior to registering outputs (requesting blind signatures before this is OK).

to avoid accessing spending keys twice, only one ownership proof can be used, so long as it commits to an ephemeral signing key used by the client to sign the mix id and the blind signing key.

with these mitigations in place the coordinator would only be trusted to perform mixid assignments honestly (which is still problematic), so the coordinator would still be trusted with assigning outpoints to mixids. without a consensus layer validated by clients there's no way to make that strictly trustless, by verifiably randomly partitioning the set of candidate inputs, because there is no way for the coordinator to prove that it hasn't omitted any inputs, but as LaurentMT points out even without client consensus on the set of candidate coins this can at least be partially mitigated, and clients can at least check that their inputs are not being omitted.

t is unfortunate that because we have forked and built upon a project that some of these developers have had animosity towards in the past, that they expect malicious intent from us.

my animosiity was due to vague allusions to my description of the tagging vulnerability, instead of an actual citation, and the lack of followup to make sure it was actually addressed while unequivocally claiming it was addressed, when many aspects of my description were ignored in the attempted solution.

We have not seen a way to achieve this and believe a single RSA key is still the best approach, albeit with enhancements we will add in our next release.

this implies a lack of understanding of concepts such as PKI / key certificate for authenticity, something that should be necessary background knowledge for implementing a blind signing scheme with key consistency

this in conjunction with steep coordination fees misrepresented as "anti-Sybil" does not inspire confidence to say the least

Decentralization was mentioned 3 times in this response. Wouldn't have been difficult to improve or contribute to the decentralized protocols that already exists for coinjoin.

We have already demonstrated that we will make changes to our codebase based on user concern as can be seen by our efforts on reproducibility.

🦗 🦗 🦗