implement feedback in cs thesis

5 files changed, 13 insertions, 208 deletions

diff --git a/doc/cs/content/4_1_design.tex b/doc/cs/content/4_1_design.tex
index 272f8da7..1d22b151 100644
--- a/doc/cs/content/4_1_design.tex
+++ b/doc/cs/content/4_1_design.tex
@@ -48,8 +48,8 @@ The following protocols currently use \gls{RSABS}:
               \item Customer
               \item Exchange
           \end{itemize}
-    \item \textbf{Payback Protocol:}
-          The payback protocol distinguishes three different cases, which either use the refresh protocol or disclose either the withdraw transcript or refresh protocol transcript to the exchange.
+    \item \textbf{Recoup Protocol:}
+          The recoup protocol distinguishes three different cases, which either use the refresh protocol or disclose either the withdraw transcript or refresh protocol transcript to the exchange.
           \\ Components:
           \begin{itemize}
               \item Customer
@@ -96,7 +96,7 @@ The coin and denomination private keys can be used as long-term secrets due to t
 
 Another question evolved around which key to use for the derivation of $ r_0, r_1 $.
 Obvious options are the denomination key or the exchange's online signing key.
-The denomination key was chosen because it has the payback protocol in place that would handle coin recovery in case of a key compromise and subsequent revocation.
+The denomination key was chosen because it has the recopu protocol in place that would handle coin recovery in case of a key compromise and subsequent revocation.
 
 \begin{figure}[htp]
   \begin{equation*}
@@ -376,7 +376,7 @@ In the reveal phase, the RSA signing and unblinding is exchanged with Schnorr's
       \\ & & \textbf{check } h_C = h_C'
       \\ & & r_b := \text{HKDF}(256,n_r || d_s, \text{"r}b\text{"})
       \\ & & \overline{s}_{C_p}^{(\gamma)} = r_b + \overline{c_{b_\gamma}} d_s \mod p
-      \\ & & \text{persist } \langle \rho_L, \sigma_L \rangle
+      \\ & & \text{persist } \langle \rho_L, \sigma_L, S \rangle
       \\ & \xleftarrow[\rule{2.5cm}{0pt}]{b, \overline{s}_C^{(\gamma)}} &
       % Check coin signature and persist coin
       % unblind signature
