[taler-docs] branch master updated: added ZK-proof for age restriction for withdrawal

[gnunet]

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 16f9650  added ZK-proof for age restriction for withdrawal
16f9650 is described below

commit 16f9650166b6f2163e86d6e7f9f4ce49d23bb093
Author: Özgür Kesim <oec-taler@kesim.org>
AuthorDate: Tue Dec 20 13:56:34 2022 +0100

    added ZK-proof for age restriction for withdrawal
---
 design-documents/024-age-restriction.rst | 145 +++++++++++++++++++++++--------
 1 file changed, 107 insertions(+), 38 deletions(-)

diff --git a/design-documents/024-age-restriction.rst 
b/design-documents/024-age-restriction.rst
index b394a42..ce1e130 100644
--- a/design-documents/024-age-restriction.rst
+++ b/design-documents/024-age-restriction.rst
@@ -29,8 +29,6 @@ optional feature that can be switched on by the exchange 
operator.
 Requirements
 ============
 
-TODO
-
 * legal requirements for merchants must allow for this kind of mechanism
 
 
@@ -55,7 +53,9 @@ protocol, that gives the minor/ward a 1/κ chance to raise the 
minimum age for
 the new coin).
 
 The proposed solution maintains the guarantees of GNU Taler with respect to
-anonymity and unlinkability. (TODO: refer to the paper, once published)
+anonymity and unlinkability.  We have published a paper 
+`Zero Knowledge Age Restriction for GNU Taler 
<https://link.springer.com/chapter/10.1007/978-3-031-17140-6_6>`_
+with the details.
 
 ¹) Once the feature is enabled and the age groups are defined, the exchange has
 to stick to that decision until the support for age restriction is disabled.
@@ -65,31 +65,32 @@ We might reconsider this design decision at some point.
 Main ideas and building blocks
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-The main ideas are simple:
+The main ideas are as follows:
 
 #. The exchange defines and publishes M+1 different *age groups* of increasing
    order: :math:`0 < a_1 < \ldots < a_M` with :math:`a_i \in \mathbb{N}`.  The
    zeroth age group is :math:`\{0,\ldots,a_1-1\}`.
 
-#. An **unrestricted** *age commitment* is defined as a vector of length M of
+#. An **unrestricted age commitment** is defined as a vector of length M of
    pairs of Edx25519_ public and private keys on Curve25519. In other words: 
one
-   key pair for each age group after the zeroth:
-   :math:`\bigl\langle (p_1, s_1), \ldots, (p_M, s_M) \bigr\rangle`
+   key pair for each age group after the zeroth: :math:`\bigl\langle (q_1,
+   p_1), \ldots, (q_M, p_M) \bigr\rangle`.  Here, :math:`q_i` are the public 
keys
+   (mnemonic: **q-mitments**), :math:`p_i` are the private keys.
 
-#. A **restricted** *age commitment* **to age group m** (or m-th age group) 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`.
-   F.e. if *none* of the private keys is provided, the age commitment would be
-   restricted to the zeroth age group.
+#. 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 (q_1, p_1), \ldots, (q_m, p_m),
+   \, (q_{m+1}, \perp), \ldots, (q_M, \perp )\bigr\rangle`.  F.e. if *none* of
+   the private keys is provided, the age commitment would be restricted to the
+   zeroth age group.
 
 #. 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:`\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).
+   :math:`\vec{Q} := \langle q_1, \ldots, q_M \rangle`.  Note that from
+   just the age commitment one can not deduce if it originated from an
+   unrestricted or restricted one (and what age).
 
 #. 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
@@ -100,8 +101,13 @@ The main ideas are simple:
    SHA256 hash value of the age commitment (i.e. the M public keys) into the
    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.
+   sign :math:`\text{FDH}_N(C_p, h_Q)`.  Here, :math:`C_p` is the EdDSA public
+   key of a coin and :math:`h_Q` is the hash of the age commitment 
:math:`\vec{Q}`.
+   **Note:** A coin with age restriction can only be validated when both, the
+   public key of the coin itself **and** the hash of the age commitment, are
+   present.  This needs to be supported in each subsystem: Exchange, Wallet and
+   Merchant.
+
 
 TODO: Summarize the design based on the five functions ``Commit()``,
 ``Attest()``, ``Verify()``, ``Derive()``, ``Compare()``, once the paper from
@@ -193,12 +199,11 @@ in ``ExchangeKeysResponse.age_restricted_denoms``.
 Age restricted denominations
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-If age-restriction is registered as an extension under the name
-``age_restriction``, 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 during the modified ``refresh`` and ``deposit``
-operations (see below).
+If age-restriction is registered as extension ``age_restriction``, 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 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
@@ -248,7 +253,7 @@ changed since the given timestamp.
    }
 
 
-SQL changes
+SQL schema
 -----------
 
 The exchange has to mark denominations with support for age restriction as such
@@ -289,6 +294,79 @@ can not be expressed reliably with SQL.
 Protocol changes
 ----------------
 
+Withdraw
+~~~~~~~~
+
+The withdraw protocol is affected in the following situations:
+
+- A wire transfer to the exchange (to fill a reserve) was marked by the
+  originating bank as coming from a bank account of a minor, belonging to a of
+  a specific age group.
+- A wire transfer to the exchange was marked to be age-restricted by other
+  means (not yet designed or implemented)
+
+In these cases, the wallet will have to perform a zero-knowledge protocol with
+exchange as part of the the withdraw protocol, which we sketch here.  Let
+
+- :math:`\kappa` be the same cut-and-choose parameter for the refresh-protocol.
+- :math:`\Omega \in E` be a published, nothing-up-my-sleeve, constant
+  group-element on the elliptic curve.
+- :math:`a \in \{1,\ldots,M\}` be the maximum age (group) for which the wallet
+  has to prove its commitment.
+
+The values :math:`\kappa`, :math:`\Omega` and :math:`a` are known to the 
Exchange and the Wallet.
+
+Then:
+
+#. *Wallet*:
+
+   #. creates planchets :math:`\{C_i \mid i = 1,\ldots,\kappa\}` as candidates 
for *one* coin.
+   #. creates age-commitments :math:`\{ \vec{Q}^i \mid i = 1,\ldots,\kappa\}` 
as follows:
+
+      a) chooses randomly :math:`a`-many scalars :math:`\{p^i_j \mid j = 
1,\ldots,a\}`,
+      #) creates keypairs :math:`\{(p^i_j, q^i_j = p^i_j*G) \mid j = 
1,\ldots,a\}` for Edx25519,
+      #) chooses randomly :math:`(M - a)`-many scalars :math:`\{s^i_j \mid j = 
a+1,\ldots,M\}`,
+      #) calculates :math:`\{\omega^i_j = s^i_j*\Omega \mid j = a+1,\ldots,M 
\}`,
+      #) sets :math:`\vec{Q}^i := 
(q^i_1,\ldots,q^i_a,\omega^i_{a+1},\ldots,\omega^i_M)`
+
+   #. calculates :math:`\{ f_i := \text{FDH}(C_i, H(\vec{Q}^i)) \mid i = 
1,\ldots,\kappa \}`
+   #. chooses random blindings :math:`\beta_i(.), i = 1,\ldots,\kappa`, 
depending on the the cipher (RSA, CS).
+   #. calculates :math:`F := 
\text{H}(\beta_1(f_1)||\ldots||\beta_\kappa(f_\kappa))`
+   #. sends :math:`F` to the Exchange
+
+#. *Exchange*
+
+   #. receives and stores :math:`F`
+   #. chooses randomly :math:`\gamma \in \{1,\ldots,\kappa\}` and
+   #. sends :math:`\gamma` to the Wallet.
+
+#. *Wallet*
+
+   #. receives :math:`\gamma`
+   #. sends to the Exchange the tuple :math:`\left(r_\gamma, \vec{\beta}, 
\vec{\vec{Q}}, \vec{\vec{S}}\right)` with
+
+      - :math:`r_\gamma := \beta_\gamma(f_\gamma)`
+      - :math:`\vec{\beta} := 
(\beta^1,\ldots,\beta^{\gamma-1},\bot,\beta^{\gamma+1},\ldots,\beta^\kappa)`
+      - :math:`\vec{\vec{Q}} := 
(\vec{Q}^1,\ldots,\vec{Q}^{\gamma-1},\bot,\vec{Q}^{\gamma+1},\ldots,\vec{Q}^\kappa)`
+      - :math:`\vec{\vec{S}} := 
(\vec{S}^1,\ldots,\vec{S}^{\gamma-1},\bot,\vec{S}^{\gamma+1},\ldots,\vec{S}^\kappa)`
+        with :math:`\vec{S}^i := (s^i_j)`
+
+#. *Exchange*:
+
+   #. receives :math:`\left(r, (\beta^i), (\vec{Q}^i), (\vec{B}^i) \right)`
+   #. calculates :math:`g_i := \beta_i\left(\text{FDH}(\vec{Q}^i)\right)` for 
:math:`i \neq \gamma`
+   #. compares :math:`F \overset{?}{=} \text{H}(g_1||\ldots||g_{\gamma - 
1}||r||g_{\gamma+1}||\ldots||g_\kappa)` and bails out on inequality
+   #. for each :math:`\vec{B}^i, i \neq \gamma`
+
+      i. calculates :math:`\tilde{\omega}^i_j := b^i_j * \Omega` for :math:`j 
= a+1,\ldots,M`
+      #. compares each :math:`\tilde{\omega}^i_j` to :math:`q^i_j` from 
:math:`\vec{Q}^i = (q^i_1, \ldots, q^i_M)` and bails out on inequality
+   #. signs :math:`r`
+   #. sends signature :math:`\sigma_r` to Wallet
+
+
+
+
+
 Refresh - melting phase
 ~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -528,19 +606,14 @@ satisfy any minimum age requirement.
 Changes in the Wallet
 ^^^^^^^^^^^^^^^^^^^^^
 
-TODO.
-
-* choosing age-restriction during withdrawal coins from denominations with
-  support for age restriction.
-* Define protocol to pass denominations to child/ward.
-
+A wallet implementation SHOULD support denominations with age restriction.  In
+that case it SHOULD allow to select an age group as upper bound during
+withdraw.
 
 
 Alternatives
 ============
 
-TODO.
-
 * ID-based systems
 * credit/debit card based systems
 
@@ -548,10 +621,7 @@ TODO.
 Drawbacks
 =========
 
-TODO.
-
 * age groups, once defined, are set permanently
-* age restricted coins are basically shared between ward and warden.
 
 Also discuss:
 
@@ -571,9 +641,8 @@ We had some very engaged discussions on the GNU Taler 
`mailing list <taler@gnu.o
 
 * `Age-restriction is about coins, not currencies 
<https://lists.gnu.org/archive/html/taler/2021-09/msg00021.html>`__
 
+* The published paper: `Zero Knowledge Age Restriction for GNU Taler 
<https://link.springer.com/chapter/10.1007/978-3-031-17140-6_6>`_
 
-The upcoming paper on anonymous age-restriction for GNU Taler from Özgür Kesim
-and Christian Grothoff will be cited here, once it is published.
 
 .. _Edx25519:
 

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