-more typos

doc/cs/ads/glossary.tex

@@ -6,7 +6,7 @@
 %
 
 %
-% Glossareintraege --> referenz, name, beschreibung
+% Glossareintraege --> reference, name, beschreibung
 % Aufruf mit \gls{...}
 %
 % \newglossaryentry{non-repudiation}{name={non-repudiation},plural={non-repudiation},description={After a message is signed, one can not dispute that a message was signed}}

doc/cs/content/1_introduction.tex

@@ -51,7 +51,7 @@ In scope are all necessary changes on the protocol(s) and components for the fol
     \item design and implement a protocol where the user proves to the exchange the knowledge of the coin that is to be signed (optional)
 \end{itemize}
 
-Out of scope is production readyness of the implementation.
+Out of scope is production readiness of the implementation.
 This is because changes in the protocos and code need to be thoroughly vetted to ensure that no weaknesses or security vulnerabilities were introduced.
 Such an audit is out of scope for the thesis and is recommended to be performed in the future.
 The iOS wallet will not be considered in this work.

doc/cs/content/3_preliminaries.tex

@@ -141,7 +141,6 @@ This can be used to detect compromised signing keys or a malicious exchange.
 
 \subsection{Properties}
 \label{sec:taler-properties}
-%Alle Taler Eigenschaften die wir angreifen wollen auflisten und bezug nehmen wie diese erreicht werden
 This section describes Taler's properties.
 
 \subsubsection{Free Software}
@@ -299,7 +298,7 @@ If verification is successful, only Alice knows her private key and Bob uses Ali
 A digital signature scheme has a message space M, a signature space S and three algorithms:
 \begin{itemize}
     \item Key generation: $(pk,sk) \gets keyGen()$
-    \item Signatue generation: $s \gets $sign$_sk(m)$
+    \item Signature generation: $s \gets $sign$_sk(m)$
     \item Verification: $ v \gets $verify$_pk(m,s)$ where $v \in {0,1}$
 \end{itemize}
 If the result of the verification algorithm equals 1, a signature for m is called valid.
@@ -783,7 +782,7 @@ A good introduction to cut and choose protocols gives the Paper from Claude Cré
         The expression cut-and-choose was later introduced by David Chaum in analogy to a popular cake sharing problem:
         Given a complete cake to be shared among two parties distrusting of each other (for reasons of serious appetite).
         A fair way for them to share the cake is to have one of them cut the cake in two equals hares, and let the other one choose his favourite share.
-        This solution guarantes that it is in the formers best interest to cut the shares as evenly as possible."
+        This solution guarantees that it is in the formers best interest to cut the shares as evenly as possible."
     }
 \end{center}
 
@@ -870,10 +869,10 @@ Figure \ref{fig:withdraw-loophole-exploit} explains how such a payment would wor
 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 malicious 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.
+    \item The withdraw confirmations are transmitted to the exchange, which generates the signatures and returns them to the malicious merchant.
+    \item The malicious merchant unblinds the signatures.
           He is now in possession of the coin, thus the payment is completed.
 \end{enumerate}
 
