summaryrefslogtreecommitdiff
path: root/taler-fc19/reviewsfc19.txt
blob: be142c7d6fa3c26e68713fd1515987cf404e3015 (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

Subject:
[FC19] Paper #166 "Robust and Income-transparent Online..."
From:
<hotcrp@submit19.ifca.ai>
Date:
11/14/18, 2:45 PM
To:
Christian Grothoff <christian.grothoff@bfh.ch>

Dear Christian Grothoff,

We are sorry to notify you that your paper #166, Robust and
Income-transparent Online E-Cash, has not been accepted to the Financial
Cryptography and Data Security 2019 conference.  The reviews for your paper
are appended below.

We received a record number of submissions this year (178), of which we
accepted 33 regular papers and 7 short papers.

You may wish to submit your paper to one of the associated workshops. As
none of the workshops' submission deadlines have yet passed, we are leaving
it up to the authors to decide whether to resubmit, rather than moving
rejected papers automatically.

Thanks for submitting to the conference, and we hope you will nonetheless
attend the event.

   - Ian and Tyler

Review #166A
===========================================================================

Overall merit
-------------
3. Weak accept

Reviewer expertise
------------------
3. Knowledgeable

Paper summary
-------------
This paper describes an "online" e-cash protocol that provides the following properties:
- a "recoverability" property that allows a user to recover coins from backups if a wallet is lost
- a "change protocol" that allows partially-spent coins to be renewed for smaller denominations
- and a probabilistic "auditability" property that allows a user to reveal the source of coins in their wallet
The paper spends a great deal of time giving game-based definitions for these properties, then gives a "generic" protocol that meets these goals when instantiated with discrete-log based primitives (the security proofs and instantiations are given in the appendix.)  Overall, the paper seems correct, but does not really make a compelling case for the change and auditing properties.

Comments for author
-------------------
The paper is written in a way that makes it quite difficult to read: Since it is clear that you have a specific instantiation of most of the primitives in mind, I think just describing the protocol, and giving a UC-style functionality, rather than spending 4 pages on syntax/types, and 3 pages on oracles, and another 2 pages on notation for things that will be instantiated by standard DH/DLog primitives, would make the paper much more approachable for readers and reviewers.


* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *


Review #166B
===========================================================================

Overall merit
-------------
3. Weak accept

Reviewer expertise
------------------
2. Some familiarity

Paper summary
-------------
The paper presents a new e-cash protocol that involves exchanges, customers and merchants. Briefly, the customer can have a coin minted from the exchange (i.e. blind-signature) and spend it with a merchant. The coins appear to be dividable too (and anything that is "too small" is considered a fee to exchange). The paper mostly focuses on defining the security goals anonymity, conservation, unforgeability, and income transparency. It provides games on how the properties can be achieved, they instantiate the protocol and provide a proof that the instantiation satisfies these goals.

Comments for author
-------------------
The paper is well-written and easy to read. It appears to be more of a theoretical paper as it outlines both the security game + the instantiated protocol, but there is no implementation or assessment of its efficiency. i.e. how well does the protocol work and how can it be compared with the related works? 

I feel the paper doesn't really present a good case why income-transparency is a desirable goal. There are some really good ethical questions that could be explored (i.e. should people have financial privacy? is there something desirable? how does it impact the power structures in society?).


* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *


Review #166C
===========================================================================

Overall merit
-------------
2. Weak reject

Reviewer expertise
------------------
3. Knowledgeable

Paper summary
-------------
The authors propose conservation as a new security property for e-cash schemes. Conservation ensures that aborted withdraws and spends do not deprive the user of money.

Comments for author
-------------------
The paper is heavy on syntax, with no intuition, exposition, or relation to existing work. The actual construction is not until page 11!.   The majority of this is not part of the claimed contribution of the paper, but the details required to flesh out a full fledged scheme. You were allowed unlimited appendices. Please use them.

The lack of discussion and comparison to related work makes it particularly challenging to evaluate the work. Conservation seems like a property that would be implied by most ideal functionality/UC defined schemes.  These are rarer than game based schemes, but not non-existent. In light of those, is the property actually novel?  (see e.g. the first result for universal Composable E-cash https://eprint.iacr.org/2005/341.pdf) 

Beyond that, is the property challenging to achieve? Take CHL06 Compact E-cash, which operates in the harder offline setting and uses the signed PRF as wallet/token dispenser where coins are generated as the output of a prf with the key signed by the bank. It seems that this scheme or on substantially similar  achieves conservation.  The user obtains their wallet (the signed PRF seed) only in the last step of an interactive withdraw protocol. Upon completting that set. the bank where debits the account. The user can always ask the exchange to repeated this step (on the same prf seed).


Similarly, for that tax protocol. How does this compare to e.g. GNU Taller?
 
Do the authors believe there is anything novel about the e-cash scheme they propose or is the novelty in defining the property appropriately? It seems the answer is just the property.