gnunet-svn
[Top][All Lists]
Advanced

[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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]