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
|
\documentclass[a4paper]{scrartcl}
\usepackage[utf8]{inputenc}
\usepackage{amsmath,amssymb,amsthm}
\usepackage{pifont}
\usepackage{url}
\usepackage[left=20mm,top=20mm]{geometry}
\usepackage{booktabs}
\usepackage{hyperref}
\usepackage{subcaption}
\usepackage{mathpazo}
\usepackage{adjustbox}
\usepackage{array}
\newcolumntype{R}[2]{%
>{\adjustbox{angle=#1,lap=\width-(#2)}\bgroup}%
l%
<{\egroup}%
}
\newcommand*\rot{\multicolumn{1}{R{45}{1em}}}% no optional argument here, please!
\title{E-Cash Comparison}
\date{\today}
\begin{document}
\maketitle
\newcommand\Y{\ding{51}} % {\checkmark}
\newcommand\N{\ding{55}}
\begin{tabular}{r|ccccccccccccc}
&
\rot{Instant enforcement} &
\rot{Robust anonymity} &
\rot{Key expiration} &
%
\rot{Traceability} &
\rot{Transferability} &
\rot{Taxability} &
%
\rot{Withdrawal cost} &
\rot{Deposit cost} &
\rot{Change} &
%
\rot{Robust anonymity} &
\rot{Receipts} &
\rot{Endorsed} &
\rot{Refunds}
\\ \hline
Taler
& \Y & \Y & \Y
& \N & S & \Y
& $\log n$ & $\log n$ & ON
& \Y & \Y & \Y & Anon
\\
% TODO: Just omit this straw-man online Chaum in favor on HINDE
Chaum Online
& \Y & ? & \Y?
& \N & S & \N
& $\log n$ & $\log n$ & ON
& \Y? & \N & \N & ?
\\
HINDE
& \Y? & \Y & \Y?
& \N & S & \N
& $\log n$ & $\log n$ & ON
& \Y? & \N? & \N? & ?
\\
Chaum Offline
& \N & ? & \Y?
& \N & S & \N?
& $\log n$ & $\log n$ & ON
& \Y? & \N? & \N? & ?
\\ \hline
\end{tabular}
\section{Criteria}
\begin{itemize}
\item \textbf{Key expiration.}
How/when do keys expire.
How do users exchange old coins for new coins?
\item \textbf{Instant enforcement.}
In the past, payment schemes needed to function even when neither
party had connectivity, which makes double spending unavoidable.
To address this, anonymous payment schemes were designed to
deanonymize the customer who double spent, but this approach makes
anonymity extremely brittle and requires expensive debt collection
operations.
\item \textbf{Robust anonymity.}
Anonymity is not trivially compromised by wallet spending errors,
including restoring from backups and certain targeted attacks.
Required for good operational security.
Inherently conflicts with offline double spending detection.
% Exculpability under ...
\item \textbf{Traceability.}
A threshold of authorities can deanonymize a customer. % if required (e.g. to catch a criminal).
Also makes anonymity brittle.
% TODO: Should this be Untraceability?
\item \textbf{Transferability.}
Ability to transfer a coin from one user to another.
None/Sharing/Transfer.
\item \textbf{Taxability.}
Is income transparent to the exchange? Do reliable transfers
among distrusting parties require that the exchange record the
transaction.
% TODO: Expand definition and cite the successor papers to Zerocash/BOLT
% that handle regulation?
\item \textbf{Withdrawal cost.}
Asymptotic time and storage costs for the wallet during and after withdrawal.
Also frequently bandwidth costs for the withdrawal operation. %TODO: Details?
FIXME: Do we have a rigorous definition for this? Literature
only uses big-O for batched withdrawal/deposit.
\item \textbf{Deposit costs.}
Asymptotic time and storage costs for the exchange's double spending
protections required during deposit.
Frequently ignored, especially in ``constant time'' schemes.
FIXME: Do we have a rigorous definition for this? Literature
only uses big-O for batched withdrawal/deposit.
\item \textbf{Change/Divisibility.}
Which mechanism is used for divisibility? (None/OFFline/ONline).
\item \textbf{Robustness under network failures.}
Protocol aborts, including network failures, cannot compromise any party's
financial security or the customer's anonymity.
\item \textbf{Receipts for spending.}
The customer either can prove that they payed for
a contract, or they can get their (unlinkable) money back.
\item \textbf{Endorsed.} Separation of the coin and permission to spend
it, see \cite{camenisch2007endorsed}. Allows fair exchange (?).
\item \textbf{Refunds.} Anonymous/Deanonymizing/Payment/None/Unspecified
\item \textbf{Anonymity Without Trusted Setup / ``Trustless anonymity``.} A trusted stup is be problematic;
while the exchange is fixed, the customers/merchant are not, so
distributed key generation isn't always an option. It makes it hard to instantiate the scheme
and hard to trust the deployed scheme.
\item \textbf{Realistic Exchange Storage Requirements.}
In schemes that have divisibility, the exchange still needs to
store the smallest denomination. Unless the scheme also has multiple denominations,
this storage requirements are unrealistic.
\item \textbf{Cryptographic Batching.} Some schemes allow
withdrawing a wallet with $2^\ell$ coins in $O(1)$ with
$O(1)$ storage and $O(1)$ batch spending.
\end{itemize}
These are discussion items that do not necessarily need to appear in the table.
\begin{itemize}
\item \textbf{Security proofs}. % {Cryptographic assumptions.}
Do some security proofs require the random oracle model (ROM)?
At present, any schemes with security proofs in the standard model
do still require strong assumptions for pairing-based cryptography
(I/II/III). % so give the pairing type required.
% Notes: Taler uses ROM for the mint's security in the proof of security
% for FDH against one-more forgery attacks, but this could be removed by
% adapting it to some standard model blind signature scheme. We expect
% Taler also uses ROM for the user's anonymity in the proof of security
% around the FD-PRF in the refresh protocol.
\item \textbf{Software.}
Can the scheme be implemented purely in software?
Some schemes require hardware security modules, including
``Untraceable Off-line Cash in Wallet with Observers''. % replace with \cite{}
\end{itemize}
\section{Misc.}
\textbf{Blind signatures under aborts.} The idea here is that the customer could abort before the exchange
credits the account/reserve. Before aborting, the customer obtains some intermediate values from the exchange, which they
could re-combine into a valid signature when repeating this many times. This is especially relevent since there's a proof
that in the Standard Model, blind signature schemes need to have $>3$ moves.
\section{Literature Survey}
\bibliography{literature}
\bibliographystyle{alpha}
\end{document}
|
