Merge branch 'master' of ssh://taler.net/exchange
I need to refine the text for real after this sloppy merge
This commit is contained in:
commit
88d633526d
@ -20,25 +20,6 @@
|
||||
% CG adds:
|
||||
% We SHOULD do this for the FINAL paper, not for the anon submission.
|
||||
|
||||
\documentclass{llncs}
|
||||
%\usepackage[margin=1in,a4paper]{geometry}
|
||||
\usepackage[T1]{fontenc}
|
||||
\usepackage{palatino}
|
||||
\usepackage{xspace}
|
||||
\usepackage{microtype}
|
||||
\usepackage{amsmath,amssymb,eurosym}
|
||||
\usepackage[dvipsnames]{xcolor}
|
||||
\usepackage{tikz}
|
||||
\usetikzlibrary{shapes,arrows}
|
||||
\usetikzlibrary{positioning}
|
||||
\usetikzlibrary{calc}
|
||||
% \usepackage{enumitem}
|
||||
\usepackage{caption}
|
||||
%\usepackage{subcaption}
|
||||
\usepackage{subfig}
|
||||
% \usepackage{sidecap}
|
||||
% \usepackage{wrapfig}
|
||||
|
||||
% Relate to:
|
||||
% http://fc14.ifca.ai/papers/fc14_submission_124.pdf
|
||||
|
||||
@ -63,23 +44,70 @@
|
||||
% - transaction = coin ownership transfer that should be taxed
|
||||
% - sharing = coin copying that should not be taxed
|
||||
|
||||
|
||||
\title{Refreshing Coins for Giving Change and Refunds \\ in Chaum-style Anonymous Payment Systems}
|
||||
|
||||
\begin{document}
|
||||
\mainmatter
|
||||
|
||||
%\author{Florian Dold \and Sree Harsha Totakura \and Benedikt M\"uller \and Jeff Burdges \and Christian Grothoff}
|
||||
%\institute{The GNUnet Project}
|
||||
|
||||
|
||||
\maketitle
|
||||
|
||||
% FIXME: As a general comment, I think we're mixing the crypto stuff and the systems
|
||||
% stuff too much. It might be more appropriate to have to systems stuff in a separate
|
||||
% section, and the "pure" crypto stuff for the crypto people?
|
||||
|
||||
|
||||
\documentclass[sigconf, authordraft]{acmart}
|
||||
|
||||
\usepackage{booktabs} % For formal tables
|
||||
\usepackage{tikz}
|
||||
\usetikzlibrary{shapes,arrows}
|
||||
\usetikzlibrary{positioning}
|
||||
\usetikzlibrary{calc}
|
||||
\usepackage{eurosym}
|
||||
|
||||
|
||||
% Copyright
|
||||
%\setcopyright{none}
|
||||
%\setcopyright{acmcopyright}
|
||||
%\setcopyright{acmlicensed}
|
||||
\setcopyright{rightsretained}
|
||||
%\setcopyright{usgov}
|
||||
%\setcopyright{usgovmixed}
|
||||
%\setcopyright{cagov}
|
||||
%\setcopyright{cagovmixed}
|
||||
|
||||
|
||||
% DOI
|
||||
\acmDOI{10.475/123_4}
|
||||
|
||||
% ISBN
|
||||
\acmISBN{123-4567-24-567/08/06}
|
||||
|
||||
%Conference
|
||||
\acmConference[WOODSTOCK'97]{ACM Woodstock conference}{July 1997}{El
|
||||
Paso, Texas USA}
|
||||
\acmYear{1997}
|
||||
\copyrightyear{2016}
|
||||
|
||||
\acmPrice{15.00}
|
||||
|
||||
\acmSubmissionID{123-A12-B3}
|
||||
|
||||
\begin{document}
|
||||
\title{Refreshing Coins for Giving Change and Refunds \\ in Chaum-style Anonymous Payment Systems}
|
||||
\subtitle{Authors' names blinded for review}
|
||||
|
||||
|
||||
%\author{Ben Trovato}
|
||||
%\authornote{Dr.~Trovato insisted his name be first.}
|
||||
%\orcid{1234-5678-9012}
|
||||
%\affiliation{%
|
||||
% \institution{Institute for Clarity in Documentation}
|
||||
% \streetaddress{P.O. Box 1212}
|
||||
% \city{Dublin}
|
||||
% \state{Ohio}
|
||||
% \postcode{43017-6221}
|
||||
%}
|
||||
%\email{trovato@corporation.com}
|
||||
|
||||
|
||||
% The default list of authors is too long for headers}
|
||||
%\renewcommand{\shortauthors}{B. Trovato et al.}
|
||||
|
||||
|
||||
\begin{abstract}
|
||||
This paper introduces {\em Taler}, a Chaum-style digital payment system that
|
||||
enables anonymous payments while ensuring that entities that receive
|
||||
@ -106,6 +134,46 @@ and adequately balances the state's need for monetary control with the
|
||||
citizen's needs for private economic activity.
|
||||
\end{abstract}
|
||||
|
||||
%
|
||||
% The code below should be generated by the tool at
|
||||
% http://dl.acm.org/ccs.cfm
|
||||
% Please copy and paste the code instead of the example below.
|
||||
%
|
||||
\begin{CCSXML}
|
||||
<ccs2012>
|
||||
<concept>
|
||||
<concept_id>10010520.10010553.10010562</concept_id>
|
||||
<concept_desc>Computer systems organization~Embedded systems</concept_desc>
|
||||
<concept_significance>500</concept_significance>
|
||||
</concept>
|
||||
<concept>
|
||||
<concept_id>10010520.10010575.10010755</concept_id>
|
||||
<concept_desc>Computer systems organization~Redundancy</concept_desc>
|
||||
<concept_significance>300</concept_significance>
|
||||
</concept>
|
||||
<concept>
|
||||
<concept_id>10010520.10010553.10010554</concept_id>
|
||||
<concept_desc>Computer systems organization~Robotics</concept_desc>
|
||||
<concept_significance>100</concept_significance>
|
||||
</concept>
|
||||
<concept>
|
||||
<concept_id>10003033.10003083.10003095</concept_id>
|
||||
<concept_desc>Networks~Network reliability</concept_desc>
|
||||
<concept_significance>100</concept_significance>
|
||||
</concept>
|
||||
</ccs2012>
|
||||
\end{CCSXML}
|
||||
|
||||
\ccsdesc[500]{Computer systems organization~Embedded systems}
|
||||
\ccsdesc[300]{Computer systems organization~Redundancy}
|
||||
\ccsdesc{Computer systems organization~Robotics}
|
||||
\ccsdesc[100]{Networks~Network reliability}
|
||||
|
||||
|
||||
\keywords{ACM proceedings, \LaTeX, text tagging}
|
||||
|
||||
\maketitle
|
||||
|
||||
\section{Introduction}
|
||||
|
||||
The design of payment systems shapes economies and societies. Strong,
|
||||
@ -151,7 +219,7 @@ provides fair exchange and exculpability via cryptographic proofs.
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\begin{tikzpicture}
|
||||
\tikzstyle{def} = [node distance= 1em and 11em, inner sep=1em, outer sep=.3em];
|
||||
\tikzstyle{def} = [node distance= 2em and 6.5em, inner sep=1em, outer sep=.3em];
|
||||
\node (origin) at (0,0) {};
|
||||
\node (exchange) [def,above=of origin,draw]{Exchange};
|
||||
\node (customer) [def, draw, below left=of origin] {Customer};
|
||||
@ -193,6 +261,7 @@ which owned the original coin.
|
||||
|
||||
|
||||
%\vspace{-0.3cm}
|
||||
|
||||
\section{Related Work}
|
||||
%\vspace{-0.3cm}
|
||||
|
||||
@ -1284,8 +1353,10 @@ We thank people (anonymized).
|
||||
%Jacob Appelbaum for productive discussions and support.
|
||||
\newpage
|
||||
|
||||
\bibliographystyle{alpha}
|
||||
\bibliography{taler,rfc,ro}
|
||||
\bibliographystyle{ACM-Reference-Format}
|
||||
\bibliography{taler,ro} % rfc
|
||||
|
||||
\end{document} %TODO: What?!?
|
||||
|
||||
%\vfill
|
||||
%\begin{center}
|
||||
@ -1491,14 +1562,20 @@ any adversary with an advantage for linking Taler coins gives
|
||||
rise to an adversary with an advantage for recognizing SHA512 output.
|
||||
\end{corollary}
|
||||
|
||||
There was an earlier encryption-based version of the Taler protocol
|
||||
in which refresh operated consisted of $\kappa$ normal coin withdrawals
|
||||
encrypted using the secret $t^{(i)} C$ where $C = c G$ is the coin being
|
||||
refreshed and $T^{(i)} = t^{(i)} G$ is the transfer key.
|
||||
We will now consider the impact of the refresh operation. For the
|
||||
sake of the argument, we will first consider an earlier
|
||||
encryption-based version of the protocol in which refresh operated
|
||||
consisted of $\kappa$ normal coin withdrawals where the commitment
|
||||
consisted of the blinding factors and private keys of the fresh coins
|
||||
encrypted using the secret $t^{(i)} C_s$ where $C_s = c_s G$ of the
|
||||
dirty coin $C$ being refreshed and $T^{(i)} = t^{(i)} G$ is the
|
||||
transfer key.\footnote{We abandoned that version as it required
|
||||
slightly more storage space and the additional encryption
|
||||
primitive.}
|
||||
|
||||
\begin{proposition}
|
||||
Assuming the encryption used is semantically (IND-CPA) secure, and
|
||||
that the independence of $c$, $t$, and the new coins key materials,
|
||||
that the independence of $c_s$, $t$, and the new coins' key materials,
|
||||
then any probabilistic polynomial time (PPT) adversary with an
|
||||
advantage for linking Taler coins gives rise to an adversary with
|
||||
an advantage for recognizing SHA512 output.
|
||||
@ -1515,15 +1592,15 @@ this coin and report the exchange's fraudulent activity.
|
||||
|
||||
% TODO: Is independence here too strong?
|
||||
|
||||
We may now remove the encrpytion by appealing to the random oracle model
|
||||
\cite{BR-RandomOracles}.
|
||||
We may now remove the encrpytion by appealing to the random oracle
|
||||
model~\cite{BR-RandomOracles}.
|
||||
|
||||
\begin{lemma}[\cite{??}]
|
||||
Consider a protocol that commits to random data by encrypting it
|
||||
using a secret derived from a Diffe-Hellman key exchange.
|
||||
In the random oracle model, we may replace this encryption with
|
||||
a hash function derives the random data by applying hash functions
|
||||
to the same secret.
|
||||
a hash function which derives the random data by applying hash
|
||||
functions to the same secret.
|
||||
\end{lemma}
|
||||
% TODO: IND-CPA again? Anything else?
|
||||
|
||||
@ -1551,7 +1628,13 @@ Diffie-Hellman key exchange on Curve25519.
|
||||
We do not distinguish between information known by the exchange and
|
||||
information known by the merchant in the above. As a result, this
|
||||
proves that out linking protocol \S\ref{subsec:linking} does not
|
||||
degrade privacy.
|
||||
degrade privacy. We note that the exchange could lie in the linking
|
||||
protocol about the transfer public key to generate coins that it can
|
||||
link (at a financial loss to the exchange that it would have to square
|
||||
with its auditor). However, in the normal course of payments the link
|
||||
protocol is never used. Furthermore, if a customer needs to recover
|
||||
control over a coin using the linking protocol, they can use the
|
||||
refresh protocol on the result to again obtain an unlinkable coin.
|
||||
|
||||
|
||||
|
||||
@ -1873,3 +1956,4 @@ provides a payment system with the following key properties:
|
||||
The payment system handles both small and large payments in
|
||||
an efficient and reliable manner.
|
||||
\end{description}
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user