commit 16f9650166b6f2163e86d6e7f9f4ce49d23bb093
parent f2be1a49e103c08dc7532413ce10166303cd3c3c
Author: Özgür Kesim <oec-taler@kesim.org>
Date: Tue, 20 Dec 2022 13:56:34 +0100
added ZK-proof for age restriction for withdrawal
Diffstat:
1 file changed, 107 insertions(+), 38 deletions(-)
diff --git 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:
