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
|
\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{Offline spending} &
\rot{Robust anonymity} &
\rot{Key Expiration} &
%
\rot{Traceability} &
\rot{Transferability} &
\rot{Taxability} &
%
\rot{Withdrawal cost} &
\rot{Deposit cost} &
\rot{Change} &
%
\rot{Robustness} &
\rot{Receipts} &
\rot{Endorsed} &
\rot{Refunds}
\\ \hline
Taler
& \N & \Y & \Y
& \N & S & \Y
& $\log n$ & $\log n$ & ON
& \Y & \Y & \Y & \Y
\\
% TODO: Just omit this straw-man online Chaum in favor on HINDE
Chaum Online
& \N & ? & \Y?
& \N & S & \N
& $\log n$ & $\log n$ & ON
& \Y? & \N & \N & \N
\\
HINDE
& \N & \Y & \Y?
& \N & S & \N?
& $\log n$ & $\log n$ & ON
& \Y? & \N? & \N? & \N
\\
Chaum Offline
& \Y & ? & \Y?
& \N & S & \N?
& $\log n$ & $\log n$ & ON
& \Y? & \N? & \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{Offline spending.}
Important historical property from when transactions were commonly
processed offline, possibly still useful in some situations.
Inherently makes anonymity brittle, so no longer a wise goal.
\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?
\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.
\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
\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.
\bibliography{literature}
\bibliographystyle{alpha}
\end{document}
|
