231 lines
11 KiB
Plaintext
231 lines
11 KiB
Plaintext
----------------------- REVIEW 1 ---------------------
|
||
TITLE: Refreshing Coins for Giving Change and Refunds in Chaum-style Anonymous Payment Systems
|
||
|
||
----------- 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 length is freely configurable, the specific RSA modulus
|
||
> (n) will change between different denominations. For the experiments
|
||
> we used RSA 1024, but there keys only live for like a week; for deployments
|
||
> with a longer lifetime, it likely makes sense to use a larger key size.
|
||
> The elliptic curves are given and referenced in the paper, namely Ed25519
|
||
> (used for all signatures) and Curve25519 (ECDHE, in refreshing).
|
||
|
||
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.
|
||
> Comparing Taler to blockchain-based solutions is comparing apples and
|
||
> oranges, and blockchain-based solutions are many (10^8?) orders of magnitude
|
||
> slower.
|
||
|
||
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.
|
||
|
||
> We added FDH_K to the notation list.
|
||
> We added citations 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.
|
||
|
||
> We changed the title.
|
||
|
||
The “We have computed Li…” in Subsection 4.3 should be L(i).
|
||
|
||
> Li-typo was fixed.
|
||
|
||
|
||
----------------------- REVIEW 2 ---------------------
|
||
TITLE: Refreshing Coins for Giving Change and Refunds in Chaum-style Anonymous Payment Systems
|
||
|
||
----------- 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).
|
||
|
||
> We added a section with that goes deeper into properties and proofs
|
||
|
||
- 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?
|
||
|
||
> We added this to the related work, main problem with this work is that it is
|
||
> limited to/meant for public transportation systems. For general payments,
|
||
> their refund can be abused to create transactions that are not
|
||
> taxable.
|
||
|
||
- Found the discussion on Bitcoin too long and unnecessary - the proposed
|
||
system is not decentralized anyway
|
||
|
||
> Correct, but we constantly find people thinking Taler is a crypto-currency,
|
||
> so for some readers it is important to point out the differences.
|
||
> We have tried to keep the discussion short.
|
||
|
||
- Referencing a system (Goldberg’s HINDE) that is not published makes
|
||
impossible for the reviewer to check any arguments.
|
||
|
||
> In an earlier submission, a reviever insisted that this reference
|
||
> be added.
|
||
|
||
- 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?
|
||
|
||
> Yes, juxtaposition denotes multiplication. "commit to disk" has been
|
||
> changed to "persist", the customer must persis the value before making the
|
||
> bank transaction, so that they don't lose their reserve key should the system
|
||
> crash. It is used to restart the operation in case of a crash.
|
||
> Where the blinding factor "b" is selected from depends on the instantiation
|
||
> of the protocol, it's simply a fresh blinding factor in the blind signature
|
||
> scheme.
|
||
|
||
- Section 4.1, step 3, what is the key K used in FDH? Also is S_w(B) a standard
|
||
signature?
|
||
|
||
> The "K" here means that the domain of the full domain hash is the
|
||
> modulus of the public key K_v of the key pair K.
|
||
|
||
- 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)”
|
||
|
||
> We added some clarification that the exchange looks up if the request
|
||
> already exists in their database.
|
||
|
||
- 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.
|
||
|
||
> Yes, this is why the user has to refresh a partially spend coin
|
||
> before reusing it, unless they don't care about their anonymity.
|
||
|
||
- 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.
|
||
|
||
> We added a remark on the high level of anonymity that Zerocash achieves
|
||
|
||
- 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?).
|
||
|
||
> We multiply t_s^(i) with G, so the only reasonable domain is
|
||
> [1,n] where n is the order of the elliptic curve we use.
|
||
> S_{C’} is a signature made with private key C’_p, what we sign
|
||
> over is the commitment.
|
||
|
||
- 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?
|
||
|
||
> The exchange records spent coins (with the amount spent) in it's database.
|
||
> When refreshing a coin, the customer must reveal the coin's (unblinded)
|
||
> public key to the exchange, which will then set the remaining value
|
||
> of the coin to zero in it's database. The new coin is now allowed
|
||
> to exceed the old coin in value.
|
||
|
||
|
||
----------------------- REVIEW 3 ---------------------
|
||
PAPER: 46
|
||
TITLE: Refreshing Coins for Giving Change and Refunds in Chaum-style Anonymous Payment Systems
|
||
|
||
----------- 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.
|
||
|
||
> We added a section with proofs
|