[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[donau] branch master updated (aa84bf3 -> 351b824)
From: |
gnunet |
Subject: |
[donau] branch master updated (aa84bf3 -> 351b824) |
Date: |
Thu, 23 Jan 2025 00:25:00 +0100 |
This is an automated email from the git hooks/post-receive script.
tanja-lange pushed a change to branch master
in repository donau.
from aa84bf3 -de-tanjarize
new c8a5b2e start of additional references
new 1032a32 typo fix
new e6fe2cd this is too chatty for the definition environment and it was
the only definiion, put citations with the thing they are being cited for
new 918f7f9 adding example for blind signatures, wording
new 786cf42 changed to donau service and agreed on removing tax authority
when not needed
new 550689b spell checking and general read through
new 819cf92 tricky with anonymous link and sounds misleadingly alarming
new ef82ee8 linking in appendix, removing URLs that could violate anoymity
new 2e1c6be the threat section was covering only ethical aspects, so
moved into ethics part to save some space
new 351b824 adding code listings & commitment for aritfact
The 10 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
doc/usenix-security-2025/paper/app-impl.tex | 186 +++++++++++++++++++++
doc/usenix-security-2025/paper/discussion.tex | 4 +-
doc/usenix-security-2025/paper/donau-paper.tex | 4 +-
doc/usenix-security-2025/paper/ethic.tex | 22 ++-
doc/usenix-security-2025/paper/implementation2.tex | 24 ++-
doc/usenix-security-2025/paper/intro.tex | 2 +-
doc/usenix-security-2025/paper/tanja.bib | 11 ++
doc/usenix-security-2025/paper/technicaldesign.tex | 102 ++++++-----
doc/usenix-security-2025/paper/threats.tex | 5 +-
9 files changed, 299 insertions(+), 61 deletions(-)
create mode 100644 doc/usenix-security-2025/paper/app-impl.tex
create mode 100644 doc/usenix-security-2025/paper/tanja.bib
diff --git a/doc/usenix-security-2025/paper/app-impl.tex
b/doc/usenix-security-2025/paper/app-impl.tex
new file mode 100644
index 0000000..28a8d45
--- /dev/null
+++ b/doc/usenix-security-2025/paper/app-impl.tex
@@ -0,0 +1,186 @@
+\section{Additional Details -- Implementation}\label{app-impl}
+
+This appendix describes the remaining implementation details such as APIs.
+
+\subsection{REST API}
+
+The detailed REST API specification of the Donau back-end is publicly
+available and will be submitted as artifact.
+The following are
+the main API endpoints:
+
+\subsubsection{\texttt{/keys}}
+The \texttt{GET /keys} request returns all valid donation unit public keys
+offered by the Donau, as well as the Donau's current EdDSA public signing key.
+The following is an example response of a \texttt{curl 127.0.0.1:8080/keys}
+command. Some parts of the following example responses are truncated (denoted
by
+the three dots '\texttt{...}') to make them more readable.
+
+\begin{verbatim}
+{
+ "version": "0:0:0",
+ "base_url": "http://localhost:8080/",
+ "currency": "EUR",
+ "signkeys": [
+ {
+ "stamp_start": {
+ "t_s": 1717069556
+ },
+ "stamp_expire": {
+ "t_s": 1718279156
+ },
+ "key": "CFV2PY8164E231XZSQK30K8R6CBQ..."
+ },
+ {
+ ...
+ }
+ ],
+ "donation_units": [
+ {
+ "donation_unit_pub": {
+ "cipher": "RSA",
+ "rsa_public_key": "020000YC7XK99S..."
+ },
+ "year": 2024,
+ "lost": false,
+ "value": "EUR:5"
+ },
+ {
+ "donation_unit_pub": {
+ "cipher": "CS",
+ "cs_public_key": "7SKRQGBSEPBG24..."
+ },
+ "year": 2024,
+ "lost": false,
+ "value": "EUR:1"
+ },
+ {
+ ...
+ }
+ ]
+}
+\end{verbatim}
+
+\subsubsection{\texttt{/charities}}
+
+The following is an example response of a \texttt{curl
127.0.0.1:8080/charities} command.
+There is only one charity named \texttt{example} registered with a donation
limit of 10 euros.
+
+\begin{verbatim}
+{
+ "charities": [
+ {
+ "charity_pub": "ABETNXT9ZF606FRF3WD5...",
+ "url": "example.com",
+ "name": "example",
+ "max_per_year": "EUR:10",
+ "receipts_to_date": "EUR:0",
+ "current_year": 2024
+ }
+ ]
+}
+\end{verbatim}
+
+To insert a charity a \texttt{POST} request can be sent using
+\texttt{curl -d @charity.json -X POST http://127.0.0.1:8080/charities}.
+
+The following is an example of a
+\texttt{charity.json} entry
+
+\begin{verbatim}
+{
+ "charity_pub": "ABETNXT9ZF606FRF3WD5...",
+ "charity_name": "mycharity",
+ "charity_url": "mycharity.example.com",
+ "max_per_year": "EUR:1000",
+ "receipts_to_date": "EUR:0",
+ "current_year": 2024
+}
+\end{verbatim}
+
+The response consists of the charity ID generated by the database.
+\begin{verbatim}
+{
+ "charity-id": 1
+}
+\end{verbatim}
+
+
+\subsubsection{\texttt{/batch-issue}}
+
+The following is an example response of a \\
+\texttt{curl -d @issue.json -X POST http://127.0.0.1:8080/batch-issue/1}
+request showing a \texttt{issue.json} entry.
+The number at the end of the URL is the charity ID.
+
+
+
+\begin{verbatim}
+{
+ "budikeypairs": [
+ {
+ "h_donaton_unit_pub": "130C2KDHTAFDQFB8XED...",
+ "blinded_udi": {
+ "cipher": "RSA",
+ "rsa_blinded_identifier": "AXPTEE24W28S9XN..."
+ }
+ }
+ ],
+ "charity_sig": "JEJ0QMDXD416XKSK1SG0DETJEH...",
+ "year": 2024
+}
+\end{verbatim}
+
+\begin{verbatim}
+{
+ "blind_signatures": [
+ {
+ "blinded_signature": {
+ "cipher": "RSA",
+ "blinded_rsa_signature": "16XHNWSCDRVKHF..."
+ }
+ }
+ ],
+ "issued_amount: "EUR:15"
+}
+\end{verbatim}
+
+\subsubsection{\texttt{/batch-submit}}
+
+\begin{verbatim}
+{
+ "h_donor_tax_id": "N2NYR2SFNGZSS388R2SB0VK...",
+ "donation_year": 2024,
+ "donation_receipts": [
+ {
+ "h_donaton_unit_pub": "130C2KDHTAFDQFB8X...",
+ "nonce": "JEQC39G",
+ "donation_unit_sig":
+ {
+ "cipher": "RSA",
+ "rsa_signature": "GQBXPNE4JT5W53T3CVP6E..."
+ }
+ }
+ ]
+}
+\end{verbatim}
+
+\subsubsection{\texttt{/donation-statement}}
+To obtain the donation statement, the donor submits a GET request for a
specified year and taxpayer ID.
+
+The following is an example response of a \\
+\texttt{curl http://127.0.0.1:8080/donation-statement/$\backslash$} \\
+\hspace*{0.5cm} \ \texttt{2024/N2NYR2SFNGZSS388R2SB...} \\
+request.
+
+The last parameter of the URL is the \DI.
+
+\begin{verbatim}
+{
+ "total": "EUR:15",
+ "donation_statement": "C1JVDP25AR001W5AHMAZ...",
+ "donau_pub": "63f62b7901311c2187bfcde6304d1..."
+}
+\end{verbatim}
+
+
diff --git a/doc/usenix-security-2025/paper/discussion.tex
b/doc/usenix-security-2025/paper/discussion.tex
index d3ebecd..bbfd4bf 100644
--- a/doc/usenix-security-2025/paper/discussion.tex
+++ b/doc/usenix-security-2025/paper/discussion.tex
@@ -1,6 +1,6 @@
-\section{Discussion} \label{discussion}
+\section{Discussion of features} \label{discussion}
-In this section we first show how the presented design relates to the
+In this section we show how the presented design relates to the
various requirements discussed in Section~\ref{sec:optionalfeatures}
and what extensions could be made to address almost all of them.
diff --git a/doc/usenix-security-2025/paper/donau-paper.tex
b/doc/usenix-security-2025/paper/donau-paper.tex
index 2ea2b5c..c5c9fcb 100644
--- a/doc/usenix-security-2025/paper/donau-paper.tex
+++ b/doc/usenix-security-2025/paper/donau-paper.tex
@@ -114,7 +114,6 @@ instantiated with significant changes or additions to the
design.
\input{technicaldesign}
\input{implementation2}
\input{discussion}
-\input{threats}
%\input{conclusion}
@@ -141,12 +140,13 @@ constructive discussion on the subject.
\bibliographystyle{plainurl}
-\bibliography{donau-paper,bibliography}
+\bibliography{donau-paper,bibliography,tanja}
% Maybe for camera-ready?
\appendix
\input{appendix}
+\input{app-impl}
%\input{implementation}
\end{document}
diff --git a/doc/usenix-security-2025/paper/ethic.tex
b/doc/usenix-security-2025/paper/ethic.tex
index 966a3d6..187c0f0 100644
--- a/doc/usenix-security-2025/paper/ethic.tex
+++ b/doc/usenix-security-2025/paper/ethic.tex
@@ -1,4 +1,4 @@
-\section*{Ethics considerations and compliance with the open science policy}
+\section{Ethics considerations}
Ethical considerations are at the root of this project.
At their essence, donations are ethical acts that empower third parties to act
in a manner compatible with the value system of the donor.
@@ -7,20 +7,30 @@ explicitly linking them to the causes and institutions they
support.
This has a self-censoring or chilling effect, due to fear of potential future
repercussions in complex and volatile political climates:
information may linger inside of the bureaucratic system and later cause
unforeseeable harm.
Support for certain organizations and their linked causes
-can lead not only to stigmatisation but also to phyical harassement, or far
worse.
+can lead not only to stigmatization but also to physical harassment, or far
worse.
Such concerns about real-world consequences of revealing one's support for
various causes creates stress for donors,
and the current approach to provide tax benefits for donations encroaches on
the privacy of those who do not wish to reveal who they support.
+\input{threats}
+
+\subsection{Administrative burden}
The current mechanism also has discriminatory aspects.
-It places a higher bureaucratic cost on spreading an equivalent cumulative
amount across smaller philanthropic causes -- denying intersectional interests
donors may have, and disadvantaging smaller, early stage and more lean public
causes. %XXX: "earlier stage"/"leaner"?
+It places a higher bureaucratic cost on spreading an equivalent cumulative
amount across smaller philanthropic causes -- denying inter-sectional interests
donors may have, and disadvantaging smaller, early stage and more lean public
causes. %XXX: "earlier stage"/"leaner"?
The latter notably includes ``niche'' causes linked to (combinations of)
cultural, sexual, ethnic, religious and social minorities.
Smaller causes often do not have the capacity to offer support for achieving
fiscal compensation to their donors, reprieving their (latent) donor
constituencies of the amplifying effects of such compensation and making them
less attractive (and thus relatively less likely) to be supported. %XXX: This
sentence does not make sense to me. "Reprieve" is not used correctly (I think),
and it's too lacking in detail to understand whether it's referring to e.g.,
membership benefits, or something [...]
-The aim of this project is to simplify donating for all and offer
non-discrimatory access to tax benefits and greater protection of privacy,
leading to greater tax justice and a philanthropic climate.
+The aim of this project is to simplify donating for all and offer
non-discriminatory access to tax benefits and greater protection of privacy,
leading to greater tax justice and a philanthropic climate.
We want to reverse the situation where people prefer not to claim the tax
benefit to which they are entitled in order to protect themselves.
-The associated software does not place any ethical dillema's upon the users.
+\section{Open science}
+\subsection{Access to software}
+The associated software does not place any ethical dilemmas upon the users.
It is delivered as free/libre open source software, available under GNU
-Affero General Public license v3 or later in the
+Affero General Public license v3 or later in
+\ifanonymous
+a public repository.
+\else
+the
repository \url{git.taler.net/donau.git}.
+\fi
Anyone is able to download, compile, install, modify and redistribute the
software as they wish, conditional to respecting this license.
diff --git a/doc/usenix-security-2025/paper/implementation2.tex
b/doc/usenix-security-2025/paper/implementation2.tex
index c4c609d..f5e55d5 100644
--- a/doc/usenix-security-2025/paper/implementation2.tex
+++ b/doc/usenix-security-2025/paper/implementation2.tex
@@ -1,9 +1,20 @@
+\newif\ifanonymous
+\anonymoustrue
+
\section{Implementation}\label{implementation}
This section describes the current implementation of the Donau server
-(available from \url{https://git.taler.net/donau.git}), which
+\ifanonymous
+\else
+(available from \url{https://git.taler.net/donau.git}),
+\fi
+which
primarily consists of an HTTP server with a REST API
-(\url{https://docs.taler.net/core/api-donau.html}) and a Postgresql
+\ifanonymous
+\else
+(\url{https://docs.taler.net/core/api-donau.html})
+\fi
+and a Postgresql
database (Figure~\ref{fig:donau_system_arch}). The Donau backend is
written in C, as it reuses parts of the codebase from GNU Taler
exchange component. The Donau has a similar architecture and uses
@@ -22,6 +33,9 @@ exchange does, including encapsulating its private keys in
separate
The main endpoints of the REST API are briefly summarized
in the following sections.
+\ifanonymous
+For examples see Appendix~\ref{app-impl}.
+\fi
\subsubsection{\texttt{/keys}}
@@ -38,10 +52,10 @@ to request a donation report to keep track of their total
donations in
the current year. The response includes the maximum donation amount
and the current donated amount for the charity of the current year.
-\begin{figure}[ht]
-\includegraphics[width=0.5\textwidth]{donau_flow_issue_receipt}
+\begin{figure*}[h]
+\includegraphics[width=0.7\textwidth]{donau_flow_issue_receipt}
\caption{Flow of the issue receipt process}
\label{fig:donau_flow_issue_receipt}
-\end{figure}
+\end{figure*}
\subsubsection{\texttt{/batch-issue}}
diff --git a/doc/usenix-security-2025/paper/intro.tex
b/doc/usenix-security-2025/paper/intro.tex
index 575e580..f00a364 100644
--- a/doc/usenix-security-2025/paper/intro.tex
+++ b/doc/usenix-security-2025/paper/intro.tex
@@ -229,7 +229,7 @@ At a high level, the Donau protocol consists of five steps:
their tax payer identification number in return.
\item After the tax period ends, each donor submits their
collected donation confirmation tokens to the Donau and
- receive a summary donation statement over the total
+ receives a summary donation statement over the total
amount bound to their tax payer identification number.
\item Donors submit the summary donation statement with
their tax filing to the donation authority, which validates
diff --git a/doc/usenix-security-2025/paper/tanja.bib
b/doc/usenix-security-2025/paper/tanja.bib
new file mode 100644
index 0000000..e4dd689
--- /dev/null
+++ b/doc/usenix-security-2025/paper/tanja.bib
@@ -0,0 +1,11 @@
+@article{2023/hoepman,
+ author = {Jaap{-}Henk Hoepman},
+ title = {Two faces of blindness},
+ journal = {Des. Codes Cryptogr.},
+ volume = {91},
+ number = {8},
+ pages = {2705--2721},
+ year = {2023},
+ doi = {10.1007/S10623-023-01228-2},
+}
+
diff --git a/doc/usenix-security-2025/paper/technicaldesign.tex
b/doc/usenix-security-2025/paper/technicaldesign.tex
index 0289e3b..a5c2903 100644
--- a/doc/usenix-security-2025/paper/technicaldesign.tex
+++ b/doc/usenix-security-2025/paper/technicaldesign.tex
@@ -29,17 +29,17 @@ top of this core protocol design.
% here you're only linkable across donations to the same
% charity, which is probably OK.
-This section provides a technical overview of the Donau protocol, starting with
+This section provides a technical overview of our Donau protocol, starting with
some cryptographic background followed by the setup and usage.
+The Donau service is typically run by the tax authority but can be an
independent entity.
% The first section introduces some notation and definitions used later on in
the protocol description.
% Concepts from cryptography are also explained when necessary.
%
\subsection{Background \& Terminology}\label{notation_and_definitions}
- Digital cash makes use of \textbf{blind signatures} to issue
tokens~\cite{Chaum89}. Our
- design uses the same mechansim to unlink the donation process from the issued
- donation receipts, thus preserving the anonymity properties of the digital
- cash used to make a donation. This section introduces the definition and
+ Digital cash makes use of \textbf{blind signatures}~\cite{Chaum89} to issue
tokens. Our
+ design uses the same mechanism to unlink the donation process from the issued
+ donation receipts. This section introduces the definition and
security properties of blind signatures.
% \paragraph{Cryptographic Hash Function}
@@ -93,8 +93,6 @@ some cryptographic background followed by the setup and usage.
never be able to link previously issued blind signatures with their
unblinded counterparts.
- \begin{definition}{Blind Signature}
-
\textrm{Slightly more formally, we define blind signatures as a quadruple
of algorithms:}
\begin{itemize}
\item $KeyGen(1^\lambda)$: Generates a verification/signing key pair
$(K^{\pub}, K^{\priv})$.
@@ -102,52 +100,68 @@ some cryptographic background followed by the setup and
usage.
\item $BlindSign(K^{\priv}, \overline{m})$: Takes secret signing key
$K^{\priv}$ and blinded message $\overline{m}$ and computes the blind signature
$\overline{\sigma}$.
\item $Unblind(\overline{\sigma}, b, K^{\pub})$: Takes blind signature
$\overline{\sigma}$, blinding factor $b$ and verification key $K^{\pub}$ of the
signer, and returns the unblinded signature $\sigma$ on message $m$ (or $\bot$).
\end{itemize}
- \end{definition}
+
+It should be impossible for the signer to infer information about the message
+they sign and it should be impossible for them to trace their signature later,
+see Hoepman's recent paper~\cite{2023/hoepman} highlighting that these are two
+separate requirements.
+
+The most well-known blind signature scheme, going back to Chaum's original
+work~\cite{Chaum89}, is based on RSA. A signature on message $m$ under RSA key
+public key $(n,e)$ is $s\equiv m^d \bmod n$, where $(n,d)$ is the corresponding
+private key. Instead of asking for a signature on $m$ one can request a
+signature on the blinded value $m'\equiv m\cdot r^e \bmod n$ for some randomly
+chosen $r$, receive the blind signature $s'$, and obtain the signature on $m$
+by unblinding $s'$ by computing $s'/r \bmod n$.
+
+
\subsection{Key generation and initial
setup}\label{key_generation_and_initial_setup}
Before incognito donations to charities can be executed, all participants in
-the donation system (i.e., the Donau, charities, and donors) must perform some
+the donation system (i.e., the Donau service, charities, and donors) must
perform some
initial setup steps.
-\subsubsection{Donau key generation}\label{donau_key_generation}
+\subsubsection{Donau service key generation}\label{donau_key_generation}
\begin{enumerate}
-\item The Donau generates an Ed25519~\cite{DBLP:journals/jce/BernsteinDLSY12}
keypair
+\item The Donau service generates an
Ed25519~\cite{DBLP:journals/jce/BernsteinDLSY12} keypair
$(D^{\pub}$, $D^{\priv})$, called the {\bf Donau Key}, for digital
signatures.
- \item The Donau also generates a set of \textbf{Donation Unit} keypairs
+ \item The Donau service also generates a set of \textbf{Donation Unit}
keypairs
$(K_x^{\pub}, K_x^{\priv})$ for blind signatures, corresponding to different
currency denominations $x$ that a donation can be composed of.
\end{enumerate}
-The Donau publishes all public keys over an authenticated channel.
+The Donau service publishes all public keys over an authenticated channel.
It uses fresh Donation Unit keys for each tax period.
\subsubsection{Charity key generation and
registration}\label{charity_key_generation}
\begin{enumerate}
\item Each charity generates its own Ed25519 {\bf Charity Key} $( C^{\pub},
C^{\priv} )$.
- \item The charity also fetches the Donation Unit public keys from the Donau.
- \item The charity transmits its public key $C^{\pub}$ to the party
controlling the Donau (e.g the
-local tax authority) using an authenticated channel.
- \item The party in charge of Donau administration (usually the relevant tax
-authority) ensures that the charity is authentic and a legally recognized
+ \item The charity also fetches the Donation Unit public keys from the
+Donau service.
+ \item The charity transmits its public key $C^{\pub}$ to the party
controlling the Donau service
+using an authenticated channel.
+ \item The party in charge of Donau service administration
+validates that the charity is authentic and a legally recognized
charitable organization. After successful verification, the charity public key
$C^{\pub}$ is registered in the Donau database.
\end{enumerate}
\subsubsection{Donor Identifier generation}
-A donor uses their Donor Identifier every time they
-make a donation and again when requesting a donation receipt from the Donau.
-
Each donor generates a personal \textbf{Donor Identifier} $\DI$ by
computing a salted hash of their taxpayer ID
\begin{align*}
\DI = H(\texttt{TAXID}, S)
\end{align*}
-where $S$ is a random salt with sufficient entropy to
-prevent guessing attacks and {\tt TAXID} is their taxpayer ID.
+where $H$ is a cryptographic hash function and
+$S$ is a random salt with sufficient entropy to
+prevent guessing attacks, and {\tt TAXID} is their taxpayer ID.
The donor stores the salt $S$ along with their $\DI$.
+A donor uses their Donor Identifier every time they
+make a donation and again when requesting a donation receipt from the Donau
service.
+
They need to use the salt to link the Donation Identifier to their tax
ID and claim the tax benefits for their donation. The use of the salt
ensures that the $\DI$ cannot be linked to the donor by anybody
@@ -156,11 +170,11 @@ without $S$, even if they know {\tt TAXID}.
\subsection{Donating to a charity}\label{donating_to_a_charity}
% \subsection{Donor donates to charity and transmits \textbf{Unique Donor
identifiers} (future donation receipts)}
-When a donor wishes to donate to a charity, they first retrieve the Donau's
Donation Unit
+When a donor wishes to donate to a charity, they first retrieve the Donau
service's Donation Unit
public keys $K_x^{\pub}$ for the current tax period.
-The donor then represents their donation as a sum of the Donation Units
offered by the Donau.
+The donor then represents their donation as a sum of the Donation Units
offered by the Donau service.
-\emph{Example: Assuming the Donau publishes the Donation units $\{1,2,4,8\}$,
a donation of $7$ would be split into 1 unit each of the values $4$, $2$ and
$1$.}
+\emph{Example: Assuming the Donau service publishes the Donation units
$\{1,2,4,8\}$, a donation of $7$ would be split into 1 unit each of the values
$4$, $2$ and $1$.}
For each necessary Donation Unit the donor generates a \textbf{Unique Donor
Identifier (UDI)} by appending a random nonce $N_i$ to the value $\DI$.
@@ -179,7 +193,7 @@ The donor must remember all UDIs.
Next the donor blinds the Unique Donor Identifiers using a unique blinding
factor for each one.
This hides the information in the UDIs from third parties, including the Donau
-and charity, and protects against linkability. The result is a set of {\bf
Blinded Unique Donor Identifiers (BUDIs)}.
+service and charity, and protects against linkability. The result is a set of
{\bf Blinded Unique Donor Identifiers (BUDIs)}.
{\em In our example, the Blinded Unique Donor Identifiers would be}
\begin{align*}
@@ -193,7 +207,7 @@ So far, the \textbf{Blinded Unique Donor Identifiers} do
not carry information a
The \emph{intended effective value is indicated} by grouping each Unique Donor
Identifier with
the hash of its respective Donation Unit public key $K^{\pub}_x$.
We call this pair a \textbf{Blinded Unique Donor Identifier Key Pair}
(\textbf{BKP}).
-It is only the \emph{intended effective} value because their value is zero
until they are signed by the Donau.
+It is only the \emph{intended effective} value because their value is zero
until they are signed by the Donau service.
Note that they must be signed with the matching Donation Unit key as the
blinding and unblinding operations rely strongly on the public key.
@@ -228,37 +242,37 @@ That is, it computes
\begin{align*}
\sigma_c = \sign(\vec{\mu}, C^{\priv})
\end{align*}
-The charity sends the array $\vec{\mu}$ of BKPs and their signature $\sigma_c$
to the Donau to generate a receipt.
+The charity sends the array $\vec{\mu}$ of BKPs and their signature $\sigma_c$
to the Donau service to generate a receipt.
-\subsection{Donau generates donation
receipt}\label{donau_creates_donation_receipt}
-When the Donau receives a signed set of BKPs from a charity, it verifies the
charity's signature.
+\subsection{Donau service generates donation
receipt}\label{donau_creates_donation_receipt}
+When the Donau service receives a signed set of BKPs from a charity, it
verifies the charity's signature.
It then checks that no legal restrictions are being violated.
-If none are, the Donau increments its record of the charity's total receipts
by the
+If none are, the Donau service increments its record of the charity's total
receipts by the
total amount of the donation, i.e., the sum of the denominations used in the
BKPs.
-The Donau then blindly signs all BUDIs using the Donation Unit private keys
+The Donau service then blindly signs all BUDIs using the Donation Unit private
keys
$K_x^{\priv}$
that correspond to the public keys hashed in the BKPs.
-{\em In our example, the Donau blindly signs the three BUDIs submitted by the
charity}
+{\em In our example, the Donau service blindly signs the three BUDIs submitted
by the charity}
\begin{align*}
\overline{\beta_1} = \blind\_\sign(\overline u_1, K_1^{\priv}) \\
\overline{\beta_2} = \blind\_\sign(\overline u_2, K_2^{\priv}) \\
\overline{\beta_3} = \blind\_\sign(\overline u_3, K_4^{\priv})
\end{align*}
-These signatures constitute a blinded donation receipt from the Donau, and the
Donau sends these back to the charity,
+These signatures constitute a blinded donation receipt from the Donau service,
and the Donau service sends these back to the charity,
which in turn forwards them to the donor.
\subsection{Donor receives donation
receipt}\label{donor_receives_donation_receipt}
-Upon receiving the blinded donation receipt from the Donau via the charity,
+Upon receiving the blinded donation receipt from the Donau service via the
charity,
the donor verifies the blind signatures over the BUDIs.
If they verify, the donor then unblinds them to obtain signatures over the
original UDIs.
These UDIs, their unblinded signatures, and their respective hashed Donation
Unit public keys
constitute a collection of donation receipts.
These donation receipts are stored on the donor's device.
-{\em In our example: the donor unblinds the Donau signatures
$\overline{\beta_1}, \overline{\beta_2}, \overline{\beta_3}$, obtaining:}
+{\em In our example: the donor unblinds the Donau service signatures
$\overline{\beta_1}, \overline{\beta_2}, \overline{\beta_3}$, obtaining:}
\begin{align*}
\beta_1 &= \unblind(\overline{\beta_1}, b_1, K_1^{\pub}) \\
\beta_2 &= \unblind(\overline{\beta_2}, b_2, K_2^{\pub}) \\
@@ -271,10 +285,10 @@ These donation receipts are stored on the donor's device.
r_3 &= ( \UDI_3, \beta_3, h(K_4^{\pub}) )
\end{align*}
-\subsection{Donor requests an annual donation statement from
Donau}\label{donor_requests_a_donation_statement_from_the_donau}
+\subsection{Donor requests an annual donation statement from Donau
service}\label{donor_requests_a_donation_statement_from_the_donau}
In order for the donor to claim a tax deduction,
the donor needs to obtain a final donation statement which can be sent to the
tax authority.
-The donor sends their saved donation receipts $\{r_1, \ldots, r_k\}$,
accumulated throughout the tax period, to the Donau.
+The donor sends their saved donation receipts $\{r_1, \ldots, r_k\}$,
accumulated throughout the tax period, to the Donau service.
This can in principle be done multiple times during the tax period;
however, the receipts must not be submitted at a time strongly correlated with
the donation to achieve
\emph{unlinkability} between the \emph{issuance} of the receipts (which
happens at the time of donation)
@@ -283,7 +297,7 @@ and their \emph{submission} for the Donation Statement.
Remember that each $\UDI$ is the concatenation of the donor identifier $\DI$
and
a random nonce, i.e., they all start with the same $\DI$.
-Once the Donau receives the donor's donation receipts, it checks that for each
receipt:
+Once the Donau service receives the donor's donation receipts, it checks that
for each receipt:
\begin{itemize}
\item the public key $K_x^{\pub}$ is known.
\item the signature $\beta$ is correct using the corresponding public key
@@ -294,13 +308,13 @@ $K_x^{\pub}$.
identified as $\DI$.
\end{itemize}
-Importantly, the Donau does not see signatures of the charities the donor
+Importantly, the Donau service does not see signatures of the charities the
donor
donated to, so it does not know where the donor spent money.
They also only see a collection of common denominations, so they are unable to
correlate total donation amounts per charity.
-Finally, the receipts are unblinded, so they are unlinkable to any signature
the Donau has seen before.
+Finally, the receipts are unblinded, so they are unlinkable to any signature
the Donau service has seen before.
-The Donau then generates a signature over the total \texttt{amount} of all
receipts, the current tax period (\texttt{year}) and the Donor Identifier.
-This results in a final signature called the \textbf{Donation Statement},
which the Donau returns to the donor:
+The Donau service then generates a signature over the total \texttt{amount} of
all receipts, the current tax period (\texttt{year}) and the Donor Identifier.
+This results in a final signature called the \textbf{Donation Statement},
which the Donau service returns to the donor:
\begin{align*}
\sigma_s = \sign(( \DI, \textsf{amount}_{\sf Total}, \textsf{year}) ),
D^{\priv})
diff --git a/doc/usenix-security-2025/paper/threats.tex
b/doc/usenix-security-2025/paper/threats.tex
index ed7049e..b5a1eef 100644
--- a/doc/usenix-security-2025/paper/threats.tex
+++ b/doc/usenix-security-2025/paper/threats.tex
@@ -1,4 +1,6 @@
-\section{Threat Analysis}\label{sec:threats}
+\subsection{Money laundering}\label{sec:threats}
+
+\ifodd0
The presented protocol is using similar cryptographic constructions as
the GNU Taler payment system itself, primarily blind signatures and
@@ -6,6 +8,7 @@ regular signatures. However, it does not use the ``refresh''
protocol
of GNU Taler, as there is no need to render change. As a result, the
Donau protocol suffers from a subset of the threats from quantum
computing.~\cite{lange2024}
+\fi
A new Donau-specific threat is that donations could be used for
laundering criminal assets. This does not mean that we expect
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
- [donau] branch master updated (aa84bf3 -> 351b824),
gnunet <=
- [donau] 02/10: typo fix, gnunet, 2025/01/22
- [donau] 01/10: start of additional references, gnunet, 2025/01/22
- [donau] 03/10: this is too chatty for the definition environment and it was the only definiion, put citations with the thing they are being cited for, gnunet, 2025/01/22
- [donau] 06/10: spell checking and general read through, gnunet, 2025/01/22
- [donau] 05/10: changed to donau service and agreed on removing tax authority when not needed, gnunet, 2025/01/22
- [donau] 07/10: tricky with anonymous link and sounds misleadingly alarming, gnunet, 2025/01/22
- [donau] 08/10: linking in appendix, removing URLs that could violate anoymity, gnunet, 2025/01/22
- [donau] 04/10: adding example for blind signatures, wording, gnunet, 2025/01/22
- [donau] 09/10: the threat section was covering only ethical aspects, so moved into ethics part to save some space, gnunet, 2025/01/22
- [donau] 10/10: adding code listings & commitment for aritfact, gnunet, 2025/01/22