exchange/doc/paper/taler_FC2017.txt

----------------------- REVIEW 1 ---------------------
TITLE: Refreshing Coins for Giving Change and Refunds in Chaum-style Anonymous Payment Systems
Overall evaluation: -2

----------- Overall evaluation -----------
This paper proposes an anonymous payment system called Taler, based on the
Chaum’s blind signature scheme. Taler employs a new refresh protocol that
allows fractional payments and refunds while providing the unlinkability and
untraceability. The refresh protocol uses the cut-and-choose technique to
assure that the protocol is not abused for evading taxation. 

Comment: The correctness of the refresh protocol does not hold. The \bar{B(i)}
computed by the exchange is not equal to B(i) computed by the honest customer,
as \bar{Cp(i)} is not equal to FDHK(Cp(i)).

> This was a simple typo that is fixed now

This paper does not provide a security proof or even an informal security
analysis for the proposed anonymous payment system Taler, such that Taler may
be insecure.

> We added a section with proofs

I find two (possible) attacks against the refresh protocol. As the
exchange does not check the validity of the public key Cp′ , the attacker can
send an arbitrary public key to the exchange that will accept, and obtain a
fresh coin. The attacker can spend partially a coin multiple times via
refreshing the coin and obtaining a fresh coin in turn, as the refresh protocol
only transforms a dirty coin into a fresh coin with the same denomination. The
misbehavior will not be detected by the exchange, as the fresh coin is
unlinkable to the original coin.

> When refreshing a coin, the old coin is obviously marked as spend.
> This attack is based on a misunderstanding of refreshing.

The implementation of Taler in this paper is
unclear. For example!  , the security level, the RSA modulus, and the elliptic
curve etc. are not described.

> The RSA modulus depends on the denomination, for higher denominations
> with a longer lifetime it makes sense to use a larger key size.
> The elliptic curves are given and referenced in the paper, namely Ed25519 and
> Curve25519

Moreover, the average time of the withdrawal, spending, refreshing protocols
are not provided. The authors also do not compare Taler with other known
anonymous payment systems. Thus, the efficiency of Taler is unclear.     

> In our "Experimental Results" section we mention that local processing
> of requests happens in the order of a few milliseconds.
> Comparing Taler to other e-cash systems experimentally is impossible,
> since their implementation is not available.

Additional Comment: The description of the protocols of Taler omits many
details. In particular, the authors should describe in detail how the refunds
are executed using the refresh protocol, as the authors claim that the refresh
protocol allows refunds as a contribution.

> We added more material on refunds

Furthermore, the authors should interpret the notation FDHK, and cite the
reference for EdDSA. The title of Subsection 3.1 may be misleading, as this
subsection does not describe the security model. The authors should rename the
title. The “We have computed Li…” in Subsection 4.3 should be L(i).

> FIXME: can/should we address this?


----------------------- REVIEW 2 ---------------------
TITLE: Refreshing Coins for Giving Change and Refunds in Chaum-style Anonymous Payment Systems
Overall evaluation: -2

----------- Overall evaluation -----------
This paper proposes a new e-cash, named Taler, where the bank (or else called
exchange) is online during the spending protocol to allow for double-spending
detection. Taler allows for spending coins of various denominations by allowing
a user to only spend a value v1<V (where V is the value of the withdrawn coin)
and then exchange the remaining value for a new, fresh coin, of value V-v1. The
proposed scheme is different compared to Chaum e-cash: in Taler coins are pairs
of pk/sk keys where the public key has been signed by the bank/exchange while
in typical Chaum e-cash coins are represented by unique serial numbers.


Although the proposed system is hiding some interesting ideas, I think it
cannot be accepted for publication at the moment. First and most importantly
the current version of the paper lacks any level of analysis (not even
informal) of the security level that system achieves. In fact, what security
means has not been defined even in an informal lever. Moreover, as I better
explain in my specific comments below there seem to be some issues with both
security and anonymity (linking different uses of same coin, ensuring coin
refreshing happens for the correct value).  Finally, the description of the
protocols has quite a few inconsistencies (details below): there are parts that
seem unnecessary and others that are not properly defined/explained, notation
is also very overloaded (there is a 2 page notation table!).


