From 6e495fcb3f7af146d72fc436bc986ede590884fa Mon Sep 17 00:00:00 2001 From: Florian Dold Date: Mon, 29 Oct 2018 10:54:09 +0100 Subject: ref fixes --- taler/design.tex | 20 ++++++++++---------- taler/implementation.tex | 13 +++++++------ taler/security.tex | 28 ++++++++++++++-------------- 3 files changed, 31 insertions(+), 30 deletions(-) (limited to 'taler') diff --git a/taler/design.tex b/taler/design.tex index f583757..712cdd0 100644 --- a/taler/design.tex +++ b/taler/design.tex @@ -18,9 +18,8 @@ payments is discussed in Chapter~\ref{chapter:implementation}. GNU Taler is based on the idea of Chaumian e-cash, with some differences and additions explained in the following sections. Other variants and extensions -of e-cash are discussed in Section~\ref{section:related-work:ecash}, and -different blind signature algorithms are discussed in -Section~\ref{section:related-work:blind-signatures}. +of e-cash and blind signatures are discussed in +Section~\ref{sec:related-work:e-cash}. \subsection{Entities and Trust Model} @@ -80,8 +79,9 @@ parties. \subsection{System Assumptions} +% FIXME: Tor might not be strong enough, so it's not really an example! We assume that an anonymous bi-directional communication channel such as -Tor~\cite{tor-design} is used for all communication between the customer and +Tor~\cite{dingledine2004tor} is used for all communication between the customer and the merchant, as well as for obtaining unlinkable change for partially spent coins from the exchange and for retrieving the exchange's denomination keys. @@ -164,7 +164,7 @@ pre-filled bank account details of the exchange as well as the reserve public key. The customer clicks on this link or scans the QR code to invoke their banking app with pre-filled transaction details. Since there currently is no standardized format for pre-filled wire transfer details, we are proposing the -\texttt{payto://} URI format explained in section \ref{sec:payto}, currently +\texttt{payto://} URI format explained in section \ref{appendix:payto}, currently under review for acceptance as an IETF Internet Standard. @@ -189,7 +189,7 @@ once more coins are redeemed than the total that was signed into existence using that denomination key. In this case, the exchange can allow authentic customers to redeem their unspent coins that were signed with the compromised private key, while refusing further deposits involving coins signed by the -compromised denomination key (see Section~\ref{sec:payback}). As a result, the +compromised denomination key (see Section~\ref{sec:revocation-payback}). As a result, the financial damage of losing a private signing key is limited to at most the amount originally signed with that key, and denomination key rotation can be used to bound that risk. @@ -238,7 +238,7 @@ withdraw the refreshed coins makes them unlinkable from the old coin. % FIXME: talk about logarithmic time, simulation -\subsection{Refreshing and Taxability}\cite{sec:design-refresh} +\subsection{Refreshing and Taxability}\label{sec:design-refresh} % FIXME: maybe put section on how to avoid withdraw loophole here! One goal of Taler is to make merchants' income transparent to state auditors, so that income can be taxed appropriately. Naively implemented, however, a simple @@ -330,7 +330,7 @@ merchant, effectively hiding the fees from the customer. % FIXME: explain wire fee amortization -\subsection{The Withdraw Loophole and Tipping} +\subsection{The Withdraw Loophole and Tipping}\label{taler:design:tipping} The withdraw protocol can be (ab)used to illicitly transfer money, when the receiver generates the coin's secret key, and gives the public key to the party executing the withdraw protocol. We call this the ``withdraw loophole''. This @@ -344,7 +344,7 @@ agreement. % FIXME: argue that this can't be done on scale for money laundering -\subsubsection{Fixing the Withdraw Loophole} +\subsubsection{Fixing the Withdraw Loophole}\label{taler:design:fixing-withdraw-loophole} In order to discourage the usage of the withdraw loophole for untaxed payments, the following approach would be possible: Normal withdraw operations and @@ -541,7 +541,7 @@ to export evidence and upholds the core principles described in~\cite{fc2014murdoch}. In particular, in providing the cryptographic proofs as evidence none of the participants have to disclose their core secrets. -\subsection{Perfect Crime Scenarios} +\subsection{Perfect Crime Scenarios}\label{sec:design:blackmailing} The key revokation and emergency payback mechanism described in Section \ref{sec:revocation-payback} can also be used against criminals in perfect crime / kidnapping scenarios where the adversary demands to be paid a ransom in diff --git a/taler/implementation.tex b/taler/implementation.tex index f9221ca..e1cd6b0 100644 --- a/taler/implementation.tex +++ b/taler/implementation.tex @@ -709,7 +709,7 @@ URL. A HTTP GET on that URL will return a list of refund confirmations that the merchant received from the exchange. \subsection{Tipping} -Tipping in Taler uses the ``withdraw loophole'' (see \ref{XXX}) to allow the +Tipping in Taler uses the ``withdraw loophole'' (see \ref{taler:design:tipping}) to allow the merchant\footnote{We still use the term ``merchant'', since donations use the same software component as the merchant, but ``donor'' would be more accurate.} to donate small amounts (without any associated contract terms or legal obligations) into the user's wallet. @@ -773,7 +773,7 @@ syntax makes parsing of \texttt{payto} URIs trivial with existing parsers. Formally, a \texttt{payto} URI is an encoding of a partially filled out pro forma invoice. The full specification (in the form of an IETF draft currently -at the time of writing) of the \texttt{payto} URI is in Appendix \ref{XXX}. +at the time of writing) of the \texttt{payto} URI is in Appendix~\ref{appendix:payto}. In the implementation of Taler, \texttt{payto} URIs are used in various places: \begin{enumerate} @@ -897,6 +897,7 @@ certifies these keys with the \texttt{taler-auditor-sign} tool. \begin{figure} \includegraphics[width=\textwidth]{diagrams/taler-diagram-keyup.png} \caption{Dataflow for updating the exchange's keys.} + \label{figure:keyup} \end{figure} This process is illustrated in Figure~\ref{figure:keyup}. @@ -1190,7 +1191,7 @@ Instead, an overlay or separate tab/window displays the prompt to the user. In this section, we describe the main cryptographic protocols for Taler in more detail. Effectively this corresponds to a concrete instantiation of the -protocols in Section \ref{sec:abstract-instantiation}. +protocols in Section \ref{sec:crypto:instantiation}. For ease of presentation, we do not provide a bit-level description of the cryptographic protocol. Some details from the implementation are left out, @@ -1606,12 +1607,12 @@ to provide service many merchants and all of their customers. Thus the exchange is the bottleneck for the performance of the system. We provide a microbenchmark for the performance of cryptographic operations in -the wallet (Table~\ref{table:wallet-benchmark)}. Even on a low-end smartphone +the wallet (Table~\ref{table:wallet-benchmark}. Even on a low-end smartphone devices, the most expensive cryptographic operations remains well under $150ms$, a threshold for user-interface latency under which user happyiness and productivity is considered to be unaffected \cite{tolia2006quantifying}. -\begin{table}\label{table:wallet-benchmark} +\begin{table} \centering \begin{subtable}[t]{0.4\linewidth} \centering{ @@ -1783,7 +1784,7 @@ hash context finish & 0.28 & 1215 & 1227 \\ \bottomrule \end{tabular} \caption{Cryptographic operations in the benchmark with one client and $10000$ operations.} - \label{table:baseline-benchmark} + \label{table:benchmark:ops-baseline} \end{table} diff --git a/taler/security.tex b/taler/security.tex index ee4ca0d..051eca0 100644 --- a/taler/security.tex +++ b/taler/security.tex @@ -1651,13 +1651,13 @@ In particular, the following features are left out of the formal discussion: exchange to know (or learn from the customer) the exact amount to be payed for the contract. - A complication in practice is that merchants may not want to reveal their - full bank account information to the customer, but this information is - necessary for the exchange to process the deposit, since we do not require - merchants to register beforehand the exchange (as the merchant might - support all exchanges audited by a specific auditor). We discuss a protocol - extension that allows customers to deposit coins on behalf of merchants - in~\ref{XXX}. + %A complication in practice is that merchants may not want to reveal their + %full bank account information to the customer, but this information is + %necessary for the exchange to process the deposit, since we do not require + %merchants to register beforehand the exchange (as the merchant might + %support all exchanges audited by a specific auditor). We discuss a protocol + %extension that allows customers to deposit coins on behalf of merchants + %in~\ref{XXX}. \item The fees incurred for operations, the protocols for backup and synchronization as well as other possible extensions like tick payments are @@ -1666,12 +1666,12 @@ In particular, the following features are left out of the formal discussion: %\item FIXME: auditor \end{itemize} -We note that customer tipping (see \ref{XXX}) basically amounts to an execution +We note that customer tipping (see \ref{taler:design:tipping}) basically amounts to an execution of the \algo{Withdraw} protocol where the party that generates the coin keys and blinding factors (in that case the merchant's customer) is different from the party that signs the withdraw request (the merchant with a ``customer'' key pair tied to the merchant's bank account). While this is desirable in some -cases, we discussed in \ref{XXX} how this ``loophole'' for a one-hop untaxed +cases, we discussed in \ref{taler:design:fixing-withdraw-loophole} how this ``loophole'' for a one-hop untaxed payment could be avoided. \subsection{Other Properties} @@ -1689,14 +1689,14 @@ hard drive), the next payment will cause a double spend, resulting in anonymity loss and a penalty for the customer. % FIXME: move this to design or implementation -\subsubsection{Fair Exchange} +\subsubsection{Fair Exchange}\label{sec:security:atomic-swaps} % FIXME: we should mention "atomic swap" here -The Endorsed E-Cash system by Camenisch et al. (described in Section -\ref{sec:security-related-work}) allows for fair exchange of (online or -offline) e-cash against digital goods. The online version does not protect the -customer against loss of anonymity from linkability of aborted fair exchanges. +The Endorsed E-Cash system by Camenisch et al. \cite{camenisch2007endorsed} +allows for fair exchange of (online or offline) e-cash against digital goods. +The online version does not protect the customer against loss of anonymity from +linkability of aborted fair exchanges. Taler's refresh protocol can be used for fair exchange of online e-cash against digital goods, without any loss of anonymity due to linkability of aborted -- cgit v1.2.3