This chapter analyses the \acl{CS} implementation and compares it to the existing implementation with \gls{RSABS}.
The comparison will include the schemes itself, performance comparisons and a discussion on the security assumptions.
For the performance comparison CPU usage, latency, bandwidth and storage space are compared.
\section{Cipher Agility}
One of the benefits of having another blind signature scheme in Taler is \textit{cipher agility}.
Cipher agility means that one scheme can substitute another, for example if one scheme gets compromised in the future.
Cipher agility is considered harmful in certain situations.
TLS 1.2 \cite{rfc5246} and IPSEC/IKEv2 \cite{rfc6071} are good examples on how dangerous cipher agility inside protocols can be.
There are many ways these protocols can be set up insecure.
\\\\
Taler's protocols are built around blind signature schemes.
Therefore it is crucial to have an additional secure blind signature scheme that works with all Taler protocols.
As described in section \ref{sec:blind-sign-schemes}, blind signature schemes can vary and may be complex to substitute.
The \gls{CSBS} implementation provides such an alternative and thus \textit{cipher agility}.
\section{Scheme Comparison}
\label{chap:disc-scheme-comp}
Both schemes are explained in the preliminaries chapter (\gls{RSABS} in section \ref{fig:rsa-fdh-blind-sign} and \gls{CSBS} in \ref{fig:clause-blind-schnorr-sign-scheme}).
\\
There are multiple differences worth mentioning.
The first difference is that Schnorr signatures are inherently randomized.
This is also where the additional step in Schnorr signatures comes from.
A random number is chosen by the signer for every signature. \\
In \gls{CSBS} two blinding secrets are used instead of one in \gls{RSABS}.
On top of that, \gls{CSBS} needs to do most computations for signature creation twice, due to the \ac{ROS} problem (see \ref{par:ros-problem}).
\\\\
\textit{\Gls{abort-idempotency}} is a very important property for Taler.
Ensuring \gls{abort-idempotency} with the \gls{CSBS} scheme is harder than it was with RSA, due to the many random elements in the scheme ($r_0, r_1, \alpha_0, \alpha_1, \beta_0, \beta_1, b$).
The reason that these values are chosen randomly is the need for \textit{unpredictability}.\\
In the protocols (see chapter \ref{chap:design}) \gls{hkdf} is extensively used to derive these values instead of randomly generating them.
That way, the values are still \textit{unpredictable} (due to \gls{hkdf} properties), but now the protocols also ensure \textit{\gls{abort-idempotency}}.
In comparison to the RSA Blind Signature scheme, this is a clever and elegant solution, but the protocol complexity is increased.
\\\\
One could now think that RSA would be much simpler to implement, since the scheme looks easier and more accessible for many.
This can go horribly wrong and many developers still underestimate implementing RSA.
There are a lot of attacks on RSA, some examples are listed on the famous tool RsaCtfTool \cite{ganapati:rsactftool}.
Ben Perez made a popular talk and blog post, about why one should stop using RSA and should preferably use libsodium and \ac{ECC}\cite{perez:stoprsa}.
Using \gls{RSABS} in Taler is still a reasonable and fine choice.
Taler uses libgcrypt, a well-known and tested library.
\\
To conclude, the \gls{CSBS} protocols might be more complex to understand than the RSA Blind Signature protocols.
One has to keep in mind that implementing RSA correctly is hard.
\\
Another difference worth mentioning is, that the \gls{CSBS} scheme does not need scheme specific configurations, whereas RSA needs a key size specified.
This is because the implemented \gls{CSBS} version only supports \gls{25519}.
\\\\
Furthermore, both schemes provide \textit{perfect blindness}, see paragraph \ref{par:prop-blindness-rsa} for RSA and paragraph \ref{par:prop-blindness-cs} for \gls{CSBS}.
\section{Performance Comparison}
\label{sec:disc-perf-comp}
This section compares how the two schemes perform regarding CPU usage, latency, bandwidth and space.
Clause Schnorr has fixed key sizes with 256 bits (32 bytes), which we compare against different RSA key sizes (1024, 2048, 3072 and 4096 bits).
In terms of security, \gls{CSBS} 256 bit keys could be compared to 3072 bit RSA keys (see \url{https://www.keylength.com/} for more information).
Various benchmarks were made on different CPU architectures.
This section discusses the main results, detailed information about the performance comparison can be found in appendix \ref{chap:app-perf}.
We thank the Taler team for providing measurements from additional systems and architectures.
Table \ref{tab:comp-cs-vs-rsa-3072} shows how \gls{CSBS} compares to RSA 3072.
RSA 3072 was chosen for comparison, since they both provide a comparable level of security.
Both provide about 128 bits of security, which means that roughly $2^{128}$ attempts in average are needed for a successful brute-force attack.\\
The table shows that \gls{CSBS} has better performance compared to RSA 3072 in all operations.
The biggest difference can be seen in the key generation.
In RSA, two random primes are needed, whereas \ac{DLP} algorithms like \gls{CSBS} only need to generate a random value.
Since key generation is done rarely compared to the other operations, the time needed for key generation does not matter that much.\\
Furthermore, the blinding in \gls{CSBS} is still faster than blinding in RSA, although in the \gls{CSBS} case the calculation is done twice. Also the derivation of $r_0,r_1$, the generation of $R_0,R_1$ and the derivation of $\alpha_0, \beta_0, \alpha_1, \beta_1$ is included in the measurement for the blinding operation of \gls{CSBS}.
Signing and blinding operations are much faster in \gls{CSBS}, also \gls{CSBS} signature verification is faster than RSA 3072.
\begin{bfhBox}[BFH-MediumBlue]{Setup}
CPU: 8-core AMD Ryzen 7 PRO 5850U \\
OS: Ubuntu 21.10 Linux 5.13.0-25-generic \#26-Ubuntu SMP Fri Jan 7 15:48:31 UTC 2022 x86\_64 x86\_64 x86\_64 GNU/Linux \\
Table \ref{tab:comp-cs-vs-rsa-1024} shows a comparison between \gls{CSBS} and RSA 1024 bit.
RSA 1024 is in some situations faster than the \gls{CSBS} implementation.
Note that 1024 bit keys are not recommended for many use cases, but the highest currently known RSA factorization done is 829 bits \cite{enwiki:1055393696}.
The following section \ref{sec:disc-risk} explains the risk running RSA 1024 or \gls{CSBS} denominations further.\\
The blind and unblind operations are running in a wallet implementation, therefore the comparison with RSA 1024 is very interesting for devices with less CPU power.
Although RSA 1024 bit is much faster in the blinding operation, \gls{CSBS} still perform better when calculating the blinding and unblinding operations together.
\gls{CSBS} unblinding computes only an addition of two scalars $s +\alpha\mod p$, while RSA computes $s * r^{-1}$.
To conclude, \gls{CSBS} are faster than RSA 1024 bit and provide a better level of security.
This can be especially useful for wallets running on devices with less CPU power.
The verification on RSA 1024 is faster than \gls{CSBS}.
Therefore, it has to be further investigated which algorithm would overall perform better for the exchange or merchants.
While RSA 1024 bit can compete in certain operations, \gls{CSBS} provide a better level of security and are still faster in most operations.
This section the notion of \acl{RTT} (see \cite{geeks:rtt}) is used.
There are many factors that influence the measurement of a \acl{RTT}.
Following factors can bring huge changes in the value of \ac{RTT}s.
\begin{itemize}
\item Distance
\item Transmission medium
\item Network hops
\item Traffic levels
\item Server response time
\end{itemize}
All of these factors will vary in reality and are independent of the scheme.\\
The important comparison here is the number of \ac{RT}s as in table \ref{tab:comp-rtt}.
\begin{table}[ht]
\centering
\colorlet{BFH-table}{BFH-MediumBlue!10}
\colorlet{BFH-tablehead}{BFH-MediumBlue!50}
\setupBfhTabular
\begin{tabular}{lc}
\rowcolor{BFH-tablehead}
\textbf{Signature Scheme}&\textbf{Number of RTs}\\\hline
RSA Blind Signatures & 1\\\hline
Clause Blind Schnorr Signatures & 2\\\hline
\end{tabular}
\caption{Comparison of Round-Trips}
\label{tab:comp-rtt}
\end{table}
While creating \gls{RSABS} have one \ac{RT}, \gls{CSBS} need an additional \ac{RT} for requesting the public $R_0, R_1$.
This means that the time spend for withdrawing is almost \textbf{doubled} (the $ R $ request doesn't have any persistence and therefore requires less time) in comparison to RSA.
A coin should not be spent immediately after withdrawal or refresh.
Otherwise, an adversary could deanonymize a customer by correlating the timestamps.
The additional \ac{RT} is a drawback of \gls{CSBS} compared to RSA, but negligible due to the fact that a coin must not be spent immediately.
\section{Security Assumptions}
\label{sec:disc-sec-assumptions}
This section discusses the differences regarding the security assumptions of the schemes.
This section should not explain nor analyze the security assumptions, instead the section focuses on explaining what these assumptions mean and what should be kept in mind about them.
Read section \ref{sec:sign-schemes} and it's references for more information on the assumptions.
RSA's security assumptions are well known since quite a long time and a lot of research is done.
Despite being a lot of attacks \cite{ganapati:rsactftool}\cite{perez:stoprsa}, RSA is still considered a secure scheme after decades.\\
For Schnorr Signatures the \acl{DLP} (see \autoref{sec:dlp}) needs to be hard.
Also the \ac{DLP} is well-known and is being researched since decades.\\
However, with Blind Schorr Signatures an additional assumption needs to hold; the \ac{ROS} problem.
Compared to the other assumptions, \ac{ROS} is relatively new and still a recent research topic.
A recent paper from 2020 on the (in)security of ROS \cite{cryptoeprint:2020:945} broke many schemes relying on ROS being hard, including Schnorr Blind signatures.
The paper on which we rely on (updated in 2021) with the Clause Blind Schnorr Signature Scheme \cite{cryptoeprint:2019:877} is considered secure at the time of writing.\\
\section{Risk}
\label{sec:disc-risk}
As introduced in \autoref{sec:disc-sec-assumptions}, \gls{CSBS} rely on an additional assumption currently being researched.
Compared to other schemes, the chosen \gls{CSBS} are very new (published in 2019, updated in 2021).
While every scheme could potentially be broken, older ones already went through a lot of research and their assumptions are well-known.
Therefore, the risk that a vulnerability in \gls{CSBS} will be discovered is probably higher than a newly discovered vulnerability breaking RSA.
Unpredictability of $ r $ is a key aspect of the signature creation process of \gls{CSBS}.
The redesigned Taler protocols solve this by persisting the nonce and denomination key (described in \autoref{sec:withdraw-protocol-impl}) and checking for reuse of this combination before signature creation.
If this process is malfunctioning (broken implementation, faulty database) or can be circumvented in any way, recovery of a denomination private key is possible.
An exchange operator can still consider using \gls{CSBS} as denomination scheme, as there are multiple benefits (see \autoref{sec:disc-perf-comp}).
The financial loss in the worst case can be calculated and capped by the validity of a denomination key.
If a vulnerability in the \gls{CSBS} would be detected, an exchange operator could revoke the corresponding denomination keys and change the scheme to \gls{RSABS}.
The wallets can then follow the refund protocol to get the money back.
\section{Comparison Conclusion}
\label{sec:disc-comp-conclusion}
A detailed comparison of the two blind signature schemes was made.
This last section interprets the results and concludes the comparison.
\gls{CSBS} on \gls{25519} provide the same security level as \gls{RSABS} with 3072 bit key sizes.
The implementation of \gls{CSBS} is the clear winner in all performance comparisons with RSA 3072 bits.
1024 bit RSA is faster than the \gls{CSBS} implementation in certain operations.
The \gls{CSBS} implementation still offers better performance for wallets with less CPU power and provides a much higher level of security (comparable to RSA 3072).
As further comparisons show, RSA scales very bad the larger the keys get and \gls{CSBS} performs much better overall.
As discussed in the risk section \ref{sec:disc-risk}, \gls{CSBS} have an additional security assumption, which is still a recent research topic.
\gls{CSBS} provide various benefits and the risk can be calculated and capped.
An exchange operator who is aware of the discussed risk can use \gls{CSBS} safely.
\gls{CSBS} are best suited for denominations with low value, where many coins are being withdrawn/refreshed.