Specific comments:

- I would expect the “Security Model” section (Section 1.3) to actually explain
  (even in an informal way) the desired properties of the proposed scheme.
  These should include double-spending detection security, unforgeability, user
  anonymity and more importantly the new type of security introduced by coin
  refresh (this should be a property that guarantees that a user cannot re-fresh
  a coin for value more than the one that the “dirty” coin is carrying) Instead
  it just mentions some of the tools used in the proposed scheme (i.e. FDH
  signatures, cut-and-choose and what kind of security they offer).

- Related work missing: there has been previous work in “payments with
  refunds”. Please look at Rupp et al “P4R: Privacy-Preserving Pre-Payments
  with Refunds for Transportation Systems” where instead of refreshing coins, the
  unused amount is accumulated in some token that can later be used. How would
  you compare with that system?

- Found the discussion on Bitcoin too long and unnecessary - the proposed
  system is not decentralized anyway

- Referencing a system (Goldberg’s HINDE) that is not published makes
  impossible for the reviewer to check any arguments. 

- Section 4.1, step 1: is W_p = w_s * G? Also where is blinding factor b
  selected from? What does it mean to “commit to disk”? The customer commits
  and keeps the commitment local? Where is this used?

- Section 4.1, step 3, what is the key K used in FDH? Also is S_w(B) a standard
  signature?

- Section 4.1, step 4, How can the exchange know that this was indeed a new
  withdrawal request? If a new blinding factor b is used, then a customer can
  create multiple “freshly” looking requests for the same C_p.  (Also a minor
  point: 2nd line also reads as “if the same withdrawal request was issued before
  the exchange will send S_K(B)”

- Section 4.2, it seems that a customer can use a coin of value say $10 to
  multiple transactions of <= $10 in total. I.e. it can first a pay a merchant
  M1 $2 and then a merchant M2 another $5 dollars. In that case the exchange can
  link those two payments together. Sure, it might not know who is the owner of
  the coin (i.e. cannot link with withdrawal) but this is still an anonymity
  problem.

- Section 4.3, doesn’t seem very fair to compare with Zcash or at least it
  should be highlighted that a quite weaker level of anonymity is achieved.

- Section 4.3, step 1, where is the key t_s^(i) selected from? What does S_{C’}
  denotes? Is that a commitment (as noted in the text) or a signature (as noted
  in notation table?). 

- Section 4.3 In this protocol I would expect the customer to somehow “prove”
  to the exchange what is the remaining value of the dirty coin. I do not see
  this happening. How does this part of the protocol ensure that a user cannot
  just refresh a coin for one of a much bigger value than the remaining one?


----------------------- REVIEW 3 ---------------------
PAPER: 46
TITLE: Refreshing Coins for Giving Change and Refunds in Chaum-style Anonymous Payment Systems
Overall evaluation: -1

----------- Overall evaluation -----------
The paper introduces a variant's of Chaum's e-cash scheme (with an
on-line bank); the main novelty is a "refresh" protocol which enables
a user to exchange a coin for a new blinded one. The reason for
wanting this features is that it enables refunds from a merchant that
later can be refreshed into "clean" coins that are unlinkable to the
refunded coins. The protocol is based on what appears to be a standard
cut-and-choose approach, which does not appear to be particularly
novel. On the postive side, the problem appears a natural and if it
hasn't been done before certainly useful. On the negative side, since
the paper does not contain any formal definitions, or even semi-formal
specifications of the desiderata, it is very hard to understand what
actually is acheived. Furthermore, no proofs of security are given,
and even the protocol is hard to fully understand. As such, I would
suggest the authors to first formalize their approach and
resubmitting.