318 lines
19 KiB
TeX
318 lines
19 KiB
TeX
\chapter{Discussion}
|
|
\label{chap:disc}
|
|
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).
|
|
|
|
\subsection{CPU Usage}
|
|
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 \\
|
|
libsodium version: 1.0.18-1build1 \\
|
|
libgcrypt version: 1.8.7-5ubuntu2 \\\\
|
|
Benchmarks with other hardware setups can be found in appendix \ref{chap:app-perf}.
|
|
\end{bfhBox}
|
|
|
|
\begin{table}[h]
|
|
\centering
|
|
\colorlet{BFH-table}{BFH-MediumBlue!10}
|
|
\colorlet{BFH-tablehead}{BFH-MediumBlue!50}
|
|
\setupBfhTabular
|
|
\begin{tabular}{llr}
|
|
\rowcolor{BFH-tablehead}
|
|
\textbf{Signature Scheme} & \textbf{Operation} & \textbf{Speed} \\\hline
|
|
CS & 10x key generation & 0.204 ms \\\hline
|
|
RSA 3072 bit & 10x key generation & 2684 ms \\\hline
|
|
\hline
|
|
CS & 10x derive $R_0, R_1$ \& blinding & 3.870 ms \\\hline
|
|
RSA 3072 bit & 10x blinding & 5 ms \\\hline
|
|
\hline
|
|
CS & 10x signing & 0.077 ms \\\hline
|
|
RSA 3072 bit & 10x signing & 86 ms \\\hline
|
|
\hline
|
|
CS & 10x unblinding & 0.001 ms \\\hline
|
|
RSA 3072 bit & 10x unblinding & 24 ms \\\hline
|
|
\hline
|
|
CS & 10x verifying & 1.358 ms \\\hline
|
|
RSA 3072 bit & 10x verifying & 3.075 ms \\\hline
|
|
\end{tabular}
|
|
\caption{Comparison on CS vs. RSA 3072}
|
|
\label{tab:comp-cs-vs-rsa-3072}
|
|
\end{table}
|
|
|
|
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.
|
|
Comparison of such hardware can be found in appendix \ref{chap:app-perf}, these comparison results come to the same conclusion.\\
|
|
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.
|
|
|
|
\begin{table}[h]
|
|
\centering
|
|
\colorlet{BFH-table}{BFH-MediumBlue!10}
|
|
\colorlet{BFH-tablehead}{BFH-MediumBlue!50}
|
|
\setupBfhTabular
|
|
\begin{tabular}{llr}
|
|
\rowcolor{BFH-tablehead}
|
|
\textbf{Signature Scheme} & \textbf{Operation} & \textbf{Speed} \\\hline
|
|
CS & 10x key generation & 0.204 ms \\\hline
|
|
RSA 1024 bit & 10x key generation & 126 ms \\\hline
|
|
\hline
|
|
CS & 10x derive $R_0, R_1$ \& blinding & 3.870 ms \\\hline
|
|
RSA 1024 bit & 10x blinding & 1.282 ms \\\hline
|
|
\hline
|
|
CS & 10x signing & 0.077 ms \\\hline
|
|
RSA 1024 bit & 10x signing & 7 ms \\\hline
|
|
\hline
|
|
CS & 10x unblinding & 0.001 ms \\\hline
|
|
RSA 1024 bit & 10x unblinding & 2.991 ms \\\hline
|
|
\hline
|
|
CS & 10x verifying & 1.358 ms \\\hline
|
|
RSA 1024 bit & 10x verifying & 0.876 ms \\\hline
|
|
\end{tabular}
|
|
\caption{Comparison on CS vs RSA 1024}
|
|
\label{tab:comp-cs-vs-rsa-1024}
|
|
\end{table}
|
|
\subsection{Disk Space}
|
|
\begin{bfhWarnBox}
|
|
These are theoretical calculations, implementations may choose to persist additional values.
|
|
\end{bfhWarnBox}
|
|
\gls{CSBS} save disk space due to the much smaller key sizes.
|
|
Even more disk space is saved by deriving values with the \gls{hkdf}, these values do not have to be stored.
|
|
\\
|
|
Table \ref{tab:comp-sign-space} shows the disk space comparison of signatures, the private keys alone need even less space with 256 bits per key.
|
|
\\
|
|
The wallet saves a lot of disk space by deriving most of the values.
|
|
In the \gls{CSBS} case a wallet must at least persist the private key $c_s$, $R_0, R_1, s', D_p$, each being 256 bits (32 bytes).
|
|
A wallet needs to persist 150 bytes per coin in total.
|
|
In the RSA Blind Signature case the wallet persists $c_s$, $b$, $\sigma_c$, $D_p$.
|
|
\\Note: for refreshed coins an additional 32 byte value is persisted as seed.\\
|
|
$c_s$ is still a 32 byte value in the RSA case, the other values depend on the RSA key size. (32 byte + 3 * \textit{rsa\_keysize}).
|
|
The disk space comparison for a wallet can be found in \ref{tab:comp-wallet-space}.
|
|
|
|
\begin{table}[ht]
|
|
\centering
|
|
\colorlet{BFH-table}{BFH-MediumBlue!10}
|
|
\colorlet{BFH-tablehead}{BFH-MediumBlue!50}
|
|
\setupBfhTabular
|
|
\begin{tabular}{lccr}
|
|
\rowcolor{BFH-tablehead}
|
|
\textbf{Signature Scheme} & \textbf{Disk Space} & \textbf{Factor} & \textbf{Disk Space 1M signatures}\\\hline
|
|
CS & 512 bits & 1x & 64 MB\\\hline
|
|
RSA 1024 bit & 1024 bits & 2x & 128 MB \\\hline
|
|
RSA 2048 bit & 2048 bits & 4x & 256 MB\\\hline
|
|
RSA 3072 bit & 3072 bits & 6x & 384 MB\\\hline
|
|
RSA 4096 bit & 4096 bits & 8x & 512 MB\\\hline
|
|
\end{tabular}
|
|
\caption{Comparison disk space signatures}
|
|
\label{tab:comp-sign-space}
|
|
\end{table}
|
|
|
|
\begin{table}[ht]
|
|
\centering
|
|
\colorlet{BFH-table}{BFH-MediumBlue!10}
|
|
\colorlet{BFH-tablehead}{BFH-MediumBlue!50}
|
|
\setupBfhTabular
|
|
\begin{tabular}{lccr}
|
|
\rowcolor{BFH-tablehead}
|
|
\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 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}
|
|
\end{table}
|
|
|
|
\subsection{Bandwidth}
|
|
\begin{bfhWarnBox}
|
|
These are theoretical calculations, implementations may choose to persist additional values.
|
|
\end{bfhWarnBox}
|
|
The reasons that \gls{CSBS} use less bandwidth is mostly because the signature/key sizes are much smaller.
|
|
The bandwidth improvements for the \texttt{/keys} API is the same as specified in the table with disk space comparison \ref{tab:comp-sign-space}.
|
|
For \gls{CSBS} many calculations are performed twice, therefore also two values are submitted.
|
|
Table \ref{tab:comp-band-withd} compares the bandwidth used in a withdrawal.
|
|
The 32 byte values $2 * n_w, 2 * D_p, R_0, R_1, s,W_p, c_0, c_1, \sigma_W$ as well as an integer $b$ are transmitted for \gls{CSBS}.\\
|
|
For RSA, the values $D_p, m', \sigma'_c$ have the same size as the key size.
|
|
Additionally, the 32 byte values $W_p, \sigma_W$ are transmitted.
|
|
\\\\
|
|
In the refresh protocol the only difference is an additional hash ($h_{C_0}, h_{C_1}$ instead of only $h_C$) sent in the commit phase.
|
|
Depending on the hash size another 32 byte (or 64 byte) value is transmitted.
|
|
|
|
\begin{table}[ht]
|
|
\centering
|
|
\colorlet{BFH-table}{BFH-MediumBlue!10}
|
|
\colorlet{BFH-tablehead}{BFH-MediumBlue!50}
|
|
\setupBfhTabular
|
|
\begin{tabular}{lccr}
|
|
\rowcolor{BFH-tablehead}
|
|
\textbf{Signature Scheme} & \textbf{Bandwidth 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 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{Bandwidth comparison withdrawal}
|
|
\label{tab:comp-band-withd}
|
|
\end{table}
|
|
|
|
\subsection{Latency}
|
|
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.
|