[donau] branch master updated: work on section 5

[gnunet]

This is an automated email from the git hooks/post-receive script.

grothoff pushed a commit to branch master
in repository donau.

The following commit(s) were added to refs/heads/master by this push:
     new fe34a84  work on section 5
fe34a84 is described below

commit fe34a84575dcf325a0f1862a7bdca076ac8aad5b
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Wed Jan 22 19:45:45 2025 +0100

    work on section 5
---
 doc/usenix-security-2025/paper/bibliography.bib |  44 ++++-
 doc/usenix-security-2025/paper/discussion.tex   | 236 ++++++++++++++----------
 2 files changed, 179 insertions(+), 101 deletions(-)

diff --git a/doc/usenix-security-2025/paper/bibliography.bib 
b/doc/usenix-security-2025/paper/bibliography.bib
index 1579ba4..f0bb490 100644
--- a/doc/usenix-security-2025/paper/bibliography.bib
+++ b/doc/usenix-security-2025/paper/bibliography.bib
@@ -221,6 +221,13 @@ pages = {256-276},
 year = {2015}
 }
 
+@PhdThesis{taler2019dold,
+  author =       {Florian Dold},
+  title =        {The GNU Taler System: Practical and Provably Secure 
Electronic Payments},
+  school =       {University of Rennes 1},
+  year =         {2019},
+}
+
 @article{welling1989smurfs,
   title={Smurfs, money laundering, and the federal criminal law: the crime of 
structuring transactions},
   author={Welling, Sarah N},
@@ -238,4 +245,39 @@ year = {2015}
   volume={1},
   pages={5--27},
   year={2015}
-}
\ No newline at end of file
+}
+
+@article{abc,
+        title =         {The ABC of ABC: An analysis of attribute-based 
credentials in the light of data protection, privacy and identity},
+        author =        {Koning, Merel and Korenhof, Paulan and Alp{\'a}r, 
Gergely and Hoepman, Jaap-Henk},
+        year =          {2014},
+        journal =       {Proc. 10th International Conf. on Internet, Law \& 
Politics},
+         pages =         {357-374},
+}
+
+@INPROCEEDINGS{hasini2016unlinkableeid,
+  author={Gunasinghe, Hasini and Bertino, Elisa},
+  booktitle={2016 IEEE 2nd International Conference on Collaboration and 
Internet Computing (CIC)},
+  title={RahasNym: Pseudonymous Identity Management System for Protecting 
against Linkability},
+  year={2016},
+  pages={74-85},
+}
+
+@InProceedings{esorics2022age,
+ author="Kesim, {\"O}zg{\"u}r and Grothoff, Christian and Dold, Florian and 
Schanzenbach, Martin",
+ title="Zero-Knowledge Age Restriction for GNU Taler",
+ booktitle="Computer Security -- ESORICS 2022",
+ year="2022",
+ publisher="Springer International Publishing",
+ address="Cham",
+ pages="110--129",
+}
+
+@inproceedings{mixminion,
+ author = {Danezis, George and Dingledine, Roger and Mathewson, Nick},
+ title = {Mixminion: Design of a Type III Anonymous Remailer Protocol},
+ booktitle = {Proceedings of the 2003 IEEE Symposium on Security and Privacy},
+ series = {SP '03},
+ year = {2003},
+ isbn = {0-7695-1940-7},
+}
diff --git a/doc/usenix-security-2025/paper/discussion.tex 
b/doc/usenix-security-2025/paper/discussion.tex
index b50f66d..d3ebecd 100644
--- a/doc/usenix-security-2025/paper/discussion.tex
+++ b/doc/usenix-security-2025/paper/discussion.tex
@@ -24,8 +24,8 @@ deductable donations.
 
 If the purpose of the registration is to limit charities to only accept money
 from registered donors additional components need to be added. The
-cryptographic concept of attribute-based credentials can be used to build a
-suitable functionality.
+cryptographic concept of attribute-based credentials~\cite{abc}
+can be used to build a suitable functionality.
 When a donor registers, they are provided a credential to prove that they are
 registered. When donating to a
 charity, the donor uses their credential to sign their donation. The charity 
checks
@@ -47,7 +47,7 @@ a discussion of threats.)
 
 Given that only few countries require donor registration and we
 consider this a requirement that hampers charities, we chose not to include
-this feature in our design.
+this feature in our core design.
 
 
 
@@ -74,25 +74,27 @@ the signature and to keep all donations and signatures, in 
order to decline furt
 donation attempts by donors who have reached their limit.
 
 As a practical instantiation it is conceivable to combine the Donau
-protocol with an EID solution that provides some unlinkable
-pseudonym derived from the donor's main identity. The unlinkable
-pseudonym could be unique to the donor, charity and time period.
+protocol with an eID solution that provides some unlinkable
+pseudonym derived from the donor's main 
identity~\cite{hasini2016unlinkableeid}.
+The unlinkable pseudonym could be unique to the donor,
+charity and time period.
 By signing the donation process with such an unlinkable pseudonym
-it is possible to prevent smurfing donations, alas at the expense
+it is possible to prevent smurfing donations~\cite{welling1989smurfs},
+alas at the expense
 of reducing anonymity to pseudonymity.
 
-As discussed above in section~\ref{discussion:registration}, the signature on
+As discussed above in Section~\ref{discussion:registration}, the signature on
 the donation does not guarantee that the $\DI$ hidden in the BKPs matches that
 of the signer.
 
 \subsection{Feature: Notarized affidavit}
 
 GNU Taler already supports privacy-preserving age-restrictions on
-payments, thus it would be trivial to prove that the donor is of
+payments~\cite{esorics2022age}, thus it would be trivial to prove that the 
donor is of
 legal age as part of the payment process (without disclosing any
 further information). In general, including other attestations may
 be possible, but is likely to be highly problematic from a privacy
-point of view. Not to mention that birthrates are commonly recorded
+point of view. Not to mention that birthdates are commonly recorded
 and thus age can be easily attested by the payment service provider,
 other types of attestations would require building the corresponding
 certification infrastructure.
@@ -100,23 +102,28 @@ certification infrastructure.
 
 \subsection{Feature: Unique ID for donor advised decisions}
 
-Issuing tokens to advise decisions would be part of the donation contract.
-The donation process could return such a token in addition to the donation
-receipt to enable the donor to vote, similar to the discount and subscription
-tokens already proposed for GNU Taler.
-
-An inherent feature of the Donau protocol is that the
-donor has the private keys of the coins used to make a donation,
-and thus inherently a feature that could be used to advise
-decisions.
-
-Limiting decisions to one per donor
-instead of proportional to the amount donated is more complex,
-as it would require a solution similarly to enforcing cumulative limits per
-donor as discussed in section~\ref{discussion:limit}.
-
-The main challenge in both scenarios would be to find a way to inform
-the anonymous donors when their input is solicited.
+One way to enable donors to advise decisions without being linked to
+the specific dontation would be for the donation process to return
+blindly signed e-voting tokens (in addition to the donation receipt)
+to enable the donor to vote. This would be similar to the discount and
+subscription tokens already proposed for GNU Taler.
+
+Alternatively, if advise should be linked to a specific donation, one
+could build on an inherent feature of the GNU Taler protocol which is
+that the donor signs with private keys of digital coins to pay for a
+donation.  Creating additional signatures the same private coin keys
+could also be used to advise decisions while providing a clear link to
+a specific donation.
+
+Limiting decisions to one per donor instead of proportional to the
+amount donated is more complex, as it would require a solution
+similarly to enforcing cumulative limits per donor as discussed in
+Section~\ref{discussion:limit}.
+
+A shared practical challenge independent of the cryptographic solution
+is to find a good way to inform anonymous donors when their input is
+solicited. In theory, anonymous remailers~\cite{mixminion} could be
+used for this purpose.
 
 \subsection{Feature: Compound weighted donation}
 
@@ -136,62 +143,83 @@ and always shown to the payer, ensuring cost 
transparency. The
 design does not require the use of additional parties beyond
 the payment system, donor and charity.  If fundraising parties
 are involved as well, their cuts could be easily made transparent
-in the GNU Taler contract terms used in the donation payment.
+in the GNU Taler contract terms used in the payment process.
 
 \subsection{Feature: Staged donation}\label{discussion:staged}
 
 Staged donations would require the payment service to hold funds in
 escrow until certain conditions are met (or refund them).  GNU Taler
-can already do refunds, and escrow of funds is a feature planned for
-the future.
-%TL: that is always a problem and not changed by using our solution.
-% One difficulty would be to establish an authority
-% that decides whether the conditions are met.
-
-The blinded donation receipts could similarly be held in escrow, released only
-when the next stage of funding is reached and the donation is released. A
-problem, however, is that the donor is anonymous and thus cannot be reached
-at the time that later goals are met.
-
-A solution is for the charity to further blind or encrypt the Donau signatures
-and to publicly post the keys when the next stage of funding is reached and the
-donation becomes effective. In the following we assume that the donation is
-split up by funding stage and that the donor submitted an array of BKPs per
-funding stage, so
-$\vec{\mu_j} = (\bar{\mu}_{j1}, \bar{\mu}_{j2}, \ldots)$ is the array of BKPs 
for
-funding stage $j$.
-To make the multitude of keys manageable, the charity uses a random string
-$t_j$ per funding stage and {\em encrypts} the Donau response
-$(\beta_{j1}, \beta_{j2}, \ldots)$ for the stage $j$ payments
-with $H(t_j, \vec{\mu_j})$. The encrypted Donau responses (one per stage) are
-returned to the donor at the time of donation instead of the plaintext Donau
-response.
-
-When work progresses to reach
-stage $j$ and the donation payments are collected, the charity posts $t_j$
-publicly. Every donor can then compute the key $H(t_j, \vec{\mu_j})$ and 
decrypt
-their donation receipts for stage $j$. This requires the donor to store the 
BKPs along with
-the encrypted donation receipts until stage $j$ is reached and $t_j$ is
-released. It requires the charity to have a bulletin board for posting $t_j$
-but charities soliciting staged donations typically post extensive progress
-reports justifying them declaring success on the previous stage and this report
-should then link to the key $t_j$.
+can already do refunds (without infringing on the privacy of the
+donor~\cite{taler2019dold}), and {\em escrow of funds} is a feature
+planned for the future. Escrow means that the payment service provider
+is responsible for releasing the funds to the charity only when
+contractually specified conditions are met (likely attested by some
+trusted third party), and otherwise the funds are refunded to the
+donor.
+
+As with other donations, the donor would create blinded donation
+receipts upon payment, matching the amounts to the various stages.
+However, the blinded donation receipts would only be requested from
+the Donau once the funds are released to the charity from escrow.
+Instead of using an anonymous remailer, the nature of a staged
+donation allows the wallet software to be informed at what times it
+should periodically contact the charity server to request a status
+update on the project. Here, the wallet can easily identify itself as
+the donor using the private coin keys.  Depending on the project's
+progress the charity would then request blinded donation receipts
+from the Donau and return those to the wallet, or the wallet would
+receive a refund from the payment service provider.
+
+%
+%A problem, however, is that the donor is anonymous and thus cannot be reached
+%at the time that later goals are met.
+%
+%A solution is for the charity to further blind or encrypt the Donau signatures
+%and to publicly post the keys when the next stage of funding is reached and 
the
+%donation becomes effective. In the following we assume that the donation is
+%split up by funding stage and that the donor submitted an array of BKPs per
+%funding stage, so
+%$\vec{\mu_j} = (\bar{\mu}_{j1}, \bar{\mu}_{j2}, \ldots)$ is the array of BKPs 
for
+%funding stage $j$.
+%To make the multitude of keys manageable, the charity uses a random string
+%$t_j$ per funding stage and {\em encrypts} the Donau response
+%$(\beta_{j1}, \beta_{j2}, \ldots)$ for the stage $j$ payments
+%with $H(t_j, \vec{\mu_j})$. The encrypted Donau responses (one per stage) are
+%returned to the donor at the time of donation instead of the plaintext Donau
+%response.
+%
+%When work progresses to reach
+%stage $j$ and the donation payments are collected, the charity posts $t_j$
+%publicly. Every donor can then compute the key $H(t_j, \vec{\mu_j})$ and 
decrypt
+%their donation receipts for stage $j$. This requires the donor to store the 
BKPs along with
+%the encrypted donation receipts until stage $j$ is reached and $t_j$ is
+%released. It requires the charity to have a bulletin board for posting $t_j$
+%but charities soliciting staged donations typically post extensive progress
+%reports justifying them declaring success on the previous stage and this 
report
+%should then link to the key $t_j$.
 
 \subsection{Feature: Bandwidth donations}
 
-If the donated amount is to shrink based on certain conditions the design
-discussed in section~\ref{discussion:staged} can be adopted. Here is a simple
-example where the final contribution of each donor is proportional to their
-maximum pledge: Each
-donation is composed of some fixed number $N$ of equal shares. During the
-period that the charity is soliciting funding all donations are held in escrow.
-Donors receive $N$ encrypted Donau responses (one per share). Once the funding
-period ends, the total sum of pledges is known. Let the fraction $a/N$ of the
-total suffice for the funding goal of the charity. The charity then posts the
-first $a$ keys $t_j$, unlocking the Donau responses for the effectively
-donated part, and receives the share of $a/N$ of the pledged donations from
-escrow. The remaining $(N-a)/N$ shares of the donations are returned to the
-donors, e.g., by voiding the contracts that spent them.
+To support bandwidth donations, the donated amount may shrink based on
+independent donations to the same charity by other parties and some
+allocation rule.  This can also be achieved via the design discussed
+in Section~\ref{discussion:staged}. As before, during the period that
+the charity is soliciting funding, all donations would be held in
+escrow.
+
+Once the funding period ends, all pledges are publicly posted (say by
+the charity) allowing the wallets to (1) confirm that their pledge was
+properly included, (2) compute the total amount pledged, (3) compute
+their share based on some previously agreed allocation rule, and (4)
+to finally collect the resulting amount of donation receipts and
+refunds.
+
+A minor limitation here is that the donor should probably be required
+to create blinded donation receipts at the time of the donation to
+avoid enabling them to change the taxpayer ID at a later time. This
+means that the granularity of the final allocations is fixed when the
+donations are made, slightly limiting the flexibility of the
+allocation rule algorithm.
 
 \subsection{Feature: Code of conduct}
 
@@ -206,9 +234,8 @@ would grant them access to additional information.
 
 \subsection{Feature: Unlock thank you artwork}
 
-The GNU Taler protocol can already be used to buy digital goods.
-While we are usually thinking about newspaper articles or videos,
-this can of course also include images or audio resources. Thus,
+The GNU Taler protocol can already be used to buy digital goods,
+including newspaper articles, videos, images or audio resources. Thus,
 this can easily be done by using the payment process to authorize
 bypassing what in a commercial setting would be called a paywall.
 
@@ -217,7 +244,7 @@ compatible with the anonymity feature. However, there is 
nothing in the design
 that stops the charity and donor from exchanging address information during the
 donation process.
 
-\subsection{Feature: Donation matching with a reference}
+\subsection{Feature: Donation matching with a reference}\label{sec:matching}
 
 Donation matching is an agreement between the charity and a matching donor.
 The charity can show proof of the payments received; if these are done using
@@ -227,28 +254,37 @@ charity can prove to the match funder that they received a
 certain amount of donations, and they can even include the
 contract terms to show that the donors intended to participate
 in the match funding project.
-This requires that the match funder is not active in the considered donation
-period or that they subtract their own donations from the total.
 
-Both donor and match funder can in principle share their
-donation receipts publicly to advertise their good deed, but they then of 
course
-void their anonymity.
+Similarly, a match funder could escrow their donation at the payment
+service provider, only to be released to the charity once matching
+donations have been made. The deposit confirmation on the escrowed
+donation can then be used to convince potential donors that the match
+funding is real.
+
+Both donor and match funder can in principle share their final
+donation receipts publicly to advertise their good deed, but they then
+of course void their anonymity.
 
 \subsection{Feature: Anonymous donation matching by employer}
 
-Technical solutions can be similar to what is discussed in
-section~\ref{discussion:registration}.
-
-A simple solution if the match funder is a company with a taxpayer ID known to
-their employees and the match funder knows the donors' taxpayer IDs (as is
-common in an employment scenario) is to use that donations in the Donau system
-do not prove that the donation is made by the taxpayer with {\tt TAXID} as
-follows: The donor donates
-the full amount (their contribution as well as the match
-funding) to the charities of their choice, where they include their own $\DI$ 
in
-half of the amount and one derived from the {\tt TAXID} of their employer in
-the other half. Then they show the donation receipts for both halves to the 
match
-funder. The match funder can verify validity of both receipts and that the
-proportion of their match is correct. They then refund the amount that was 
donated
-on their behalf to the employee and use the donation receipt for their {\tt
-TAXID} when filing their tax statement.
+Donation matching by employer could be achieved by combining approaches
+similar to what was discussed in Section~\ref{discussion:registration}
+and Section~\ref{sec:matching}.
+
+If the match funder is a company with a taxpayer ID known to their
+employees and the employer knows the donors' taxpayer IDs (as is
+common in an employment scenario) there is a simpler approach.  This
+approach exploits the loophole that donations in the Donau system do
+not prove that the donation is actually made by the taxpayer with the
+{\tt TAXID}.
+
+Thus, it is possible for the employee to simply donate the full amount
+(their contribution as well as the match funding) to the charities of
+their choice, but to include their own $\DI$ in half of the amount and
+one derived from the {\tt TAXID} of their employer in the other
+half. Then they show the donation receipts for both halves to the
+match funder. The match funder can verify validity of both receipts
+and that the proportion of their match is correct. They then pay back
+the amount that was donated on their behalf to the employee and use
+the donation receipt for their {\tt TAXID} when filing their tax
+statement.

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.