@@ -882,7 +881,7 @@ This is how it works on a high level:
         \resizebox{1.0\textwidth}{!}{$\displaystyle
         \begin{array}{ l c l}
             % preliminaries
-            \textbf{Customer}          &  & \textbf{malicous Merchant}
+            \textbf{Customer}          &  & \textbf{malicious 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
@@ -903,7 +902,7 @@ This is how it works on a high level:
             \\
             \hline
             \\
-            \textbf{malicous Merchant} &  & \textbf{Exchange}
+            \textbf{malicious Merchant} &  & \textbf{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
@@ -949,7 +948,6 @@ Chapter 4.1.4 describes more general aspects as well as the contract header and
 \subsubsection{Spend Protocol}
 The payment process begins when a customer submits a shopping cart (one or more items to buy) and commits his intent to buy them.
 The merchant has a key pair skM, pkM of which the customer knows the public key.
-% besseres Wort als commit?
 Note that certain details contained in contract header or deposit permission like merchant \ac{KYC} information, deposit and refund deadlines and fees are left out.
 The deposit state machine can be seen in figure \ref{fig:deposit:states}.
 \begin{figure}[htp]
@@ -1033,7 +1031,7 @@ In cases where there are multiple deposit permissions (meaning that multiple coi
               \item Is the signature of the coin valid?
               \item Is $ f $ (the value to be spent) smaller or equal the residual value of the coin (check for overspending attempt)?
           \end{itemize}
-          If all checks are successful, the exchange saves the deposit record containing the deposit permission and its signature in a database, substracts the spent value from the residual value of the coin and schedules the money transfer to the merchant's account $ A_m $ (grouping payments is done to reduce payment fees).
+          If all checks are successful, the exchange saves the deposit record containing the deposit permission and its signature in a database, subtracts the spent value from the residual value of the coin and schedules the money transfer to the merchant's account $ A_m $ (grouping payments is done to reduce payment fees).
           \\The exchange calculates a deposit confirmation signature $ \sigma_{DC} $ for the deposit permission with the exchange signing private key and returns them to the merchant.
           \\This signature is also used to prove that a merchant was the first to receive payment from a certain coin.
           Without this, an evil exchange could later deny confirming a payment and claim double spending.

doc/cs/content/4_2_specification.tex

@@ -370,7 +370,7 @@ GNUNET_CRYPTO_cs_unblind (
     struct GNUNET_CRYPTO_CsS *signature_scalar);
 \end{lstlisting}
 
-The verify API takes the message and its signature with the public key and returns GNUNET\_OK for a valid signature and GNUNET\_SYSERR otherwhise.
+The verify API takes the message and its signature with the public key and returns GNUNET\_OK for a valid signature and GNUNET\_SYSERR otherwise.
 See listing \ref{lst:crypto-verify-api}.
 
 \begin{lstlisting}[style=bfh-c,language=C,, caption={GNUnet verify API}, label={lst:crypto-verify-api}]
@@ -411,7 +411,7 @@ In crypto.c many utility functions are provided to create planchets (for planche
 One difference between \gls{RSABS} and \gls{CSBS} is, that the coin private key and RSA blinding secret can be created at the same point in time, since the RSA blinding secret is created randomly.
 However, for Clause Blind Schnorr secrets an additional step is needed, the public $R_0$ and $R_1$ are required to calculate the blinding seed to derive the secrets.
 
-A planchet in the Clause Blind Schnorr Signature Scheme can be created as followed (implementation details ommited).
+A planchet in the Clause Blind Schnorr Signature Scheme can be created as followed (implementation details omitted).
 
 \begin{enumerate}
   \item Create planchet with new \ac{EdDSA} private key

doc/cs/content/4_3_implementation.tex

@@ -94,8 +94,8 @@ The corresponding crypto helper, that talks with the security module, and its te
     \item \texttt{src/util/test\_helper\_cs.c}: Tests and benchmarks for the \gls{CSBS} crypto helper
 \end{itemize}
 % Crypto API offene Punkte:
-%Input-Validierung von Punkten und Skalar
-% Clamping beschreiben: https://neilmadden.blog/2020/05/28/whats-the-curve25519-clamping-all-about/
+%Input-validation of points and scalars:
+% describe clamping: https://neilmadden.blog/2020/05/28/whats-the-curve25519-clamping-all-about/
 % Testing: inverse operations, blinded signature test
 
 

doc/cs/content/5_discussion.tex

@@ -112,7 +112,7 @@ 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 conlcusion.\\
+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.
@@ -205,7 +205,7 @@ The disk space comparison for a wallet can be found in \ref{tab:comp-wallet-spac
     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 bandwith improvements for the \texttt{/keys} API is the same as specified in the table with disk space comparison \ref{tab:comp-sign-space}.
+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}.\\
@@ -222,14 +222,14 @@ Depending on the hash size another 32 byte (or 64 byte) value is transmitted.
     \setupBfhTabular
     \begin{tabular}{lccr}
         \rowcolor{BFH-tablehead}
-        \textbf{Signature Scheme} & \textbf{Bandwith used} & \textbf{Factor} & \textbf{1M coins}\\\hline
+        \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{Bandwith comparison withdrawal}
+    \caption{Bandwidth comparison withdrawal}
     \label{tab:comp-band-withd}
 \end{table}
 

doc/cs/content/6_conclusion.tex

@@ -25,7 +25,7 @@ The thesis provides several results to add support for Schnorr's blind signature
     \end{itemize}
     \item Comparison and Analysis
     \begin{itemize}
-        \item Performance (speed, space, latency \& bandwith)
+        \item Performance (speed, space, latency \& bandwidth)
         \item Security
         \item Scheme Comparison
     \end{itemize}
@@ -58,7 +58,7 @@ A security audit should always be made when implementing big changes like these.
 As mentioned in the scope section, the optional goal to find and implement a good solution for the withdraw loophole was dropped.
 This was due to the scope shift and because the analysis of the problem showed that finding a good solution needs more research and is a whole project in itself (see \ref{sec:scope} for more information).\\
 Furthermore, \gls{CSBS} could be implemented on other curves.
-For example Curve448 \cite{cryptoeprint:2015:625} could be used, as it provides 224 bits of security, wheras \gls{25519} \cite{bern:curve25519} provides about 128 bits of security.
+For example Curve448 \cite{cryptoeprint:2015:625} could be used, as it provides 224 bits of security, whereas \gls{25519} \cite{bern:curve25519} provides about 128 bits of security.
 Curve secp256k1 could further improve \gls{CSBS} performance.
 While providing support for Curve448 should not be problematic, a potential implementation for secp256k1 needs further analysis (see \cite{bernlange:safecurves} and \cite{bip:schnorr-bitc} for more information).
 

src/auditor/auditor-basedb.sql

@@ -1442,7 +1442,7 @@ BEGIN
   PERFORM create_partitioned_table(
     'CREATE TABLE IF NOT EXISTS %I'
       '(aggregation_serial_id BIGINT GENERATED BY DEFAULT AS IDENTITY' -- UNIQUE'
-	    ',deposit_serial_id INT8 PRIMARY KEY' -- REFERENCES deposits (deposit_serial_id) ON DELETE CASCADE' -- FIXME chnage to coint_pub + deposit_serial_id for more efficient depost -- or something else ???
+	    ',deposit_serial_id INT8 PRIMARY KEY' -- REFERENCES deposits (deposit_serial_id) ON DELETE CASCADE' -- FIXME change to coint_pub + deposit_serial_id for more efficient depost -- or something else ???
       ',wtid_raw BYTEA NOT NULL' -- CONSTRAINT wire_out_ref REFERENCES wire_out(wtid_raw) ON DELETE CASCADE DEFERRABLE'
     ') %s ;'
     ,table_name
@@ -16989,4 +16989,3 @@ ALTER TABLE ONLY public.signkey_revocations
 --
 -- PostgreSQL database dump complete
 --
-

src/auditor/revoke-basedb.sql

@@ -1442,7 +1442,7 @@ BEGIN
   PERFORM create_partitioned_table(
     'CREATE TABLE IF NOT EXISTS %I'
       '(aggregation_serial_id BIGINT GENERATED BY DEFAULT AS IDENTITY' -- UNIQUE'
-	    ',deposit_serial_id INT8 PRIMARY KEY' -- REFERENCES deposits (deposit_serial_id) ON DELETE CASCADE' -- FIXME chnage to coint_pub + deposit_serial_id for more efficient depost -- or something else ???
+	    ',deposit_serial_id INT8 PRIMARY KEY' -- REFERENCES deposits (deposit_serial_id) ON DELETE CASCADE' -- FIXME change to coint_pub + deposit_serial_id for more efficient depost -- or something else ???
       ',wtid_raw BYTEA NOT NULL' -- CONSTRAINT wire_out_ref REFERENCES wire_out(wtid_raw) ON DELETE CASCADE DEFERRABLE'
     ') %s ;'
     ,table_name
@@ -17001,4 +17001,3 @@ ALTER TABLE ONLY public.signkey_revocations
 --
 -- PostgreSQL database dump complete
 --
-

src/testing/testing_api_cmd_reserve_purse.c

@@ -103,7 +103,7 @@ struct ReservePurseState
   json_t *contract_terms;
 
   /**
-   * Refernece to the reserve, or NULL (!).
+   * Reference to the reserve, or NULL (!).
    */
   const char *reserve_ref;