Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reusing unprovided output #51

Closed
anwfr opened this Issue Nov 15, 2017 · 7 comments

Comments

Projects
None yet
2 participants
@anwfr
Copy link
Contributor

anwfr commented Nov 15, 2017

I was wondering about the following scenario, if banning unprovided outputs is not implemented:

  • Alice registers inputs on a first round, but doesn't provide the output
  • A new round starts
  • Alice provides unblinded output(s) from previous round(s)

Would this enable her to disturb the round? (more outputs than expected)
Even maybe to steal money by getting her output instead of someone's else in transaction? (of course client should verify tx output before signing it...)

If so, blame protocol for banning unprovided outputs is a MUST.

Best regards

@nopara73

This comment has been minimized.

Copy link
Owner

nopara73 commented Nov 15, 2017

This is bad. I did not think about. Stealing of course cannot happen, because if an Alice doesn't see its output in the coinjoin, it won't sign (and unsigned Alice gets banned, this is actually the hidden blame protocol). But a new type of disruption is now possible. I'll spend all my time on this, until it gets addressed.

@nopara73

This comment has been minimized.

Copy link
Owner

nopara73 commented Nov 15, 2017

Here's the fix. I'm going to add the following lines to the specification under DoS Attack section.

DoS 4: What if Bob provides a signed output in the wrong round?

If Bob refuses to provide an output in the round it acquired its signature, then the corresponding Alice gets banned in Signing phase, because she will not provide signature to the CoinJoin.
However Bob's output will never be unblinded, therefore at OutputRegistration phase the Tumbler does not know if the output had been signed in the current or in some previous round.
In order to disrupt the round Alice can keep acquiring signatures (in expense for her utxos to get banned) and providing outputs to incorrect rounds.
For privacy reasons the Tumbler MUST refuse the same blinded signature to be registered twice in Input Registration phase and the Tumbler MUST refuse the same active output to be registered twice in Output Registration phase. This may already makes it uneconomical to keep this attack up for too long, but ZeroLink introduces an extension to the Chaumian CoinJoin protocol to completely defend against this attack:

  1. At Connection Confirmation phase, for Alice's connection confirmation request, the Tumbler answers with a hash of all inputs, called roundHash.
  2. At Output Registration phase this roundHash must be provided to the Tumbler by Bob.
  3. At Signing phase, when Alice acquires the CoinJoin, she must check if the roundHash is indeed the hash of all inputs.

The question arises, why not use a random round identifier, instead of roundHash? It is because the Tumbler could trick Alices into providing them different round identifiers and with that information deanonymizing the round.

@nopara73 nopara73 closed this Nov 15, 2017

@nopara73

This comment has been minimized.

Copy link
Owner

nopara73 commented Nov 15, 2017

Maybe I can keep this open until you ack the fix.

@nopara73 nopara73 reopened this Nov 15, 2017

@anwfr

This comment has been minimized.

Copy link
Contributor Author

anwfr commented Nov 15, 2017

Thanks for the fix! Looks good ;)

@anwfr anwfr closed this Nov 15, 2017

@nopara73

This comment has been minimized.

Copy link
Owner

nopara73 commented Nov 15, 2017

Me thanks. For the record I already implemented it. zkSNACKs/WalletWasabi@8d4c682

@nopara73

This comment has been minimized.

Copy link
Owner

nopara73 commented Nov 15, 2017

@anwfr

This comment has been minimized.

Copy link
Contributor Author

anwfr commented Nov 15, 2017

Sure! Thx :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.