[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GNUnet-SVN] [taler-exchange] branch master updated: fc17 reviews
From: |
gnunet |
Subject: |
[GNUnet-SVN] [taler-exchange] branch master updated: fc17 reviews |
Date: |
Tue, 16 May 2017 13:04:56 +0200 |
This is an automated email from the git hooks/post-receive script.
dold pushed a commit to branch master
in repository exchange.
The following commit(s) were added to refs/heads/master by this push:
new 49f590d fc17 reviews
49f590d is described below
commit 49f590d8dc88260741f035b7b1858e4e74d5ea45
Author: Florian Dold <address@hidden>
AuthorDate: Mon May 15 15:40:12 2017 +0200
fc17 reviews
---
doc/paper/taler_FC2017.txt | 86 ++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 86 insertions(+)
diff --git a/doc/paper/taler_FC2017.txt b/doc/paper/taler_FC2017.txt
new file mode 100644
index 0000000..7724bef
--- /dev/null
+++ b/doc/paper/taler_FC2017.txt
@@ -0,0 +1,86 @@
+----------------------- REVIEW 1 ---------------------
+PAPER: 46
+TITLE: Refreshing Coins for Giving Change and Refunds in Chaum-style Anonymous
Payment Systems
+AUTHORS: Florian Dold, Sree Harsha Totakura, Benedikt Müller, Jeff Burdges and
Christian Grothoff
+
+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 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. I find two (possible)
attacks against the refresh protocol. As the exchange does not check the
validity of the public key Cp′ [...]
+ , the security level, the RSA modulus, and the elliptic curve etc. are not
described. 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.
+
+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. 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 r [...]
+
+
+----------------------- REVIEW 2 ---------------------
+PAPER: 46
+TITLE: Refreshing Coins for Giving Change and Refunds in Chaum-style Anonymous
Payment Systems
+AUTHORS: Florian Dold, Sree Harsha Totakura, Benedikt Müller, Jeff Burdges and
Christian Grothoff
+
+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 whe [...]
+
+
+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 differen [...]
+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 [...]
+
+- 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?
+
+
+
+Typos
+Sec. 3.1 “cryptographily” -> cryptographically
+Sec 4.2, Step 1 “a exchange” -> an exchange
+Sec 4.3, 3rd line should be -> at the same time
+
+
+----------------------- REVIEW 3 ---------------------
+PAPER: 46
+TITLE: Refreshing Coins for Giving Change and Refunds in Chaum-style Anonymous
Payment Systems
+AUTHORS: Florian Dold, Sree Harsha Totakura, Benedikt Müller, Jeff Burdges and
Christian Grothoff
+
+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.
--
To stop receiving notification emails like this one, please contact
address@hidden
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [GNUnet-SVN] [taler-exchange] branch master updated: fc17 reviews,
gnunet <=