summaryrefslogtreecommitdiff log msg author committer range
path: root/doc/paper/taler_FC2017.txt
blob: 66f8560ad80b8d2faaccf5c0bdc3951d89623837 (plain)
 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232  ----------------------- 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 spent. > 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 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. > We added some clarification about to where random values are selected from. - 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 RSA 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 wallet refreshes a partially spend coin before > reusing it, although a user who did not care about their anonymity > could change that. - 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 remarks on the level of anonymity that Zerocash achieves. > We suspect Zerocash's inherent scaling issues limit its anonymity > for normal purchases, as compaired to that a large Taler exchange > provides. We mention that Zerocash is likely to provide better > anonymtiy for large transactions that do not need to be cashed out. - 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 clarified what t_s^(i) is. > 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