@@ -444,8 +444,8 @@ To re-obtain the derived coin, the same calculations as in \ref{fig:refresh-deri
 \subsection{Tipping}
 Tipping remains unchanged, except for the content of the message $ \rho_W = D_p, c_0, c_1 $ signed by the merchant using its reserve private key.
 
-\subsection{Payback Protocol}
-The payback protocol distinguishes three different cases, which all depend on the state of a coin whose denomination key has been revoked.
+\subsection{Recoup Protocol}
+The recoup protocol distinguishes three different cases, which all depend on the state of a coin whose denomination key has been revoked.
 The following listing outlines the necessary changes on the protocol, please refer to Dold's documentation section 2.2.1 \cite{dold:the-gnu-taler-system} for details regarding the different cases.
 \begin{itemize}
   \item \textbf{The revoked coin has never been seen by the exchange}:
diff --git a/doc/cs/content/5_discussion.tex b/doc/cs/content/5_discussion.tex
index 1e1bcd5d..c68b4a79 100644
--- a/doc/cs/content/5_discussion.tex
+++ b/doc/cs/content/5_discussion.tex
@@ -192,9 +192,9 @@ The disk space comparison for a wallet can be found in \ref{tab:comp-wallet-spac
         \textbf{Signature Scheme} & \textbf{Disk Space} & \textbf{Factor} & \textbf{Disk Space 1M coins}\\\hline
         CS 256 bits & 150 bytes & 1x & 150 MB\\\hline
         RSA 1024 bit & 416 bytes & 2.7x & 416 MB \\\hline
-        RSA 2048 bit & 800 bits & 5.3x & 800 MB\\\hline
-        RSA 3072 bit & 1184 bits & 7.9x & 1184 MB\\\hline
-        RSA 4096 bit & 1568 bits & 10.4x & 1568 MB\\\hline
+        RSA 2048 bit & 800 bytes & 5.3x & 800 MB\\\hline
+        RSA 3072 bit & 1184 bytes & 7.9x & 1184 MB\\\hline
+        RSA 4096 bit & 1568 bytes & 10.4x & 1568 MB\\\hline
     \end{tabular}
     \caption{Comparison disk space wallet}
     \label{tab:comp-wallet-space}
@@ -225,9 +225,9 @@ Depending on the hash size another 32 byte (or 64 byte) value is transmitted.
         \textbf{Signature Scheme} & \textbf{Bandwith used} & \textbf{Factor} & \textbf{1M coins}\\\hline
         CS 256 bits & 356 bytes & 1x & 324 MB\\\hline
         RSA 1024 bit & 448 bytes & 1.3x & 448 MB \\\hline
-        RSA 2048 bit & 832 bits & 2.5x & 832 MB\\\hline
-        RSA 3072 bit & 1216 bits & 3.75x & 1216 MB\\\hline
-        RSA 4096 bit & 1600 bits & 4.9x & 1600 MB\\\hline
+        RSA 2048 bit & 832 bytes & 2.5x & 832 MB\\\hline
+        RSA 3072 bit & 1216 bytes & 3.75x & 1216 MB\\\hline
+        RSA 4096 bit & 1600 bytes & 4.9x & 1600 MB\\\hline
     \end{tabular}
     \caption{Bandwith comparison withdrawal}
     \label{tab:comp-band-withd}
diff --git a/doc/cs/content/appendix/rsa-redesign.tex b/doc/cs/content/appendix/rsa-redesign.tex
index 463b9735..4f66d907 100644
--- a/doc/cs/content/appendix/rsa-redesign.tex
+++ b/doc/cs/content/appendix/rsa-redesign.tex
@@ -159,7 +159,7 @@ The changes to the refresh protocol are related to the derivation of transfer se
                     \\ & & h_C' = H(h_T', h_{\overline{m}}')
                     \\ & & \textbf{check } h_C = h_C'
                     \\ & & \overline{\sigma}_C^{(\gamma)} := \overline{m}^{d_{s(t)}}
-                    \\ & & \text{persist } \langle \rho_L, \sigma_L \rangle
+                    \\ & & \text{persist } \langle \rho_L, \sigma_L, S \rangle
                     \\ & \xleftarrow[\rule{2.5cm}{0pt}]{\overline{\sigma}_C^{(\gamma)}} &
                     % Check coin signature and persist coin
                     \\ \sigma_C^{(\gamma)} := r^{-1}\overline{\sigma}_C^{(\gamma)}
diff --git a/doc/cs/content/chapter_01.tex b/doc/cs/content/chapter_01.tex
deleted file mode 100644
index 5bb35445..00000000
--- a/doc/cs/content/chapter_01.tex
+++ /dev/null
@@ -1,35 +0,0 @@
-%!TEX root = ../dokumentation.tex
-
-\chapter{Das erste Kapitel}
-\section{Hello}
-Erste Erwähnung eines Akronyms wird als Fußnote angezeigt. Jede weitere wird
-nur verlinkt: \ac{AGPL}. Zweite Erwähnung \ac{AGPL}
-
-Verweise auf das Glossar: \gls{Glossareintrag}, \glspl{Glossareintrag}
-
-Nur erwähnte Literaturverweise werden auch im Literaturverzeichnis gedruckt:
-\cite{baumgartner:2002}, \cite{dreyfus:1980}
-\Gls{Glossareintrag}
-Meine erste Fußnote\footnote{Ich bin eine Fußnote}
-
-\begin{wrapfigure}{r}{.4\textwidth}
-\includegraphics[height=.4\textwidth]{taler.png}
-\vspace{-15pt}
-\caption{Das Logo der Musterfirma\footnotemark}
-\end{wrapfigure}
-%Quelle muss in Fußnote stehen (da sonst aufgrund eines Fehlers nicht kompiliert
-% wird)
-\footnotetext{aus \cite{mustermann:2012}}
-Ein ganz langer Text, der das Bild umfließt. Ein ganz langer Text, der das Bild
-umfließt. Ein ganz langer Text, der das Bild umfließt. Ein ganz langer Text, der
-das Bild umfließt. Ein ganz langer Text, der das Bild umfließt. Ein ganz langer
-Text, der das Bild umfließt. Ein ganz langer Text, der das Bild umfließt. Ein
-ganz langer Text, der das Bild umfließt. Ein ganz langer Text, der das Bild
-umfließt. Ein ganz langer Text, der das Bild umfließt. Ein ganz langer Text, der
-das Bild umfließt. Ein ganz langer Text, der das Bild umfließt. Ein ganz langer Text, der das Bild
-umfließt. Ein ganz langer Text, der das Bild umfließt. Ein ganz langer Text, der
-das Bild umfließt. Ein ganz langer Text, der das Bild umfließt. Ein ganz langer
-Text, der das Bild umfließt. Ein ganz langer Text, der das Bild umfließt. Ein
-ganz langer Text, der das Bild umfließt. Ein ganz langer Text, der das Bild
-umfließt. Ein ganz langer Text, der das Bild umfließt. Ein ganz langer Text, der
-das Bild umfließt.
diff --git a/doc/cs/content/withdraw_loophole_remediation.tex b/doc/cs/content/withdraw_loophole_remediation.tex
deleted file mode 100644
index 9e466aa7..00000000
--- a/doc/cs/content/withdraw_loophole_remediation.tex
+++ /dev/null
@@ -1,160 +0,0 @@
-\section{Remediation of the Withdraw Loophole}
-The withdraw loophole allows untaxed and untraceable payments by "misusing" the withdraw protocol.
-It allows withdraw operations where owner of the resulting coins isn't the owner of the reserve that the coins where withdrawn from.
-It is used for tipping and can therefore be seen as a feature.
-
-Using the withdraw loophole for payments is illustrated in figure \ref{fig:withdraw-loophole-exploit}.
-Note that we omitted the parts leading up to the coin creation (contract, agreement of price, number of coins and their denominations).
-This is how it works on a high level:
-\begin{enumerate}
-    \item The malicous merchant generates and blinds coins, which are then transmitted to the customer
-    \item The customer authorizes the withdraw from his reserve by signing the blinded coins with the private key of his reserve, thus generating withdraw confirmations.
-    \item The withdraw confirmations are transmitted to the exchange, which generates the signatures and returns them to the malicous merchant.
-    \item The malicous merchant unblinds the signatures.
-    He is now in possession of the coin, thus the payment is completed.
-\end{enumerate}
-
-\begin{figure}[h]
-    \begin{equation*}
-        \begin{array}{ l c l}
-            % preliminaries
-            \text{Customer} &  & \text{malicous Merchant}
-            \\ \text{knows:} & & \text{knows:}
-            \\ \text{reserve keys } w_s, W_p
-            \\ \text{denomination public key } D_p = \langle e, N \rangle & & \text{denomination public key } D_p = \langle e, N \rangle
-            \\
-            % generate coin
-            \\ & & \text{generate coin key pair:}
-            \\ & & c_s, C_p \leftarrow \text{Ed25519.KeyGen}()
-            % blind
-            \\ & & \text{blind:}
-            \\ & & r \leftarrow random \in \mathbb{Z}_N^*
-            \\ & & m' := \text{FDH}(N, C_p)*r^{e} \mod N
-            % sing with reserve sk
-            \\ & \xleftarrow[\rule{2cm}{0pt}]{m'}
-            \\ \text{sign with reserve private key:}            
-            \\ \rho_W := \langle D_p, m' \rangle
-            \\ \sigma_W := \text{Ed25519.Sign}(w_s, \rho_W)
-            \\ & \xrightarrow[\rule{2cm}{0pt}]{ \langle W_p, \sigma_W, \rho_W \rangle }
-            \\
-            % TODO add some kind of separator
-            \hline
-            \\
-            \text{malicous Merchant} &  & \text{Exchange}
-            \\\text{knows:} & & \text{knows:}
-            \\& & \text{reserve public key } W_p
-            \\ \text{denomination public key } D_p = \langle e, N \rangle & & \text{denomination keys } d_s, D_p
-            \\
-            \\ & \xrightarrow[\rule{2cm}{0pt}]{ \langle W_p, \sigma_W, \rho_W \rangle }
-            \\ & & \langle D_p, m' \rangle := \rho_W
-            \\ & & \text{verify if } D_p \text{ is valid}
-            \\ & & \textbf{check } \text{Ed25519.Verify}(W_p, \rho_W, \sigma_W)
-            \\ & & \text{decrease balance if sufficient}
-            \\ & & \text{sign:}
-            \\ & & \sigma'_c := (m')^{d_s} \mod N
-            \\ & \xleftarrow[\rule{2cm}{0pt}]{\sigma'_c}
-            \\ \text{unblind:}
-            \\ \sigma_c := \sigma'_c*r^{-1}
-            \\ \text{verify signature:}
-            \\ \textbf{check if } \sigma_c = \text{FDH}(N, C_p)
-            \\
-            \\ \text{resulting coin: } \langle c_s, C_p, \sigma_c, D_p \rangle
-        \end{array}
-    \end{equation*}
-    \caption{untaxed payment using withdraw loophole}
-    \label{fig:withdraw-loophole-exploit}
-\end{figure}
-
-\subsection{Requirements For A Possible Solution}
-A viable solution has to fix the withdraw loophole, while still providing a solution for tipping. In addition, Taler's security properties must not be weakened.
-
-The underlying problem that has to be solved is to check that the person withdrawing a coin is also the owner of the reserve used in the withdraw.
-This has to be solved in a way that prevents the customer and malicious merchant to work together.
-
-% Requirements For A Perfect Solution}
-% minimal adjustments to Taler
-% Commitment to sk of Reserve -> constructed by customer (key owner)
-% commitment to sk of coin
-%   how do we ensure that the customer is key owner? -> combine with reserve sk
-%   how do we verify? problems with blinding
-%   how do we ensure that the coin in the commitment is the coin that is signed?
-% exchange must not learn anything about coin to prevent linking of withdraw and transaction
-
-\subsection{Discussed Solution}
-For our proposed solution, a few adjustments to Taler have to be made:
-\begin{itemize}
-    \item The withdraw confirmation must include a commitment to the public key.
-    This commitment must be constructed in a way that requires the customer to know the public key.
-    The exception to this are special tipping reserves (to preserve the tipping feature).
-    \item Cut-and-choose is added to the withdraw protocol.
-    This means that the customer has to generate the coin and withdraw confirmation $ k $ times.
-    The exchange will then choose one of the $ k $ sessions.
-    The customer has to reveal the coin public key, blinding secret and commitment for all sessions except the chosen one.
-    If the customer isn't able to deliver, the reserve is locked for future withdraws until the other sessions are delivered.
-    Cut-and-choose is introduced to verify whether the customer honestly created the commitment and used the same coin public key for the signature creation and the commitment.
-    If the reserve is a special tip reserve (which has to be registered), this check is omitted.
-    \item An additional protocol is created that transfers the remaining value of a coin back to the reserve if anyone is able to reveal the commitment from the withdrawal.
-    The adjustments described up to this point lead to the customer knowing all the necessary values for using this protocol.
-    Besides the customer, no one must be able to reproduce the commitment, except in case of a reserve key compromise.
-    \item Reserves are limited (usually only one, unless justified) and bound to a customer (KYC).
-    % this goes further than fixing the loophole. It prevents people from creating new reserves that are then to be transfered
-    % TODO check if there are disadvantages to this, especially regarding privacy
-    \item For a coin to be refreshable, it must have been seen by the exchange before, meaning that it had to be used for a payment.
-    The purpose of this is to prevent a malicious merchant to simply refresh a coin after withdraw to prevent the customer from reverting the withdraw.
-    \item For any coin used in a payment, the subtracted value must be higher that a certain threshold (set globally or per denomination).
-    For example, if the threshold is $ 10\% $, at least CHF 10 of a 100 CHF coin must be used for a payment.
-    The goal of this change is to prevent a malicious merchant from buying a very cheap article to be able to refresh the coin.
-\end{itemize}
-
-The commitment has to fulfill the following properties:
-\begin{enumerate}
-    \item It has to be constructed using the reserve private key and must be verifiable using the corresponding public key.
-    \item It has to include the coin public key.
-    \item It has to be constructed in a way that ensures that the customer has knowledge of the coin public key.
-    \item Everyone with knowledge of the two keys must be able to recreate it.
-\end{enumerate}
-
-A possible commitment that partially satisfies the properties can be constructed by hashing a signature of the coin's public key:
-\begin{equation*}
-    H( \text{Ed25519.Sign} (w_w, C_p) )
-\end{equation*}
-Note that the PureEdDSA variant of Ed25519 has to be used for this.
-This variant doesn't hash the message before signing (see \cite{rfc8032} for further details).\\
-It is still possible for a customer and a malicious merchant to construct the commitment without the customer gaining knowledge of the coin public key.
-However, the customer has to share one half of the hash of the reserve private key (which is practically one half of the private key, refer to section \ref{sec:eddsa-signature-creation} for details about EdDSA signature creation).
-
-% was passiert wenn im Verhör und gezwungen wird, Keys herauszurücken?
-
-There is one drawback to this solution:
-In case of a reserve key compromise, coins generated by withdraw operation (not refreshed ones) can be linked to withdraw operations, thus revealing relationships between reserves and payments.
-This is because an adversary (exchange or auditor) in possession of a reserve private key and coin public keys can calculate $ \text{H(Ed25519.Sign}(w_s, C_p)) $ and check in the database if there is a corresponding withdraw operation, thus linking reserve and coin.
-
-\subsubsection{Discussion}
-This is not perfect solution.
-It is designed to make untaxed payments using the withdraw loophole less attractive to use for merchants.
-If accepted, it should only be used in deployments where the withdraw loophole has to be prohibited.\\
-The proposed modifications achieve that a malicious merchant, who wants to perform payments using the withdraw loophole, has to accept one of these drawbacks:
-\begin{itemize}
-    \item He has to accept that the customer is able to revert the payment.
-    \item He has to spend the coins fully.\\
-    If he is registered as a merchant at an exchange, he can perform payments to himself to launder the money.
-    Here, Talers \ac{AML} capabilities come into play.\\
-    The other possibility is to buy goods at other merchants.
-    These goods then have to be liquidated, which requires effort.
-    This wouldn't be a problem (for the malicous merchant) if cryptocurrency can be bought using Taler.
-    \item He has to spend the coins partially to be able to refresh them (thus preventing payment reversion by the customer).
-    The goods that were bought using the coin fraction then would have to be liquidated (see previous point).
-    \item He has to add the threshold value that is lost in order to refresh the coin into the price for payments.
-\end{itemize}
-
-The commitment added to the withdrawal weakens the privacy of coins.
-Blinding guarantees everlasting privacy, which would be neutralized by the commitment.
-
-The added cut-and-choose makes withdrawing more intensive, which leads to increased infrastructure requirements (and therefore costs).
-
-The added threshold makes coin spending less flexible.
-Wallets either have to contain more coins to guarantee that there is always a coin (or multiple) available to guarantee a payment without violating the threshold limitations.
-The other variant is that wallets refrain from withdrawing coins with big(ger) denominations, which leads to bigger sums of coins used per payment.
-
-This discussed solution is submitted to the Taler team as a part of the thesis documentation, upon which they can review the protocol changes and decide whether to pursue further.
-Therefore, the solution will not be implemented during this thesis.