taler_FC2017.txt (11540B)
1 ----------------------- REVIEW 1 --------------------- 2 TITLE: Refreshing Coins for Giving Change and Refunds in Chaum-style Anonymous Payment Systems 3 4 ----------- Overall evaluation ----------- 5 This paper proposes an anonymous payment system called Taler, based on the 6 Chaum’s blind signature scheme. Taler employs a new refresh protocol that 7 allows fractional payments and refunds while providing the unlinkability and 8 untraceability. The refresh protocol uses the cut-and-choose technique to 9 assure that the protocol is not abused for evading taxation. 10 11 Comment: The correctness of the refresh protocol does not hold. The \bar{B(i)} 12 computed by the exchange is not equal to B(i) computed by the honest customer, 13 as \bar{Cp(i)} is not equal to FDHK(Cp(i)). 14 15 > This was a simple typo that is fixed now 16 17 This paper does not provide a security proof or even an informal security 18 analysis for the proposed anonymous payment system Taler, such that Taler may 19 be insecure. 20 21 > We added a section with proofs 22 23 I find two (possible) attacks against the refresh protocol. As the 24 exchange does not check the validity of the public key Cp', the attacker can 25 send an arbitrary public key to the exchange that will accept, and obtain a 26 fresh coin. The attacker can spend partially a coin multiple times via 27 refreshing the coin and obtaining a fresh coin in turn, as the refresh protocol 28 only transforms a dirty coin into a fresh coin with the same denomination. The 29 misbehavior will not be detected by the exchange, as the fresh coin is 30 unlinkable to the original coin. 31 32 > When refreshing a coin, the old coin is obviously marked as spent. 33 > This attack is based on a misunderstanding of refreshing. 34 35 The implementation of Taler in this paper is 36 unclear. For example! , the security level, the RSA modulus, and the elliptic 37 curve etc. are not described. 38 39 > The RSA modulus length is freely configurable, the specific RSA modulus 40 > (n) will change between different denominations. For the experiments 41 > we used RSA 1024, but there keys only live for like a week; for deployments 42 > with a longer lifetime, it likely makes sense to use a larger key size. 43 > The elliptic curves are given and referenced in the paper, namely Ed25519 44 > (used for all signatures) and Curve25519 (ECDHE, in refreshing). 45 46 Moreover, the average time of the withdrawal, spending, refreshing protocols 47 are not provided. The authors also do not compare Taler with other known 48 anonymous payment systems. Thus, the efficiency of Taler is unclear. 49 50 > In our "Experimental Results" section we mention that local processing 51 > of requests happens in the order of a few milliseconds. 52 > Comparing Taler to other e-cash systems experimentally is impossible, 53 > since their implementation is not available. 54 > Comparing Taler to blockchain-based solutions is comparing apples and 55 > oranges, and blockchain-based solutions are many (10^8?) orders of magnitude 56 > slower. 57 58 Additional Comment: The description of the protocols of Taler omits many 59 details. In particular, the authors should describe in detail how the refunds 60 are executed using the refresh protocol, as the authors claim that the refresh 61 protocol allows refunds as a contribution. 62 63 > We added more material on refunds 64 65 Furthermore, the authors should interpret the notation FDHK, and cite the 66 reference for EdDSA. 67 68 > We added FDH_K to the notation list. 69 > We added citations for EdDSA. 70 71 The title of Subsection 3.1 may be misleading, as this 72 subsection does not describe the security model. The authors should rename the 73 title. 74 75 > We changed the title. 76 77 The “We have computed Li…” in Subsection 4.3 should be L(i). 78 79 > Li-typo was fixed. 80 81 82 ----------------------- REVIEW 2 --------------------- 83 TITLE: Refreshing Coins for Giving Change and Refunds in Chaum-style Anonymous Payment Systems 84 85 ----------- Overall evaluation ----------- 86 This paper proposes a new e-cash, named Taler, where the bank (or else called 87 exchange) is online during the spending protocol to allow for double-spending 88 detection. Taler allows for spending coins of various denominations by allowing 89 a user to only spend a value v1<V (where V is the value of the withdrawn coin) 90 and then exchange the remaining value for a new, fresh coin, of value V-v1. The 91 proposed scheme is different compared to Chaum e-cash: in Taler coins are pairs 92 of pk/sk keys where the public key has been signed by the bank/exchange while 93 in typical Chaum e-cash coins are represented by unique serial numbers. 94 95 96 Although the proposed system is hiding some interesting ideas, I think it 97 cannot be accepted for publication at the moment. First and most importantly 98 the current version of the paper lacks any level of analysis (not even 99 informal) of the security level that system achieves. In fact, what security 100 means has not been defined even in an informal lever. Moreover, as I better 101 explain in my specific comments below there seem to be some issues with both 102 security and anonymity (linking different uses of same coin, ensuring coin 103 refreshing happens for the correct value). Finally, the description of the 104 protocols has quite a few inconsistencies (details below): there are parts that 105 seem unnecessary and others that are not properly defined/explained, notation 106 is also very overloaded (there is a 2 page notation table!). 107 108 109 Specific comments: 110 111 - I would expect the “Security Model” section (Section 1.3) to actually explain 112 (even in an informal way) the desired properties of the proposed scheme. 113 These should include double-spending detection security, unforgeability, user 114 anonymity and more importantly the new type of security introduced by coin 115 refresh (this should be a property that guarantees that a user cannot re-fresh 116 a coin for value more than the one that the “dirty” coin is carrying) Instead 117 it just mentions some of the tools used in the proposed scheme (i.e. FDH 118 signatures, cut-and-choose and what kind of security they offer). 119 120 > We added a section with that goes deeper into properties and proofs 121 122 - Related work missing: there has been previous work in “payments with 123 refunds”. Please look at Rupp et al “P4R: Privacy-Preserving Pre-Payments 124 with Refunds for Transportation Systems” where instead of refreshing coins, the 125 unused amount is accumulated in some token that can later be used. How would 126 you compare with that system? 127 128 > We added this to the related work, main problem with this work is that it is 129 > limited to/meant for public transportation systems. For general payments, 130 > their refund can be abused to create transactions that are not 131 > taxable. 132 133 - Found the discussion on Bitcoin too long and unnecessary - the proposed 134 system is not decentralized anyway 135 136 > Correct, but we constantly find people thinking Taler is a crypto-currency, 137 > so for some readers it is important to point out the differences. 138 > We have tried to keep the discussion short. 139 140 - Referencing a system (Goldberg’s HINDE) that is not published makes 141 impossible for the reviewer to check any arguments. 142 143 > In an earlier submission, a reviever insisted that this reference 144 > be added. 145 146 - Section 4.1, step 1: is W_p = w_s * G? Also where is blinding factor b 147 selected from? What does it mean to “commit to disk”? The customer commits 148 and keeps the commitment local? Where is this used? 149 150 > Yes, juxtaposition denotes multiplication. "commit to disk" has been 151 > changed to "persist", the customer must persis the value before making the 152 > bank transaction, so that they don't lose their reserve key should the system 153 > crash. 154 > We added some clarification about to where random values are selected from. 155 156 - Section 4.1, step 3, what is the key K used in FDH? Also is S_w(B) a standard 157 signature? 158 159 > The "K" here means that the domain of the full domain hash is the 160 > modulus of the RSA public key K_v of the key pair K. 161 162 - Section 4.1, step 4, How can the exchange know that this was indeed a new 163 withdrawal request? If a new blinding factor b is used, then a customer can 164 create multiple “freshly” looking requests for the same C_p. (Also a minor 165 point: 2nd line also reads as “if the same withdrawal request was issued before 166 the exchange will send S_K(B)” 167 168 > We added some clarification that the exchange looks up if the request 169 > already exists in their database. 170 171 - Section 4.2, it seems that a customer can use a coin of value say $10 to 172 multiple transactions of <= $10 in total. I.e. it can first a pay a merchant 173 M1 $2 and then a merchant M2 another $5 dollars. In that case the exchange can 174 link those two payments together. Sure, it might not know who is the owner of 175 the coin (i.e. cannot link with withdrawal) but this is still an anonymity 176 problem. 177 178 > Yes, this is why the wallet refreshes a partially spend coin before 179 > reusing it, although a user who did not care about their anonymity 180 > could change that. 181 182 - Section 4.3, doesn’t seem very fair to compare with Zcash or at least it 183 should be highlighted that a quite weaker level of anonymity is achieved. 184 185 > We added remarks on the level of anonymity that Zerocash achieves. 186 > We suspect Zerocash's inherent scaling issues limit its anonymity 187 > for normal purchases, as compared to that a large Taler exchange 188 > provides. We mention that Zerocash is likely to provide better 189 > anonymtiy for large transactions that do not need to be cashed out. 190 191 - Section 4.3, step 1, where is the key t_s^(i) selected from? What does S_{C’} 192 denotes? Is that a commitment (as noted in the text) or a signature (as noted 193 in notation table?). 194 195 > We clarified what t_s^(i) is. 196 > S_{C’} is a signature made with private key C’_p, what we sign 197 > over is the commitment. 198 199 - Section 4.3 In this protocol I would expect the customer to somehow “prove” 200 to the exchange what is the remaining value of the dirty coin. I do not see 201 this happening. How does this part of the protocol ensure that a user cannot 202 just refresh a coin for one of a much bigger value than the remaining one? 203 204 > The exchange records spent coins (with the amount spent) in it's database. 205 > When refreshing a coin, the customer must reveal the coin's (unblinded) 206 > public key to the exchange, which will then set the remaining value 207 > of the coin to zero in it's database. The new coin is now allowed 208 > to exceed the old coin in value. 209 210 211 ----------------------- REVIEW 3 --------------------- 212 PAPER: 46 213 TITLE: Refreshing Coins for Giving Change and Refunds in Chaum-style Anonymous Payment Systems 214 215 ----------- Overall evaluation ----------- 216 The paper introduces a variant's of Chaum's e-cash scheme (with an 217 on-line bank); the main novelty is a "refresh" protocol which enables 218 a user to exchange a coin for a new blinded one. The reason for 219 wanting this features is that it enables refunds from a merchant that 220 later can be refreshed into "clean" coins that are unlinkable to the 221 refunded coins. The protocol is based on what appears to be a standard 222 cut-and-choose approach, which does not appear to be particularly 223 novel. On the positive side, the problem appears a natural and if it 224 hasn't been done before certainly useful. On the negative side, since 225 the paper does not contain any formal definitions, or even semi-formal 226 specifications of the desiderata, it is very hard to understand what 227 actually is achieved. Furthermore, no proofs of security are given, 228 and even the protocol is hard to fully understand. As such, I would 229 suggest the authors to first formalize their approach and 230 resubmitting. 231 232 > We added a section with proofs