Re: [Taler] reduce attack surface (Case 1)

[Florian Dold]

-------- Forwarded Message --------
Subject: Re: [Taler] reduce attack surface (Case 1)
Date: Sun, 27 Sep 2015 10:41:48 +0200
From: Christian Grothoff <address@hidden>
To: Taler <address@hidden>

Hi again,

Seems mail delivery works again (sending this one for a 3rd time).

Interesting proposal. I had been aware of the "attack" scenario you
describe (it's a (1-hop) variant on the Columbian Black Market
Exchange or a voluntary version of the "Perfect Crime Attack", so very
much one of the scenarios we describe in the discussion).  Anyway,
because it's 1-hop and because ideally we'd want to skip the
entire withdraw protocol (once we integrate more tightly with a bank, we
can skip this awkward step and just have the customer withdraw directly
from his bank account --- so the entire issue does go away once we have
accounts at the mint), thus I didn't worry about it too much.

Now, your solution (1) isn't too hard to implement, (2) actually
simplifies the protocol as the withdraw becomes simpler, but (3)
increases cost (extra refresh step) and (4) I don't think your fix
actually works.  So mostly because of (3) higher cost and (4) still
doesn't help this is not helpful, even if (1) and (2) are true.

Let me explain why it doesn't work.  With your protocol, one can still
do this:

1.) the dope-seller creates (Cs,Cp)
2.) the dope-buyer receives (Cp) from the the dope-seller.
3.) the dope-buyer makes wire transfer with subject <Cp, S_C( K,
CoinValue )>
// ...

Basically, the argument why you cannot fix it this way is the same that
I had with Jeff (?) a few weeks back in the office: we can use refresh
to chain, but the chain has to be rooted.  Thus, when Taler coins are
first created by moving from  the traditional banking system to Taler,
you make this 1-hop transfer where you cannot be sure who receives it.

Still, this isn't ultimately a problem: (1) this doesn't work for more
than 1-hop (unlike cash or the Columbian Black Market which are
unrestricted in that regard), and very much like the Perfect Crime
attack (both of which applied already to Chaum in very much the same
way); and (2) *if* we reach the point where deposits don't go back into
the banking system, but back into a "Taler account" where an individual
is linked to a private key, then we can use the private account keys (!)
in a refresh-like protocol for withdrawal.  That'll also be an
interesting way to do backups of keys.

So this just simply doesn't work with wire transfers (but this is why
the paper states that using the withdrawal key for authentication is
just one conceivable method).  (2) will have the drawback that your
private key becomes extremely valuable (I can link *all* of your
transactions when I get hold of it, and also get hold of all of your
Taler coins.), so it is not something I'd want to see outside of
_really_ secure hardware, but at least this is theoretically a fix to
address this "attack surface" within the limitations of the protocol.
Regardless, as discussed in the paper, for the first deployment we'll
just live with those limited loopholes.

I understand the discussion in the paper is very, very brief on this,
but we only have 15 pages for this version. Anyway, your points (except
for the proposed fix) are of course valid.


Happy hacking!

Christian

On 09/26/2015 11:41 PM, Fabian Kirsch wrote:
> Dear all,
>
> as the "tax evasion transaction" is a very new thread concept i want to
> suggest a slight protocol change
> in order to reduce attack surface:
>
> Redesign the withdrawel to create one single coin, without blinding,
> without anonymity.
> The anonymity and the splitting can than be achieved by "refreshing"
> which has to be implemented anyway.
>
> So
> 1.) customer creates <Cs, Cp>
> 2.) customer chooses coin-signer K
> 3.) customer signs S_C( K )
> 4.) customer makes wire transfer with subject <Cp, S_C( K, CoinValue )>
> and Amount=CoinValue+Fees
> 5.) mint signs S_K(Cp) if it agrees, otherwise the wiretransfer is
> bounced back
> A) this coin is now legally traceable connected to the wire transfer
>
> proposed Attack on current protocol:
> 1.) the dope-seller creates (Cs,Cp)
> 2.) the dope-buyer receives (Cs,Cp) from the the dope-seller.
> 3.) the dope-buyer transfers value from its reserve Wp to the sellers Coin
> A) because of the blinding, there is no linkable record of this
transaction
> B) dope-seller and dope-buyer can both check the signature S_K(Cp),
> which is proof of their hidden transaction
> C) Cs is not shared
>
> Greetings
>  Fabian
>