diff options
Diffstat (limited to 'comparison')
| -rw-r--r-- | comparison/comparison.tex | 137 |
1 files changed, 108 insertions, 29 deletions
diff --git a/comparison/comparison.tex b/comparison/comparison.tex index e4b1a08..0b8fbcf 100644 --- a/comparison/comparison.tex +++ b/comparison/comparison.tex @@ -2,6 +2,7 @@ \usepackage[utf8]{inputenc} \usepackage{amsmath,amssymb,amsthm} +\usepackage{pifont} \usepackage{url} \usepackage[left=20mm,top=20mm]{geometry} \usepackage{booktabs} @@ -28,44 +29,122 @@ \maketitle -\begin{tabular}{r|ccc} +\newcommand\Y{\ding{51}} % {\checkmark} +\newcommand\N{\ding{55}} + +\begin{tabular}{r|ccccccccccccc} & -\rot{Property 1} & -\rot{Property 2} & -\rot{Property 3} - \\ \hline -System 1 & & & X \\ -System 2 & X & X & X \\ -System 3 & X & & X \\ \hline +\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{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 + \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{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''). + \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} |