diff options
Diffstat (limited to 'design-documents/024-age-restriction.rst')
| -rw-r--r-- | design-documents/024-age-restriction.rst | 420 |
1 files changed, 348 insertions, 72 deletions
diff --git a/design-documents/024-age-restriction.rst b/design-documents/024-age-restriction.rst index 884ab275..0445aa6d 100644 --- a/design-documents/024-age-restriction.rst +++ b/design-documents/024-age-restriction.rst @@ -1,5 +1,5 @@ -DD 024: Anonymous Age Restriction Extension for GNU Taler -######################################################### +DD 24: Anonymous Age Restriction Extension +########################################## Summary ======= @@ -18,7 +18,7 @@ sensitive private information is disclosed. We want to offer a better mechanism for age-restriction with GNU Taler that * ensures anonymity and unlinkability of purchases -* can be set to particular age groups by parents/wardens at withdrawal +* can be set to particular age groups by parents/wardens at withdrawal * is bound to particular coins/tokens * can be verified by the merchant at purchase time * persists even after refresh @@ -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 - pairs of EdDSA 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` +#. 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 (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,14 +101,18 @@ 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 Özgür and Christian is published. - Changes in the Exchange API ^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -143,11 +148,16 @@ registering the extension ``age_restriction`` with a value type // `LibtoolVersion`. version: "1"; - // Age restriction specific fields - + // Age restriction specific configuration + config: ConfigAgeRestriction; + } + +.. ts:def:: ConfigAgeRestriction + + interface ConfigAgeRestriction { // The age groups. This field is mandatory and binding in the sense // that its value is taken into consideration when signing the - // denominations in `ExchangeKeysResponse`.``age_restricted_denoms``. + // age restricted denominations in the `ExchangeKeysResponse` age_groups: AgeGroups; } @@ -189,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 @@ -238,13 +247,13 @@ changed since the given timestamp. // Similar as for ``.denoms``, if the query parameter ``last_issue_date`` // was provided by the client, the exchange will only return the keys that // have changed since the given timestamp. - age_restricted_denoms: Denom[]; + age_restricted_denoms: DenomCommon[]; //... } -SQL changes +SQL schema ----------- The exchange has to mark denominations with support for age restriction as such @@ -260,15 +269,15 @@ The schema for the exchange is changed as follows: BEGIN; -- Check patch versioning is in place. SELECT _v.register_patch('exchange-TBD', NULL, NULL); - + -- Support for age restriction is marked per denomination. ALTER TABLE denominations ADD COLUMN age_restricted BOOLEAN NOT NULL DEFAULT (false); COMMENT ON COLUMN denominations.age_restriced IS 'true if this denomination can be used for age restriction'; - -- During the melting phase of the refresh, the wallet has to present the - -- hash value of the age commitment (only for denominations with support + -- During the melting phase of the refresh, the wallet has to present the + -- hash value of the age commitment (only for denominations with support -- for age restriction). ALTER TABLE refresh_commitments ADD COLUMN age_commitment_h BYTEA CHECK (LENGTH(age_commitment_h)=64); @@ -282,9 +291,165 @@ NULL, but only iff the corresponding denomination (indirectly referenced via table ``known_coins``) has ``.age_restricted`` set to true. This constraint 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, or by other means. +- A KYC-process has been performed with the owner of a reserve and the user has + been identified as being a minor. +- A Peer-to-Peer transaction was performed between customers. The receiving + customer's KYC result tells the exchange that the customer belongs to a + specific age group. + +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 and Exchange run the following protocol +for the withdrawal of one coin: + +- *Wallet* + 1. creates planchets :math:`C_i` for :math:`i \in \{1,\ldots,\kappa\}` as candidates for *one* coin. + #. creates age-commitments :math:`\vec{Q}^i` for :math:`i \in \{1,\ldots,\kappa\}` as follows: + + a) creates :math:`a`-many Edx25519-keypairs :math:`(p^i_j, q^i_j)` + randomly for :math:`j \in \{1,\ldots,a\}` (with public keys :math:`q^i_j`), + #) chooses randomly :math:`(M - a)`-many scalars :math:`s^i_j` for :math:`j \in \{a+1,\ldots,M\}`, + #) calculates :math:`\omega^i_j = s^i_j*\Omega` for :math:`j \in \{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))` for :math:`i \in \{ 1,\ldots,\kappa \}`. + #. chooses random blindings :math:`\beta_i(.)` for :math:`i \in \{1,\ldots,\kappa\}`. The blinding functions depend on the cipher (RSA, CS). + #. sends :math:`(\beta_1(f_1),\ldots,\beta_\kappa(f_\kappa))` to the Exchange + +- *Exchange* + 7. receives :math:`(b_1,\ldots,b_\kappa)` + #. calculates :math:`F := \text{H}(b_1||\ldots||b_\kappa)` + #. chooses randomly :math:`\gamma \in \{1,\ldots,\kappa\}` and + #. signs :math:`r := b_\gamma` resulting in signature :math:`\sigma_r` + #. stores :math:`F \mapsto (r, \sigma_r)` + #. sends :math:`\gamma` to the Wallet. + +- *Wallet* + 10. receives :math:`\gamma` + #. sends to the Exchange the tuple :math:`\left(F, \vec{\beta}, \vec{\vec{Q}}, \vec{\vec{S}}\right)` with + + - :math:`F := \text{H}(\beta_1(f_1)||\ldots||\beta_\kappa(f_\kappa))` + - :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* + 12. receives :math:`\left(F, (\beta_i), (\vec{Q}^i), (\vec{B}^i) \right)` + #. retrieves :math:`(r, \sigma_r)` from :math:`F` or bails out if not present + #. calculates :math:`b_i := \beta_i\left(\text{FDH}(\vec{Q}^i)\right)` for :math:`i \neq \gamma` + #. compares :math:`F \overset{?}{=} \text{H}(b_1||\ldots||b_{\gamma - 1}||r||b_{\gamma+1}||\ldots||b_\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 \in \{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 + #. sends (blinded) signature :math:`\sigma_r` to Wallet + +- *Wallet* + 18. receives :math:`\sigma_r` + #. calculates (unblinded) signature :math:`\sigma_\gamma := \beta^{-1}_\gamma(\sigma_r)` for coin :math:`C_\gamma`. + + +Note that the batch version of withdraw allows the withdrawal of *multiple* +coins at once. For that scenario the protocol sketched above is adapted to +accomodate for handling multiple coins at once -- thus multiplying the amount +of data by the amount of coins in question--, but all with the same value of +:math:`\gamma`. + +The *actual* implementation of the protocol above will have major optimizations +to keep the bandwidth usage to a minimum and also ensure that a denomination in +the commitment doesn't expire before the reveal. + +Instead of generating and sending the age commitment (array of public keys) and +blindings for each coin, the wallet *MUST* derive the corresponding blindings +and the age commitments from the coin's private key itself as follows: + +Let + +- :math:`s` be the master secret of the coin, from which the private key :math:`c_s`, blinding :math:`\beta` and nonce :math:`n` are derived as usual in the wallet core +- :math:`m \in \{1,\ldots,M\}` be the maximum age (according to the reserve) + that a wallet can commit to during the withdrawal. +- :math:`P` be a published constant Edx25519-public-key to which the private + key is not known to any client. + +For the age commitment, calculate: + +1. For age group :math:`a \in \{1,\ldots,m\}`, set + +.. math:: + s_a &:= \text{HDKF}(s, \text{"age-commitment"}, a) \\ + p_a &:= \text{Edx25519\_generate\_private}(s_a) \\ + q_a &:= \text{Edx25519\_public\_from\_private}(p_a) + +2. For age group :math:`a \in \{m,\ldots,M\}`, set + +.. math:: + f_a &:= \text{HDKF}(s, \text{"age-factor"}, a) \\ + q_a &:= \text{Edx25519\_derive\_public}(P, f_a). + +Then the vector :math:`\vec{q} = \{q_1,\ldots,q_M\}` is then the age commitment +associated to the coin's private key :math:`c_s`. For the non-disclosed coins, +the wallet can use the vector :math:`(p_1,\ldots,p_m,\bot,\ldots,\bot)` of +private keys for the attestation. + +Provided with the secret :math:`s`, the exchange can therefore calculate the +private key :math:`c_s`, the blinding :math:`\beta`, the nonce :math:`n` (if +needed) and the age commitment :math:`\vec{q}`, along with the coin's public +key :math:`C_p` and use the value of + +.. math:: + + \text{TALER\_CoinPubHashP}(C_p, \text{age\_commitment\_hash}(\vec{q})) + +during the verification of the original age-withdraw-commitment. + +For the withdrawal with age restriction, a sketch of the corresponding database +schema in the exchange is given here: + +.. graphviz:: + + digraph deposit_policies { + rankdir = LR; + splines = true; + fontname="monospace" + node [ + fontname="monospace" + shape=record + ] + + subgraph cluster_commitments { + label=<<B>age_withdraw</B>> + margin=20 + commitments [ + label="age_withdraw_id\l|<hc>h_commitment\l|amount_with_fee_val\l|amount_with_fee_frac\l|noreveal_index\l|max_age\l|<res>reserve_pub\l|reserve_sig\l|<denom>[n] denominations_serials\l|[n] h_blind_evs\l|[n] denom_sigs\l" + ] + } + + commitments:res->reserves:id [ label="n:1"; fontname="monospace"]; + commitments:denom -> denominations:id [ label="n:1"; fontname="monospace"] ; + } + + Refresh - melting phase ~~~~~~~~~~~~~~~~~~~~~~~ @@ -302,7 +467,7 @@ restriction). Therefore, in the ``/coins/$COIN_PUB/melt`` POST request, the // SHA256 hash of the age commitment of the coin, IFF the denomination // has age restriction support. MUST be omitted otherwise. age_commitment_hash?: AgeCommitmentHash; - + ... } @@ -313,7 +478,7 @@ restriction). Therefore, in the ``/coins/$COIN_PUB/melt`` POST request, the The responses to the POST request remain the same. For normal denominations *without* support for age restriction, the calculation -for the signature check is as before (borrowing notation from +for the signature check is as before (borrowing notation from `Florian's thesis <https://taler.net/papers/thesis-dold-phd-2019.pdf>`_): .. math:: @@ -344,7 +509,7 @@ the amount of age groups defined in the field ``.age_groups`` of the ``ExtensionAgeRestriction``. .. ts:def:: RevealRequest - + interface RevealRequest { ... @@ -354,14 +519,33 @@ the amount of age groups defined in the field ``.age_groups`` of the // The size of the vector is defined by the Exchange implicetly as the // amount of age groups defined in the field ``.age_groups`` of the // ``ExtensionAgeRestriction``. - old_age_commitment?: EddsaPublicKey[]; + old_age_commitment?: Edx25519PublicKey[]; + - ... } -TODO: describe how the exchange derives the κ-1 other age-restriction vectors -and compares them to the one in ``.old_age_commitment``. + +The exchange can now check if the provided public keys ``.old_age_commitment`` +have the same SHA256 hash value when hashed in sequence as the +``age_commitment_hash`` of the original coin from the call to melt. + +The existing `cut&choose protocol during the reveal phase +</core/api-exchange.html#post--refreshes-$RCH-reveal>`__ is extended to perform +the following additional computation and checks: + +Using the κ-1 transfer secrets :math:`\tau_i` from the reveal request, the +exchange derives κ-1 age commitments from the ``old_age_commitment`` by calling +``Edx25519_derive_public()`` on each `Edx25519PublicKey`, with :math:`\tau_i` +as the seed, and then calculates the corresponding κ-1 hash values :math:`h_i` +of those age commitments. + +It then calculates the κ-1 blinded hashes +:math:`m_i = r^{e_i}\text{FDH}_N(C^{(i)}_p, h_i)` (using the notation from Florian's +thesis) of the disclosed coins and together with the :math:`m_\gamma` of the +undisclosed coin, calculates the hash +:math:`h'_m = H(m_1,\cdots,m_\gamma,\cdots,m_\kappa)` which is then used in the +final verification step of the cut&choose protocol. Deposit @@ -413,23 +597,23 @@ minimum age in response to order claim by the wallet, that is, a POST to ``[/instances/$INSTANCE]/orders/$ORDER_ID/claim``. The object ``ContractTerms`` is extended by an optional field -``required_minimum_age`` that can be any integer greater than 0. In reality +``minimum_age`` that can be any integer greater than 0. In reality this value will not be smaller than, say, 8, and not larger than, say, 21. -.. ts:def:: ContractTerms +.. ts:def:: DD24ContractTerms - interface ContractTerms { + interface DD24ContractTerms { ... - + // If the order requires a minimum age greater than 0, this field is set // to the integer value of that age. In reality this value will not be // smaller than, say, 8, and not larger than, say, 21. - required_minimum_age?: Integer; + minimum_age?: Integer; ... } -By sending the contract term with the field ``required_minimum_age`` set to an +By sending the contract term with the field ``minimum_age`` set to an non-zero integer value, the merchant implicetly signals that it understands the extension ``age_restriction`` for age restriction from the exchange. @@ -438,7 +622,7 @@ Making the payment ------------------ If the ``ContractTerms`` had a non-zero value in field -``required_minimum_age``, the wallet has to provide evidence of that minimum +``minimum_age``, the wallet has to provide evidence of that minimum age by #. *either* using coins which are of denominations that had *no* age support @@ -449,7 +633,7 @@ age by * and then ―for each such coin― it has the right private key of the restricted age commitment to the age group into which the required minimum - age falls (i.e. a non-empty entry at the right index in vector of EdDSA + age falls (i.e. a non-empty entry at the right index in vector of Edx25519 keys, see above). * and signs the required minimum age with each coin's private key @@ -470,12 +654,12 @@ The object ``CoinPaySig`` used within a ``PayRequest`` during a POST to // are at least committed to the corresponding age group, this is the // signature of the minimum age as a string, using the private key to the // corresponding age group. - minimum_age_sig?: EddsaSignature; + minimum_age_sig?: Edx25519Signature; // If a minimum age was required by the order, this is age commitment bound - // to the coin, i.e. the complete vector of EdDSA public keys, one for each + // to the coin, i.e. the complete vector of Edx25519_ public keys, one for each // age group (as defined by the exchange). - age_commitment?: EddsaPublicKey[]; + age_commitment?: Edx25519PublicKey[]; } @@ -495,29 +679,24 @@ The merchant can now verify against the public key ``age_commitment[k]`` of the corresponding age group, say, ``k``. (The minimum age must fall into the age group at index ``k`` as defined by the exchange). - + **Note**: This applies only to coins for denominations that have support for age restriction. Denominations *without* support for age restriction *always* 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 @@ -525,10 +704,7 @@ TODO. Drawbacks ========= -TODO. - * age groups, once defined, are set permanently -* age restricted coins are basically shared between ward and warden. Also discuss: @@ -543,12 +719,112 @@ Discussion / Q&A We had some very engaged discussions on the GNU Taler `mailing list <taler@gnu.org>`__: * `Money with capabilities <https://lists.gnu.org/archive/html/taler/2021-08/msg00005.html>`_ - * `On age-restriction (was: online games in China) <https://lists.gnu.org/archive/html/taler/2021-09/msg00006.html>`__ * `Age-restriction is about coins, not currencies <https://lists.gnu.org/archive/html/taler/2021-09/msg00021.html>`__ - -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. +* The published paper: `Zero Knowledge Age Restriction for GNU Taler <https://link.springer.com/chapter/10.1007/978-3-031-17140-6_6>`_ + + +.. _Edx25519: + +Edx25519 +======== + +Edx25519 is a variant of EdDSA on curve25519 which allows for repeated +derivation of private and public keys, independently. It is implemented in +`GNUNET with commit ce38d1f6c9bd7857a1c3bc2094a0ee9752b86c32. +<https://git.gnunet.org/gnunet.git/commit/?id=ce38d1f6c9bd7857a1c3bc2094a0ee9752b86c32>`__ + +The private keys in Edx25519 initially correspond to the data after expansion +and clamping in EdDSA. However, this correspondence is lost after deriving +further keys from existing ones. The public keys and signature verification +are compatible with EdDSA. + +The scheme is as follows: + +:: + + /* Private keys in Edx25519 are pairs (a, b) of 32 byte each. + * Initially they correspond to the result of the expansion + * and clamping in EdDSA. + */ + + Edx25519_generate_private(seed) { + /* EdDSA expand and clamp */ + dh := SHA-512(seed) + a := dh[0..31] + b := dh[32..64] + a[0] &= 0b11111000 + a[31] &= 0b01111111 + a[31] |= 0b01000000 + + return (a, b) + } + + Edx25519_public_from_private(private) { + /* Public keys are the same as in EdDSA */ + (a, _) := private + return [a] * G + } + + Edx25519_blinding_factor(P, seed) { + /* This is a helper function used in the derivation of + * private/public keys from existing ones. */ + h1 := HKDF_32(P, seed) + + /* Ensure that h == h % L */ + h := h1 % L + + /* Optionally: Make sure that we don't create weak keys. */ + P' := [h] * P + if !( (h!=1) && (h!=0) && (P'!=E) ) { + return Edx25519_blinding_factor(P, seed+1) + } + + return h + } + + Edx25519_derive_private(private, seed) { + /* This is based on the definition in + * GNUNET_CRYPTO_eddsa_private_key_derive. But it accepts + * and returns a private pair (a, b) and allows for iteration. + */ + (a, b) := private + P := Edx25519_public_key_from_private(private) + h := Edx25519_blinding_factor(P, seed) + + /* Carefully calculate the new value for a */ + a1 := a / 8; + a2 := (h * a1) % L + a' := (a2 * 8) % L + + /* Update b as well, binding it to h. + This is an additional step compared to GNS. */ + b' := SHA256(b ∥ h) + + return (a', b') + } + + Edx25519_derive_public(P, seed) { + h := Edx25519_blinding_factor(P, seed) + return [h]*P + } + + Edx25519_sign(private, message) { + /* As in Ed25519, except for the origin of b */ + (d, b) := private + P := Edx25519_public_from_private(private) + r := SHA-512(b ∥ message) + R := [r] * G + s := r + SHA-512(R ∥ P ∥ message) * d % L + + return (R,s) + } + + Edx25519_verify(P, message, signature) { + /* Identical to Ed25519 */ + (R, s) := signature + return [s] * G == R + [SHA-512(R ∥ P ∥ message)] * P + } |