aboutsummaryrefslogtreecommitdiff
path: root/doc/paper
diff options
context:
space:
mode:
authorJeffrey Burdges <burdges@gnunet.org>2017-05-16 14:03:41 +0200
committerJeffrey Burdges <burdges@gnunet.org>2017-05-16 14:03:41 +0200
commit88d633526d704c4ab9193cb23e01a41f0225e1ba (patch)
treebb6fb562e0ecf42ef9cc10a3ba9427ab27b10781 /doc/paper
parent468a373df46eea54d024ac4c1bd0bebf548e2d0c (diff)
parent7ce67006be0f4ca8e26e1e35d5751cbc4af40cb9 (diff)
Merge branch 'master' of ssh://taler.net/exchange
I need to refine the text for real after this sloppy merge
Diffstat (limited to 'doc/paper')
-rw-r--r--doc/paper/taler.tex164
1 files changed, 124 insertions, 40 deletions
diff --git a/doc/paper/taler.tex b/doc/paper/taler.tex
index 1a695e12e..607390e24 100644
--- a/doc/paper/taler.tex
+++ b/doc/paper/taler.tex
@@ -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,21 +44,68 @@
% - transaction = coin ownership transfer that should be taxed
% - sharing = coin copying that should not be taxed
+% 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}
-\title{Refreshing Coins for Giving Change and Refunds \\ in Chaum-style Anonymous Payment Systems}
+
+% 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}
-\mainmatter
+\title{Refreshing Coins for Giving Change and Refunds \\ in Chaum-style Anonymous Payment Systems}
+\subtitle{Authors' names blinded for review}
-%\author{Florian Dold \and Sree Harsha Totakura \and Benedikt M\"uller \and Jeff Burdges \and Christian Grothoff}
-%\institute{The GNUnet Project}
+%\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}
-\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?
+% The default list of authors is too long for headers}
+%\renewcommand{\shortauthors}{B. Trovato et al.}
\begin{abstract}
@@ -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}
+