gnunet-svn
[Top][All Lists]
Advanced

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

[taler-docs] branch master updated: be more specific at certain places


From: gnunet
Subject: [taler-docs] branch master updated: be more specific at certain places
Date: Sat, 16 Oct 2021 16:27:40 +0200

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

oec pushed a commit to branch master
in repository docs.

The following commit(s) were added to refs/heads/master by this push:
     new beb9d6a  be more specific at certain places
beb9d6a is described below

commit beb9d6a804a6889f8a1f1de2932e237f5b2f7f8a
Author: Özgür Kesim <oec-taler@kesim.org>
AuthorDate: Sat Oct 16 16:27:36 2021 +0200

    be more specific at certain places
---
 design-documents/024-age-restriction.rst | 49 +++++++++++++++++++-------------
 1 file changed, 29 insertions(+), 20 deletions(-)

diff --git a/design-documents/024-age-restriction.rst 
b/design-documents/024-age-restriction.rst
index d40b267..725d172 100644
--- a/design-documents/024-age-restriction.rst
+++ b/design-documents/024-age-restriction.rst
@@ -77,25 +77,26 @@ The main ideas are simple:
 
 #. A **restricted** *age commitment* **to age group m** is derived from an 
unrestricted age
    commitment by removing all private keys for indices larger than m:
-   :math:`\bigl\langle (p_1, s_1), \ldots, (p_m, s_m), \, (p_{m+1}, \perp), 
\ldots, (p_M, \perp )\bigr\rangle`
+   :math:`\bigl\langle (p_1, s_1), \ldots, (p_m, s_m), \, (p_{m+1}, \perp),
+   \ldots, (p_M, \perp )\bigr\rangle`.  The act of restricting an unrestricted
+   age commitment is performed by the parent/ward.
 
 #. An *age commitment* (without prefix) is just the vector of public keys:
-   :math:`\langle p_1, \ldots, p_M \rangle`.  Note that from just the age
-   commitment one can not deduce if it was originated from an unrestricted or
-   restricted age commitment (and what age).
+   :math:`\vec{Q} := \langle p_1, \ldots, p_M \rangle`.  Note that from
+   just the age commitment one can not deduce if it was originated from an
+   unrestricted or restricted age commitment (and what age).
 
-#. An *attestation of age group k* is essentially the act of signing a message
+#. An *attestation of age group k* is essentially the signature to any message
    with the private key for slot k, if the corresponding private key is
-   available in a restricted age commitment.  (Unrestricted age commitments
-   can attest for any age group).
+   available in a restricted age commitment.  (Unrestricted age commitments can
+   attest for any age group).
 
 #. An age commitment is *bound to a particular coin* by incorporating the
    SHA512 hash value of the age commitment (i.e. the M public keys) into the
-   signature of the coin.  So instead of using :math:`\text{FDH}_N(C_p)` (with
-   :math:`C_p` being the public key of the coin), we calculate 
-   :math:`\text{FDH}_N(C_p, h_a)`, where :math:`h_a` is the
-   hash of the age commitment.
-
+   signature of the coin.  So instead of signing :math:`\text{FDH}_N(C_p)` with
+   the RSA private key of a denomination with support for age restriction, we
+   sign :math:`\text{FDH}_N(C_p, h_a)`.  Here, :math:`C_p` is the EdDSA public
+   key of a coin and :math:`h_a` is the hash of the age commitment.
 
 TODO: Summarize the design based on the five functions ``Commit()``,
 ``Attest()``, ``Verify()``, ``Derive()``, ``Compare()``, once the paper from
@@ -149,10 +150,9 @@ If age-restriction is registered as an extension under the 
name
 ``age_restriction.v1``, as described above, the root-object
 ``ExchangeKeysResponse`` in response to ``/keys`` MUST be extended by an
 additional field ``age_restricted_denoms``.  This is an *additional* list of
-denominations that must be used for during modified ``refresh`` and ``deposit``
+denominations that must be used during the modified ``refresh`` and ``deposit``
 operations (see below).
 
-
 The data structure for those denominations is the same as for the regular ones
 in ``ExchangeKeysResponse.denoms``.  **However**, the following differences
 apply for each denomination in the list:
@@ -204,6 +204,11 @@ changed since the given timestamp.
 SQL changes
 -----------
 
+The exchange has to mark denominations with support for age restriction as such
+in the database.  Also, during the melting phase of the refresh operation, the
+exchange will have to persist the SHA512 hash of the age commitment of the
+original coin.
+
 The schema for the exchange is changed as follows:
 
 .. sourcecode:: sql
@@ -260,19 +265,23 @@ restriction).  Therefore, in the 
``/coins/$COIN_PUB/melt`` POST request, the
 
 The responses to the POST request remain the same.
 
-For denominations *without* support for age restriction, the calculation for
-the signature check is as before (borrowing notation from 
+For normal denominations *without* support for age restriction, the calculation
+for the signature check is as before (borrowing notation from 
 `Florian's thesis <https://taler.net/papers/thesis-dold-phd-2019.pdf>`_):
 
 .. math::
-   \text{FDH}(N_0, C_p^{(0)})\; \stackrel{?}{=}\; 
\left(\sigma_C^{(0)}\right)^{e_0} \;\;\text{mod}\,N_0
+   \text{FDH}_N(C_p)\; \stackrel{?}{=}\; \left(\sigma_C\right)^{e} 
\;\;\text{mod}\,N
+
+Here, :math:`C_p` is the EdDSA public key of a coin, :math:`\sigma_C` is its
+signature and :math:`\langle e, N \rangle` is the RSA public key of the
+denomination.
 
-For denominations **with** support for age restriction, the exchange takes the
-hash value ``age_commitment_hash`` (abbreviated as h\ :sub:`a`) into account
+For denominations *with* support for age restriction, the exchange takes the
+hash value ``age_commitment_hash`` (abbreviated as :math:`h_a`) into account
 when verifying the coin's signature:
 
 .. math::
-   \text{FDH}(N_0, \langle C_p^{(0)}, h_a \rangle )\; \stackrel{?}{=}\; 
\left(\sigma_C^{(0)}\right)^{e_0} \;\;\text{mod}\,N_0
+   \text{FDH}_N(C_p, h_a)\; \stackrel{?}{=}\; \left(\sigma_C\right)^{e} 
\;\;\text{mod}N
 
 
 

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