This chapter describes the necessary changes on the protocol level to implement a Blind Schnorr Signature Scheme to Taler.
\section{Analysis of Current Protocols}
The blind RSA signature scheme is only used for coin signatures.
Note that we omitted protocols (or parts of them) where the coin signature is transmitted, but no other actions using it is performed.
\\\\
\label{abort-idempotency}
An important property to mention here is \textit{\gls{abort-idempotency}}.
\Gls{idempotence} in the context of computer science is a property to ensure that the state of a system will not change, no matter how many times the same request was made.
A more in-depth explanation is given within the cited source \cite{yuchen:idempotence}.\\
\textit{\gls{abort-idempotency}} goes a bit further.
When the protocol is aborted at any stage, for example due to power cuts or network issues, the protocol still needs to ensure that the same response is sent for the same request.
This is especially challenging when dealing with random values as we will see in the redesigned protocols in the following sections.
For \gls{RSABS} it is inherently easier to provide \textit{\gls{abort-idempotency}} since signature creation only needs one round-trip and requires less random values.
The following protocols currently use \gls{RSABS}:
\begin{itemize}
\item\textbf{Withdraw Protocol:}
The customer uses the blind signature scheme to blind the coins before transmitting them to the exchange, which blindly signs it (standard RSA signature) and the returns the signatures.
After the customer receives the signatures, he unblinds and stores them together with the coins.
\\ Components:
\begin{itemize}
\item Customer
\item Exchange
\end{itemize}
\item\textbf{Deposit Protocol:}
During the Deposit, the exchange verifies the coin signature derived using the blind RSA signature scheme.
\\ Components:
\begin{itemize}
\item Exchange
\end{itemize}
\item\textbf{Refresh Protocol:}
The refresh protocol is used to derive a new coin from an old one which was partially spent.
Parts of the protocol are similar to the withdraw protocol, but it is more complex due to the added DH lock and cut-and-choose.
\\ Components:
\begin{itemize}
\item Customer
\item Exchange
\end{itemize}
\item\textbf{Tipping:}
Tipping is a variation of the withdraw protocol where the message containing the blinded planchets is transmitted to the merchant, who signs them using his reserve private, key and returns the signatures back to the customer.
Here, the details from the withdraw protocol apply.
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.
The goal of the thesis is to add support for the Clause Blind Schnorr Signature scheme to Taler, besides the existing \gls{RSABS} implementation (see section \ref{sec:blind-rsa-sign}).
For the design of the \gls{CSBS} the existing protocols with \gls{RSABS} were redesigned.
The goal of the blind signature is to keep the exchange from knowing which coin a user withdraws and thus preventing the exchange linking a coin to a user.
The biggest impact is on the withdrawal and refresh protocols, but all protocols that include some operation around denomination signatures are affected.
During the thesis the protocols will be redesigned, implemented and the differences to the current version will be outlined.
These results will be delivered to the Taler team.
Feedback is very important when (re)designing protocols.
For that reason the redesigned protocols were discussed and reviewed with Christian Grothoff multiple times.
As signature scheme the Clause Blind Schnorr Signature Scheme described in section \ref{sec:clause-blind-schnorr-sig} was chosen for multiple reasons.
First of all it is currently considered to be secure (see \cite{cryptoeprint:2019:877}).
Schnorr Signatures on \gls{25519} are much shorter than RSA signatures.
This should provide notable performance improvements in speed and storage, and therefore scales better.
The paper describes a security analysis of the Blind Schnorr Signature scheme and introduces a modification (the "clause" part in the name) that is resistant to Wagner's algorithm (which solves ROS problem).
\Gls{25519}\cite{bern:curve25519} will be used for the implementation because it is a widely accepted curve (see \cite{bernlange:safecurves}, \cite{rfc7748}) and is already used by Taler (Taler uses Ed25519 which is built upon \gls{25519}).
\subsection{Withdraw Protocol}
\label{sec:withdraw-protocol-schnorr}
The modified protocol using the Clause Blind Schnorr Signature Scheme is described in figures \ref{fig:withdrawal-process-schnorr-1} and \ref{fig:withdrawal-process-schnorr-2}.
The proposed change introduces an additional round trip.
It must be prevented that the exchange has to track sessions or persist values during the first stage \ref{fig:withdrawal-process-schnorr-1}, while still ensuring \gls{abort-idempotency}.
In order to ensure \textit{\gls{abort-idempotency}}, the exchange has to generate the same $R_0,R_1$ for the same withdrawal request, while $r_0,r_1$ still needs to be unpredictable for the customer.
For this reason a withdrawal-nonce combined with a \gls{hkdf} comes into play.
The redesigned protocol makes extensive use of \gls{hkdf}'s functionality as \ac{PRNG} and one-way function, thus random becomes \textit{unpredictable}.
In the beginning of the protocol, the customer generates a coin key pair.
Its private key is used to generate the withdraw-nonce $n_w$ and the blinding factors $\alpha_0, \alpha_1, \beta_0, \beta_1$.
The exchange uses the withdraw nonce together with the reserve key and a long-term secret to generate $r_0, r_1$.
The coin and denomination private keys can be used as long-term secrets due to the one-way property of the \gls{hkdf}.
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 recopu protocol in place that would handle coin recovery in case of a key compromise and subsequent revocation.
\caption{Withdrawal process using Clause Blind Schnorr Signatures part 2}
\label{fig:withdrawal-process-schnorr-2}
\end{figure}
\subsection{Deposit Protocol}
The deposit protocol remains unchanged, except for the verification of the coin signature.
To verify the signature, the exchange has to check if the following equation holds:
\begin{align*}
s'G & = R' + c' D_p
\\&= R' + H(R', C_p) D_p
\end{align*}
$ s', R' $ together form the signature, $ D_p $ is the denomination public key and $ C_p $ is the coin public key.
Further details regarding the verification process can be found in section \ref{sec:blind-schnorr-sig}.
\subsection{Refresh Protocol}
The refresh protocol blindly signs the new derived coins.
The replacement of \gls{RSABS} with the Clause Blind Schnorr Signature Scheme (see \ref{sec:clause-blind-schnorr-sig}) makes the refresh protocol a bit more complex.
\subsubsection{RefreshDerive Schnorr}
The RefreshDerive protocol is described in figure \ref{fig:refresh-derive-schnorr}.
For this protocol, the main change is that more values need to be derived somehow.
These blinding factors are also derived from $x$.
Then the challenges $\overline{c_0}$ and $\overline{c_1}$ are generated as in the Clause Blind Schnorr Signature Scheme.
\caption[RefreshDerive algorithm]{The RefreshDerive replaced with Schnorr blind signature details. As before the uses the seed $s$ on the dirty coin for generating the new coin.
The new coin needs to be signed later on with the denomination key.}
\label{fig:refresh-derive-schnorr}
\end{figure}
\subsubsection{Refresh Protocol}
\label{sec:refresh-protocol}
In the commit phase (see figure \ref{fig:refresh-commit-part1}) there needs to be requested an $R_0$ and $R_1$ before deriving the new coins.
There now needs to be calculated two different commit hashes, one for $\overline{c_0}$ and one for $\overline{c_1}$.
The exchange needs to additionally generate a random $b \leftarrow\{0,1\}$ to choose a $\overline{c_b}$.
The reveal phase (see figure \ref{fig:refresh-commit-part2}) now is continued only with the chosen $\overline{c_b}$.
In the reveal phase, the RSA signing and unblinding is exchanged with Schnorr's blind signature counterparts.
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}:
\\The withdraw transcript (and verification) must be adjusted in order for the exchange to be able to retrace the blinding.
\item\textbf{The coin has been partially spent}:
\\In this case the refresh protocol will be invoked on the coin.
The necessary changes are outlined in \ref{sec:refresh-protocol}.
\item\textbf{The revoked coin has never been seen by the exchange and resulted from a refresh operation}:
\\The refresh protocol transcript and its blinding factors must be adjusted to consider the changes in the blind signature scheme.