CreditMix: a decentralized mixing protocol for Ripple

Technical questions about the Ripple API, the protocol, etc.

CreditMix: a decentralized mixing protocol for Ripple

Postby pedrorechezripple » Mon May 30, 2016 5:07 pm

Hello,

We are a security and privacy research group, with members in Germany and USA, interested in payment networks and cryptocurrencies.

Recently, we have written a research paper in which we propose CreditMix, a decentralized protocol that allows to mix Ripple transactions without requiring any change to the current Ripple network. In a nutshell, CreditMix allows a set of Ripple users to solve the following contract:

1. Assume that every user has x IOU on her input wallet.
2. Assume that every user has created a fresh output wallet and thus it does not have any IOU.
3. If every user correctly follows CreditMix, IOU on each user’s input wallet is decreased by x. Moreover, each user can send x IOU from her output wallet.
4. If at least one user misbehaves, IOU in all wallets is maintained as defined in steps 1 and 2.

CreditMix is a decentralized protocol that realizes this contract and ensures that nobody can determine the input and output wallets belonging to the same user (i.e., unlinkability of wallets is preserved). Moreover, CreditMix does not require any change to the Ripple definition and thus can be seamlessly deployed in the current Ripple network. In fact, we have successfully tested our proof-of-concept implementation of CreditMix in the current Ripple network. We have simulated a successful run of CreditMix for 5 users: each user wants to send 10 IOU from her input to her output wallet. The details of this test can be observed in the following Ripple tools:
* Involved wallets: https://www.ripplecharts.com/#/graph/rMDvFAhSPYEaUNxqrqo88xCwiZXG9P3LNK (You can click on the nodes to expand the network)
* Payment to perform the mixing of the IOU: https://www.ripplecharts.com/#/graph/21BCE61D6843F23D9A02D745AB788CFF679C6E99ECF70D56C141ACB8560AA370

A preliminary version of the paper is available at http://crypsys.mmci.uni-saarland.de/projects/FastDC. There, we provide a detailed description of the protocol (including the full pseudocode) and the illustrative example that we have tested in the Ripple network.

We would be happy to hear your feedback and critique about our proposal.
pedrorechezripple
 
Posts: 9
Joined: Wed Sep 17, 2014 7:17 pm

Re: CreditMix: a decentralized mixing protocol for Ripple

Postby Sukrim » Mon May 30, 2016 7:19 pm

Sounds quite interesting, I'm not so sure how I feel about the fact that the ledger is getting spammed with temporary accounts that way.

Maybe an "ephemeral/spendonly" account type next to "normal" and "multisign/keyonly/virtual" accounts might be useful that is designed to be funded and set up in a single (set of) transaction(s) and will be permanently purged from the ledger again once all its paths ran dry with no way to send money towards it (neither XRP nor IOUs)? That way there also might be some protection against the "everybody against me" scenario, where you are trying to mix with n instances of the (secretly) same person. As far as I understand it, in this scenario this person then would know n of the n+1 inputs that make up the shared key(s) of the common accounts which might be problematic not only privacy wise, but also resulting key strength wise.

About mixing BTC: You might also want to check out/analyze https://github.com/JoinMarket-Org/joinmarket which tries to add incentives and revenue for people offering coins to be CoinJoin mixed.
Sukrim
 
Posts: 1813
Joined: Mon May 20, 2013 10:44 am

Re: CreditMix: a decentralized mixing protocol for Ripple

Postby pedrorechezripple » Mon May 30, 2016 11:25 pm

Thank you Sukrim for your interest :)

In a setting like the one you describe in the "everybody against me" scenario, no privacy is possible at all: If a person knows n out of the n+1 inputs and outputs, the unkown pair of input and output wallets must belong to the other person. Nevertheless, this is a generic and well-known problem of mixing that appears in every mixing protocol.

The "everybody against me" scenario is not a problem for the shared wallets though. A transaction from a shared wallet is only possible if all people sign the transaction. Thus, even if a person has n out of n+1 input wallets (and thus n out n+1 signing keys), this person needs the signature from the other person to make a transaction from a shared wallet valid.
pedrorechezripple
 
Posts: 9
Joined: Wed Sep 17, 2014 7:17 pm

Re: CreditMix: a decentralized mixing protocol for Ripple

Postby Sukrim » Tue May 31, 2016 1:21 pm

As far as I understand it, the account where the funds to be mixed end up and that trusts A', B' etc. for the same amount (thus achieving the mixing) is generated algorithmically by all participants (SAccountGen in Appendix A). Of course if there are only 2 actual participants ( one impersonating a huge amount of them), there is no real privacy. What I'm a bit concerned about is if it also might be an issue cryptographically.

The private key of the shared account will be calculated/derived from a combination of some secret of each participant and if you have all of these secrets, you could of course manually verify it. If you know n-1 secrets, how safe is the resulting private key or is there a way to choose your secrets that might even leak some parts of the nth secret?

Suppose there's Alice with account A and Eve with accounts E1-E49.
Alice doesn't know about this and takes part in a 50 participants mixing together with these accounts (A, E1, E2, ... E49).
As Eve now knows 49/50 inputs to the resulting shared account secrets for VKin and VKout, is their private key still as secure as Alice's contribution to it or less? The risk is that Eve might try to guess VKout and steal Alice's contribution to the mix.

Also, I guess that Vkin and VKout are only used once, ever, even if the same participants decide to mix again, right?
Sukrim
 
Posts: 1813
Joined: Mon May 20, 2013 10:44 am

Re: CreditMix: a decentralized mixing protocol for Ripple

Postby pedrorechezripple » Fri Jun 03, 2016 2:00 pm

Hi Sukrim,

The private key of the shared account will be calculated/derived from a combination of some secret of each participant and if you have all of these secrets, you could of course manually verify it. If you know n-1 secrets, how safe is the resulting private key or is there a way to choose your secrets that might even leak some parts of the nth secret?


If the attacker knows n-1 secrets, the final private key is still secure (i.e., unknown to the attacker). The resulting private key is the sum of the secrets from each participant. For example: S = s1 + s2 + ... + s49 + s50. Following with your example, if the attacker does not know s50, the final S could be any value depending on s50. Another point is that there is no relation between s_i and s_j if they belong to different participants.

Also, I guess that Vkin and VKout are only used once, ever, even if the same participants decide to mix again, right?

Yes, you are right. We do this to ensure that two different runs of the protocol are totally independent.
pedrorechezripple
 
Posts: 9
Joined: Wed Sep 17, 2014 7:17 pm


Return to Developers

Who is online

Users browsing this forum: No registered users and 4 guests