gnunet-svn
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[taler-donau] branch master updated: Removing useless definitions (hash


From: gnunet
Subject: [taler-donau] branch master updated: Removing useless definitions (hash functions and digital signatures)
Date: Thu, 09 Jan 2025 17:46:58 +0100

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

emmanuel-benoist pushed a commit to branch master
in repository donau.

The following commit(s) were added to refs/heads/master by this push:
     new 2d39872  Removing useless definitions (hash functions and digital 
signatures)
2d39872 is described below

commit 2d39872419c67101253c50d4fdc596b601400c5b
Author: Emmanuel Benoist <emmanuel.benoist@bfh.ch>
AuthorDate: Thu Jan 9 17:46:41 2025 +0100

    Removing useless definitions (hash functions and digital signatures)
---
 doc/usenix-security-2025/paper/donau-paper.pdf     | Bin 855212 -> 851904 bytes
 doc/usenix-security-2025/paper/donau-paper.tex     |  77 ++++++++++++++-------
 doc/usenix-security-2025/paper/requirements.tex    |   3 -
 doc/usenix-security-2025/paper/technicaldesign.tex |  76 ++++++++++----------
 4 files changed, 88 insertions(+), 68 deletions(-)

diff --git a/doc/usenix-security-2025/paper/donau-paper.pdf 
b/doc/usenix-security-2025/paper/donau-paper.pdf
index 68e656e..94caac1 100644
Binary files a/doc/usenix-security-2025/paper/donau-paper.pdf and 
b/doc/usenix-security-2025/paper/donau-paper.pdf differ
diff --git a/doc/usenix-security-2025/paper/donau-paper.tex 
b/doc/usenix-security-2025/paper/donau-paper.tex
index 0c68837..595a432 100644
--- a/doc/usenix-security-2025/paper/donau-paper.tex
+++ b/doc/usenix-security-2025/paper/donau-paper.tex
@@ -1,3 +1,9 @@
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+% TODO : 
+% - Reduce the size to 13 pages for the main text (excluding
+% bibliography)
+% - Add some bibliographical references (for the motivation).
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 %\documentclass{taler}       % full lenth boiler plate
 %\documentclass{taler-short} % for short deliverables with less boiler plate
 \documentclass[letterpaper,twocolumn,10pt]{article}
@@ -17,7 +23,7 @@
 %\wpcontrib{WP3}
 %don't want date printed
 \date{}
-\title{\Large \bf Design for Donations}
+\title{\Large \bf Design of a privacy friendly tax deduction system for 
donations}
 %\duedate{30 November 2024}
 %\actualdate{\today}
 %\version{Revision 1.0}
@@ -27,25 +33,49 @@
 %   Leenaars, Jonathan Levin}
 
 \author{
-{\rm Bob Goudriaan}\\
-NLnet Foundation
-\and
-{\rm Chrsitian Grothoff}\\
-Bern University of Applied Sciences
-\and
-{\rm Tanja Lange}\\
-Technical University of Eindhoven
-\and
-{\rm Michiel Leenaars}\\
-NLnet Foundation
-\and
-{\rm Jonathan Levin}\\
-XXXXX
-% copy the following lines to add more authors
+{\rm Anonymous}\\
+Anonymized Institution
+\and 
+{\rm Anonymous}\\
+Anonymized Institution
+\and 
+{\rm Anonymous}\\
+Anonymized Institution
+\and 
+{\rm Anonymous}\\
+Anonymized Institution
+\and 
+{\rm Anonymous}\\
+Anonymized Institution
+\and 
+{\rm Anonymous}\\
+Anonymized Institution
+\and 
+{\rm Anonymous}\\
+Anonymized Institution
+\and 
+{\rm Anonymous}\\
+Anonymized Institution
+}
+
+
+
+% \author{
+% {\rm Bob Goudriaan}\\
+% NLnet Foundation
+% \and 
+% {\rm Chrsitian Grothoff}\\
+% Bern University of Applied Sciences
+% \and
+% {\rm Tanja Lange}\\
+% Technical University of Eindhoven
+% \and
+% {\rm Michiel Leenaars}\\
+% NLnet Foundation
 % \and
-% {\rm Name}\\
-%Name Institution
-} % end author
+% {\rm Jonathan Levin}\\
+% XXXXX
+% } % end author
 
 
 %\changetable{ % use 3 colum format as in these examples
@@ -60,13 +90,8 @@ XXXXX
 \maketitle
 
 \begin{abstract}
-  This report provides an overview of functional requirements for
-  privacy-preserving donations, keeping in mind the need for tax authorities to
-  verify the proper source of donations prior to granting tax benefits. As a
-  second contribution it provides a technical design to realize
-  privacy-preserving and yet tax-deductable donations in GNU Taler, for which
-  it presents the protocol specification and implementation details for the
-  Donation Authority (Donau).
+  This paper provides an overview of functional requirements for
+  privacy-preserving donations, keeping in mind the need for tax authorities 
to verify the proper source of donations prior to granting tax benefits. As a 
second contribution it provides a technical design to realize 
privacy-preserving and yet tax-deductable donations in GNU Taler, for which it 
presents the protocol specification and implementation details for the Donation 
Authority (Donau).
 \end{abstract}
 
 %\reportkeywords{GNU Taler, Tax-deductible Donations. Donau, Donation 
Authority,
diff --git a/doc/usenix-security-2025/paper/requirements.tex 
b/doc/usenix-security-2025/paper/requirements.tex
index e07d47e..ca57d13 100644
--- a/doc/usenix-security-2025/paper/requirements.tex
+++ b/doc/usenix-security-2025/paper/requirements.tex
@@ -4,9 +4,6 @@ The starting point of this document is to create an initial 
overview of requirem
 
 Tax authorities are creative, and taxation is an ever evolving area of 
complexity. We will therefore not claim to provide the definitive overview, but 
to provide a good start for bootstrapping a donation ecosystem in the full 
knowledge that this will need to be updated.
 
-Subsequent deliverables (D3.5 and D3.6) may prioritize different properties and
-features or add further requirements on the design.
-
 \subsection{Assumptions}
 
 The basic assumptions when defining requirements for a donation flow are as 
follows:
diff --git a/doc/usenix-security-2025/paper/technicaldesign.tex 
b/doc/usenix-security-2025/paper/technicaldesign.tex
index 7c771bb..164552d 100644
--- a/doc/usenix-security-2025/paper/technicaldesign.tex
+++ b/doc/usenix-security-2025/paper/technicaldesign.tex
@@ -46,44 +46,43 @@ some cryptographic background followed by the setup and 
usage.
  This section gives an informal introduction to some concepts from cryptography
 which are used later in the report.
 
- \begin{itemize}
-   \item \textbf{Cryptographic Hash Function}
-     A cryptographic hash function $H$ is a function that takes as input an 
arbitrarily
-long bit string
-     and returns a fixed-length output string, which satisfies some security
-requirements. In formulas
-$$H: \{0,1\}^* \rightarrow \{0,1\}^n, m \mapsto h = H(m).$$
-The function $H$ should provide preimage resistance, that means that
-it should be infeasible to find an input that hashes to a given output. It
-should also provide second-preimage resistance, that means that it should be
-infeasible to find a second input that maps to the same output as a given 
input.
-Even more restricting, it should provide collision resistance, meaning that it
-should be infeasible to find two inputs that hash to the same output (without
-any other restriction).
-
-     Sometimes a hash function gets used in a scenario where the natural input
-values come from a small, easily guessable set, like passwords or PINs.
-In this scenario an attacker could break preimage resistance by just iterating
-through all possible inputs to find the matching one and, worse, could even
-store all resulting hash values in a big table for instant preimage lookups for
-all users. One partial fix is to {\bf salt} the hash, i.e., to add a random
-suffix or prefix to the input before hashing it. Applications then need to
-store the salt as well. If the salt can be kept private this stops the simple
-preimage attacks, otherwise it at least requires the attacker to try all inputs
-{\em per targeted hash}. We write a {\bf salted hash} as $h = H(m, s)$, where
-$s$ is the salt value.
-
-   \item \textbf{Digital Signatures}
-
-     A digital signature is a cryptographic scheme for authenticating a 
message or document, analogous to a handwritten signature.
-     A signer creates a public/private keypair.
-     The private signing key is used to generate a signature on a message.
-     The public key is distributed, and can be used by anybody to verify the 
authenticity of the signature.
-     A signature scheme is secure if, among other things, the private key 
cannot be computed from the public key and if
-     nobody can generate a signature that verifies for some message under a
-public key if they do not have access to the matching private key.
-
-   \item \textbf{Blind Signature}
+%    \paragraph{Cryptographic Hash Function}
+%      A cryptographic hash function $H$ is a function that takes as input an 
arbitrarily
+% long bit string
+%      and returns a fixed-length output string, which satisfies some security
+% requirements. In formulas
+% $$H: \{0,1\}^* \rightarrow \{0,1\}^n, m \mapsto h = H(m).$$
+% The function $H$ should provide preimage resistance, that means that
+% it should be infeasible to find an input that hashes to a given output. It
+% should also provide second-preimage resistance, that means that it should be
+% infeasible to find a second input that maps to the same output as a given 
input.
+% Even more restricting, it should provide collision resistance, meaning that 
it
+% should be infeasible to find two inputs that hash to the same output (without
+% any other restriction).
+
+%      Sometimes a hash function gets used in a scenario where the natural 
input
+% values come from a small, easily guessable set, like passwords or PINs.
+% In this scenario an attacker could break preimage resistance by just 
iterating
+% through all possible inputs to find the matching one and, worse, could even
+% store all resulting hash values in a big table for instant preimage lookups 
for
+% all users. One partial fix is to {\bf salt} the hash, i.e., to add a random
+% suffix or prefix to the input before hashing it. Applications then need to
+% store the salt as well. If the salt can be kept private this stops the simple
+% preimage attacks, otherwise it at least requires the attacker to try all 
inputs
+% {\em per targeted hash}. We write a {\bf salted hash} as $h = H(m, s)$, where
+% $s$ is the salt value.
+
+%    \paragraph{Digital Signatures}
+
+%      A digital signature is a cryptographic scheme for authenticating a 
message or document, analogous to a handwritten signature.
+%      A signer creates a public/private keypair.
+%      The private signing key is used to generate a signature on a message.
+%      The public key is distributed, and can be used by anybody to verify the 
authenticity of the signature.
+%      A signature scheme is secure if, among other things, the private key 
cannot be computed from the public key and if
+%      nobody can generate a signature that verifies for some message under a
+% public key if they do not have access to the matching private key.
+
+   \paragraph{Blind Signature}
 
      A \textbf{blind signature} is a type of digital signature where the
 signing party signs a so-called blinded message. The party requesting the 
signature
@@ -103,7 +102,6 @@ $\beta = \unblind(\overline{\beta}, b, K_x^{\pub})$,
 where $\overline{\beta}$ is the value to unblind, $b$ the blinding factor to
 apply and $K_x^{\pub}$ the public key that was used for signing.
 
- \end{itemize}
 
 \subsection{Key generation and initial 
setup}\label{key_generation_and_initial_setup}
 

-- 
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]