From: Sjors Provoost <sjors@sprovoost.nl>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Cc: Yuval Kogman <nothingmuch@woobling.org>
Subject: Re: [bitcoindev] Reiterating centralized coinjoin (Wasabi & Samourai) deanonymization attacks
Date: Mon, 6 Jan 2025 14:07:58 +0100 [thread overview]
Message-ID: <E26BEB3C-1345-487D-A98C-2A7E17494B5E@sprovoost.nl> (raw)
In-Reply-To: <CAAQdECCdRVV+3ZoJhOotKEvmUV4yrV7EYWE8SOWCE1CF9tZ6Yg@mail.gmail.com>
Thanks for the write-up.
I’m curious to learn if any of these attacks happened in practice,
and if there are methods to find out retroactively.
> In Whirlpool, the server's blind signing key is obtained by the client
> by extracting it from the response to the input registration
> request.[^2]
> Because the key is not announced a priori, nor is it signed by the
> participants' spending keys before output registration or signing[^5],
> the server can provide each input with a unique RSA key. Since the
> unblinded signatures are made by different keys, the server can learn
> the mapping from inputs to outputs.
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.
Perhaps if the app kept sufficient logs, it would still be possible to retroactively
check this.
> ### WabiSabi
>
> In the protocol clients register their Bitcoin UTXOs independently. A
> valid input registration request includes a BIP-322 ownership proof,
> which commits to the so called *Round ID*. This in turn is a hash
> commitment to the parameters of the round, including the server's
> anonymous credential issuance parameters (analogous to a public key).
>
> The parameters are obtained by polling the server for information
> about active rounds. If inconsistent round IDs are given to clients,
> this effectively partitions them, allowing deanonymization.
Are these round IDs logged by clients?
* = 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.
- Sjors
--
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/E26BEB3C-1345-487D-A98C-2A7E17494B5E%40sprovoost.nl.
next prev parent reply other threads:[~2025-01-06 13:21 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-21 14:16 [bitcoindev] Reiterating centralized coinjoin (Wasabi & Samourai) deanonymization attacks Yuval Kogman
2025-01-06 13:07 ` Sjors Provoost [this message]
2025-01-06 14:30 ` Yuval Kogman
2025-01-07 15:56 ` waxwing/ AdamISZ
2025-01-07 21:33 ` Yuval Kogman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E26BEB3C-1345-487D-A98C-2A7E17494B5E@sprovoost.nl \
--to=sjors@sprovoost.nl \
--cc=bitcoindev@googlegroups.com \
--cc=nothingmuch@woobling.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox