blob: e4b1a08c29ca3406f97df676ef509be825b91741 (
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
|
\documentclass[a4paper]{scrartcl}
\usepackage[utf8]{inputenc}
\usepackage{amsmath,amssymb,amsthm}
\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
\begin{tabular}{r|ccc}
&
\rot{Property 1} &
\rot{Property 2} &
\rot{Property 3}
\\ \hline
System 1 & & & X \\
System 2 & X & X & X \\
System 3 & X & & X \\ \hline
\end{tabular}
\section{Criteria}
\begin{itemize}
\item \textbf{Cryptographic Assumptions.} This needs to be included
and needs to contain more than just ROM because some schemes advertise that
they don't need ROM but rely on some other rather strong assumptions.
\item \textbf{Refunds.}
\item \textbf{Offline Spending.} Causes brittleness, not a goal.
\item \textbf{Exculpability When Restoring From Backup}. Usually conflicts with offline double spending detection.
\item \textbf{Traceability.} Means that (a threshold of) authorities can deanonymize a customer
if required (e.g. to catch a criminal).
\item \textbf{Transferability.}. Ability to transfer a coin from one user to another. None/Sharing/Transfer.
\item \textbf{Taxability / Income Transparency.} E-Cash can't be reliably transferred
without the transaction being recorded at the exchange.
\item \textbf{Time/Storage for Withdrawal.} What data the wallet need to store / send / receive.
\item \textbf{Time/Storage for Deposit.} Often not considered, especially
in ``constant time'' schemes.
\item \textbf{Divisibility/Change.}. Also: Which mechanism is used for divisibility. None/offline/online.
\item \textbf{Robustness Under Failures}.
\item \textbf{Robust Receipts for Spending.} The customer either can prove that they payed for
a contract, or they can get their (unlinkable) money back.
\item \textbf{Provably Secure (?).}
\item \textbf{Endorsed.} Separation of the coin and permission to spend
it, see \cite{camenisch2007endorsed}. Allows fair exchange (?).
\item \textbf{Key Expiration.} How/when do keys expire. How do users exchange
old coins for new coins?
\item \textbf{Relience on hardware security modules.} (E.g. ``Untraceable Off-line Cash in Wallet with Observers'').
\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}
|
