commit 482d0e664c0e190811245dfbf96428ab9470372c
parent ad0f8d4f42c4665b006c2ae20a99a2e10047b370
Author: Casaburi Johannes <johannes.casaburi@students.bfh.ch>
Date: Wed, 12 Jun 2024 21:30:00 +0200
fix typos
Diffstat:
15 files changed, 43 insertions(+), 35 deletions(-)
diff --git a/doc/thesis/abstract.tex b/doc/thesis/abstract.tex
@@ -7,7 +7,7 @@ system could in principle work with other payment systems.
Providing evidence of charitable donations for tax deductions often requires
sensitive personal information, raising privacy concerns.
-Donors may wish to anonymize receipts while still beeing able to make
+Donors may wish to anonymize receipts while still being able to make
legitimate donations to recognized charities.
Deductions for unrecognized charities or failure to deduct valid foreign
donations also occur. A system allowing anonymous yet verifiable donation
diff --git a/doc/thesis/bibliography.bib b/doc/thesis/bibliography.bib
@@ -68,3 +68,11 @@
year={2012},
howpublished = {\url{https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:12012E/TXT}},
}
+
+@misc{taler-sub,
+ author={{Christian Blättler}},
+ title={Privacy-preserving Subscriptions and Discounts},
+ year={2024},
+ howpublished = {\url{https://stage.taler.net/papers/subscription-discounts-thesis.pdf}},
+}
+
diff --git a/doc/thesis/chapters/acknowledgements/acknowledgements.tex b/doc/thesis/chapters/acknowledgements/acknowledgements.tex
@@ -2,5 +2,5 @@ First and foremost, we would like to thank Christian Grothoff and Emmanuel Benoi
A special thank to Michiel Leenaars from the NLnet foundation who had the initial idea for the project.
We would also like to thank our expert Daniel Voisard for his feedback during the project.
Further we would like to thank Christian Blättler for his contributions to GNUnet, on which our project relies on.
-A big thank to the tax authority Zürich who agreed to an interview, which has provided us with valuable insight in how donations are verified and important aspects that a system like the Donau should fulfil.
+A big thank to the tax authority Zürich who agreed to an interview, which has provided us with valuable insight in how donations are verified and important aspects that a system like the Donau should fulfill.
We would like to mention that we have used DeepL for word translations and \url{https://app.diagrams.net/} for some of the figures in this thesis.
diff --git a/doc/thesis/chapters/background/blindsign.tex b/doc/thesis/chapters/background/blindsign.tex
@@ -3,9 +3,9 @@ One important cryptographic scheme used by the Donau is the blind signature
scheme. It is an extension of digital signatures which provides, besides
authenticity and non-repudiation, privacy by allowing a user to obtain a
signature for a message, without revealing the contents of the message to the
-signer. All cryptographic elements used by the Donau where privided by the GNU
+signer. All cryptographic elements used by the Donau where provided by the GNU
Taler libraries. Blind signatures are slightly slower than the normal
-signatutes, this does not result in a performance issue as this project on GNU
+signatures, this does not result in a performance issue as this project on GNU
Taler shows: \url{https://taler.net/en/news/2022-06.html}.
This section only provides an overview of blinded signatures. Detailed
@@ -18,7 +18,7 @@ able to unblind the signature and therefore to receive a valid signature for
the unblinded message. The Donau system uses blinded signatures to bind the
identity to a donation receipt while hiding the identity of the donor. As a
result of the property of blindness, the blind signer (in this case the Donau)
-is not able to link the cleartext message with the made blind signature
+is not able to link the clear-text message with the made blind signature
or the blind signature with the unblind signature \cite[p.12]{cryptoeprint:2019/877}.
There are multiple blind signature schemes. The Donau distinguishes
@@ -28,7 +28,7 @@ the following two equivalent blind signature schemes:
Concrete the RSA-FDH blind signatures are used. Before blinding, to eliminate
certain attacks, a Full-Domain Hash (FDH) is applied on the message.
Full-Domain means the hash has the same size as the RSA modulus. The blind
-signature scheme is similar to the normal RSA signatur scheme. In addition to
+signature scheme is similar to the normal RSA signature scheme. In addition to
the normal scheme, the message is blinded with a private and random value.
Practically the length of the modulus and therefore for the key size, signature
size and the security level is variable. The scheme only has one round trip.\cite{nigelcrypto:2016}
@@ -39,13 +39,13 @@ blinder needs two random values from the signer party. One random value from
the signer and two random private values are required to blind the message
once. This process is repeated and the two blinded messages are sent to the
signer, who randomly selects a blinded message for blinding. Two blinded
-messages are needed to prevent an certain type of attack. In comparision to the
+messages are needed to prevent an certain type of attack. In comparison to the
RSA scheme, the Clause Schnorr Scheme needs an additional round trip to get the
-inital nonces from the signer. However, the individual crypto operations are so
+initial nonces from the signer. However, the individual crypto operations are so
much faster than the operations from the RSA scheme that the additional round
trip is no longer significant.\cite{DemHeuz2022}
-Because clause schnorr signatures are based on elliptic curves, smaller keys
+Because Clause Schnorr signatures are based on elliptic curves, smaller keys
can be used. GNU Taler supports one fixed 256 bit key size, which provides an
security level of 128 bits. The exact processes of this signature scheme do not
need to be understood in order to understand this thesis.
diff --git a/doc/thesis/chapters/background/hash.tex b/doc/thesis/chapters/background/hash.tex
@@ -19,7 +19,7 @@ assumption is the Avalanche Criterion. The property defines that a small change
in the hash input message leads to a substantial change in the output hash.
This criteria makes it hard to guess the input even if a part of the input is
known.\cite{hash2012} To protect the donor, their identity is represented as a
-salted hash of the tax identifiaction number. The salt is a small high entropy
+salted hash of the tax identification number. The salt is a small high entropy
value, to make it more difficult to guess the hashed value.
The Donau uses the SHA-512 hash function. SHA-512 is part of the SHA-2 family
diff --git a/doc/thesis/chapters/background/interview.tex b/doc/thesis/chapters/background/interview.tex
@@ -5,7 +5,7 @@ In order to find out how the tax authorities nowadays verify donations for
donation deduction an interview with the tax authority Zürich was held.
The interview transcript can be found in the appendix section \ref{transcript}.
Currently the tax authority Zürich verifies donations by hand. The
-verification process is intentionaly kept simple as donation fraud does not
+verification process is intentionally kept simple as donation fraud does not
seem to be a big problem. Other ways to conduct fraud, are more likely and
profitable with less legal risk attached. There is no known data that contains
how much money the state has lost with donation fraud.
diff --git a/doc/thesis/chapters/implementation/android.tex b/doc/thesis/chapters/implementation/android.tex
@@ -8,7 +8,7 @@ the link is activated. The arguments defined in chapter
\ref{donor_sends_final_statement_to_a_validator} are separated with slashes. To
ensure that as many characters as possible can be stored in the QR code, the QR
code should be alphanumeric encoded\footnote{alphanumeric encoded QR codes have
-a capaticity of up to 4296 characters and support only a few special
+a capacity of up to 4296 characters and support only a few special
characters}. This means that each argument is stringified. To ensure that no
special characters are used for binary data, the hash and the signature are
encoded in ASCII using CrockfordBase32.\cite{qrcodedensowavewebsite}
diff --git a/doc/thesis/chapters/implementation/donau.tex b/doc/thesis/chapters/implementation/donau.tex
@@ -5,7 +5,7 @@ The Donau has a similar architecture and uses
crypographic blinded signatures in a similar way as the exchange does.
\subsection{REST API} \label{rest_api}
-The detailed REST API specificatoin of the Donau backend is publicy available
+The detailed REST API specification of the Donau backend is publicly available
under the following URL: \url{https://docs.taler.net/core/api-donau.html}. The
following are the main API endpoints:
@@ -18,7 +18,7 @@ statement signature for the donor (see section
\ref{donor_requests_a_donation_statement_from_the_donau}).
The following is an example response of a \lstinline{curl 127.0.0.1:8080/keys}
-command. Some parts of the following example respones are truncated (denoted by
+command. Some parts of the following example responses are truncated (denoted by
the three dots '\texttt{...}') to make them more readable.
\begin{lstlisting}
@@ -78,7 +78,7 @@ amount for the charity of the current year.
\begin{figure}[ht]
\includegraphics[width=1\textwidth]{donau_flow_register_charity}
-\caption{The tax authority registeres a new charity in the Donau}\label{fig:donau_flow_register_charity}
+\caption{The tax authority registers a new charity in the Donau}\label{fig:donau_flow_register_charity}
\end{figure}
The following is an example response of a
@@ -286,7 +286,7 @@ Contains all Donau EdDSA signing keys.
\item \texttt{donau\_pub:} Donau EdDSA public key.
\item \texttt{valid\_from:} Year the signing key becomes valid.
\item \texttt{expire\_sign:} Year the signing key becomes invalid.
- \item \texttt{expire\_legal:} Year the signing key legaly expires.
+ \item \texttt{expire\_legal:} Year the signing key legally expires.
\end{itemize}
\subsubsection{receipts\_issued}
@@ -308,14 +308,14 @@ case the private key is replaced.
\item \texttt{h\_tax\_number:} The hash of the tax number and salt.
\item \texttt{nonce:} The nonce used in the \texttt{Unique Donor Identifier}
\item \texttt{donation\_unit\_pub:} Reference to public key used to sign.
- \item \texttt{donation\_unit\_sig:} The unblided signature the Donau made.
+ \item \texttt{donation\_unit\_sig:} The unblinded signature the Donau made.
\item \texttt{donation\_year:} The year the donation was made.
\end{itemize}
\subsubsection{history}
History of the yearly donations for each charity. This data provides a record
of donations each year. It could also provide valuable information that could
-be used in statistics to analize general donations over the year.
+be used in statistics to analyze general donations over the year.
\begin{itemize}
\item \texttt{charity\_id:} Unique ID generated by the database.
\item \texttt{final\_amount:} The final amount that was donated to the charity
diff --git a/doc/thesis/chapters/introduction/goals.tex b/doc/thesis/chapters/introduction/goals.tex
@@ -16,7 +16,7 @@ to deduct all donations of the year from taxes.
Because the receipts are centralized in one place, in the donor's wallet, the
donor does not have to worry about storing or loosing the receipts. In
addition, by submitting the donation receipts to the Donau the donation
-receipts will be stored by the Donau. This should be a significant impovement
+receipts will be stored by the Donau. This should be a significant improvement
in user convenience for both the donor and tax authority.
The Donau should prevent donation fraud with fake, expired or third-party
@@ -29,7 +29,7 @@ The goals described above boil down to the following:
\begin{itemize}
\item Protect the donors privacy and still be able to deduct the amount from
the taxes.
- \item Make donations verfiable by simply scanning a QR-Code.
+ \item Make donations verifiable by simply scanning a QR-Code.
\item Improve the user convenience for both the donor and tax authorities.
\item Prevent donation fraud with fake, expired or third-party donations.
\end{itemize}
diff --git a/doc/thesis/chapters/introduction/motivation.tex b/doc/thesis/chapters/introduction/motivation.tex
@@ -9,7 +9,7 @@ donated to a recognized charity.
%privacy
There are many reasons why such information can be sensitive and should be
hidden from third parties. Both personally and politically this information
-could be harmful to individuals if not handeled responsably. To remain
+could be harmful to individuals if not handled responsibly. To remain
anonymous donors would have to keep their donation receipts, which would not
allow them to deduct the donation from taxes. It is best to reduce and
anonymize this information as much as possible, while still having all the
@@ -24,7 +24,7 @@ the time the tax declaration is submitted.
%standardisation
For every donation the donor wants the donation to be tax deductible. The
-adressed charity has to be recognized by the local tax authority. However, it
+addressed charity has to be recognized by the local tax authority. However, it
can happen that donations to unrecognized charities are mistakenly deducted or
that donations to recognized charities abroad are not deducted. This misconduct
has found attention by Michiel Leenaars from the NLnet Foundation\footnote{see
diff --git a/doc/thesis/chapters/introduction/scope.tex b/doc/thesis/chapters/introduction/scope.tex
@@ -17,8 +17,8 @@ system like the Donau should fulfill.
Out of scope was the charity implementation which would have been integrated
into the Taler merchant and the donor client implementation which would have
been integrated into the Taler wallet. Unlike the charity integration, the
-donor part of the taler wallet is payment system dependent.
-In other words, since the taler wallet can only make donations with the taler
+donor part of the Taler wallet is payment system dependent.
+In other words, since the Taler wallet can only make donations with the Taler
payment system, it could only receive donation receipts for this. The
administrator interface was also not realized, which would have provided a
user-friendly interface to manage the charities.
diff --git a/doc/thesis/chapters/results/conclusion.tex b/doc/thesis/chapters/results/conclusion.tex
@@ -5,7 +5,7 @@ state and its citizens. Transparency allows for public scrutiny, which can help
identify inefficiencies, loopholes, or instances of corruption within the tax
system, ultimately leading to necessary reforms and improvements.
-Unfortunately, it occured to us that some tax departments still rely on
+Unfortunately, it occurred to us that some tax departments still rely on
outdated, paper-based systems or legacy software, hindering their ability to
operate efficiently and transparently. The lack of digitization not only slows
down processes but also increases the risk of errors, data inconsistencies, and
@@ -27,5 +27,5 @@ reduced.
Of course, bureaucracy and federalism can hinder the introduction of such a
system. Especially when it comes to the recognition of charities. But the Donau
-could provide a first step into a more standardized system that handels
+could provide a first step into a more standardized system that handles
donations in a secure and privacy preserving way.
diff --git a/doc/thesis/chapters/results/future.tex b/doc/thesis/chapters/results/future.tex
@@ -17,18 +17,18 @@ Each registered charity needs to communicate with the donors and the Donau. The
Taler merchant backend needs to be modified to incorporate the charity backend
logic. To do this it is necessary to add a charity information table to the
merchant database. This table should contain information like the charity
-public key, domain, base URL, currency and instance. The instance beeing a
+public key, domain, base URL, currency and instance. The instance being a
number as there could be different instances running. The merchant backend
needs to be extended to incorporate the charity logic. Meaning the signing of
BKP's sent to the charity and also the communication with the donor. The
charity should return a list of Donaus where the charity is registered, so that
-the donor can choose the appropriate Donau for tax deduction.
-%thesis christian blättler
+the donor can choose the appropriate Donau for tax deduction. A system similar
+to the one described in the thesis of Christian Blättler is to be implemented \cite{taler-sub}.
\subsection{Donau SPA}\label{donau_spa}
-For the administrator a single page application is needed to comftably manage
+For the administrator a single page application is needed to comfortably manage
the charities. This would include functionality to add, remove and modify
-charities. This setup could include a reverse proxy, which authenicates the
+charities. This setup could include a reverse proxy, which authenticates the
Donau admin. Once the identity has been confirmed the proxy can access the
Donau endpoint to manage a charity. The proxy would hold a bearer token, in
order to authenticate itself.
diff --git a/doc/thesis/chapters/results/results.tex b/doc/thesis/chapters/results/results.tex
@@ -2,7 +2,7 @@
Currently the Donau REST API is fully implemented. The Donau can manage any
number of charities using the \texttt{/charities} endpoint.
All the keys used for signing and blind signing are managed by the Donau
-thogether with the Secmod helpers.
+together with the Secmod helpers.
Overall the Donau is able to issue donation receipts and provide the necessary
donation statement to the donor, all while keeping the data anonymized and
@@ -12,7 +12,7 @@ With the binding of the tax number to the donation receipts and the signature
of the tax authority with year-dependent keys, the receipts are absolutely
bound to a donor and to a year and cannot be falsified or imitated without
falsifying the signature. Therefore donation fraud can be prevented. By
-summarizing the receipts into one single QR-Code, the user convienience for the
+summarizing the receipts into one single QR-Code, the user convenience for the
tax authority and for the donor could be improved.
Important components that are needed to operate the Donau are not yet
@@ -20,8 +20,8 @@ implemented. This includes the charity side and donor client side. Although
test where written to ensure that the Donau endpoints operate as expected,
there are still some bugs and most likely also unknown bugs, not yet found.
-The tax authority emphasises user convenience and simplicity in a system like
-the Donau. The tax authority also mentioned the challanges that arise when
+The tax authority emphasizes user convenience and simplicity in a system like
+the Donau. The tax authority also mentioned the challenges that arise when
operating such a system in the federalism. Each party often has different
requirements that a system like the Donau should fulfill.
Although the Donau is in its early stages and the prototype has not yet been
diff --git a/doc/thesis/thesis.pdf b/doc/thesis/thesis.pdf
Binary files differ.
