commit a31417799c6298f9f029ab9c50dec6629b307831
parent 9ce747711893464ed0588ddd930402fe746955bc
Author: Özgür Kesim <oec@kesim.org>
Date: Sun, 13 Apr 2025 19:34:50 +0200
[dd:pq-refresh] added table layout for refresh
Diffstat:
1 file changed, 37 insertions(+), 9 deletions(-)
diff --git a/design-documents/062-pq-refresh.rst b/design-documents/062-pq-refresh.rst
@@ -5,30 +5,37 @@ Summary
=======
This document specifies a change to GNU Taler's refresh protocol that provides
post-quantum resistance through hash-based cryptography and deterministic
-signatures, eliminating reliance on Diffie-Hellman operations.
+signatures, eliminating reliance on Diffie-Hellman operations, for the key
+derivation for the fresh coin from a dirty coin.
Motivation
==========
+
The current refresh protocol uses cryptographic primitives vulnerable to
-quantum attacks. This redesign:
+quantum attacks to derive the key material for a fresh coin from the key of the
+dirty coin. The rational for the elaborate derivation in first place is to
+ensure taxability: When original and new coins remain linked (by the owner of
+the original coin), passing coin outside the Taler protocols is discouraged.
+
+This redesign:
1. Removes DH operations from refresh derivation
-2. Uses hash-based commitments for coin lineage
-3. Implements deterministic signatures for ownership proofs
-4. Maintains backward compatibility through extension flags
+2. Uses deterministic signatures for ownership proofs
+3. Derives key material from (unforgeable) signatures
+4. Maintains backward compatibility with other parts of the protocol stack
Requirements
============
* PQ-resistant refresh without computational hardness assumptions
-* Preservation of unlinkability between old/new coins
+* Preservation of unlinkability between old/new coins (except for coin owner)
* Compatibility with existing denomination types
* Minimal bandwidth/storage overhead
Proposed Solution
=================
-RefreshDerivePQ Algorithm
+RefreshDerive Algorithm
^^^^^^^^^^^^^^^^^^^^^^^^^
The core mechanism uses two hash functions and deterministic signatures to
@@ -86,7 +93,7 @@ published.
- Exchange returns σ_γ on success.
It is worth noting that, in contrast to the existing refresh protocol, the
-client sents all κ tuples of m_i already in the commitment phase. This is
+client sends all κ tuples of m_i already in the commitment phase. This is
necessary such that the exchange can sign the request with a valid denomination
key *at the moment of melting*. This ensures idempotency of the melting/commit
request and that caries over to the reveal phase.
@@ -101,7 +108,28 @@ seed was of its own origin.
Database Changes
^^^^^^^^^^^^^^^^
-TODO, see withdraw
+Not taking sharding and coinstraints into account, the table layout will look
+basically like this:
+
+.. table:: SQL table layout for refresh
+ :align: left
+
+ ============== ============ ================================================
+ Field Type Description
+ ============== ============ ================================================
+ refresh_id BIGINT autoincremented identity of the record
+ h_commitment BYTEA the value h_m above, serving as primary key
+ timestamp INT8 execution date of the refresh
+ amount taler_amount amount with fee of the refresh
+ old_coin_pub BYTEA the old coin's public key
+ old_coin_sig BYTEA old coin's signature over the refresh request
+ noreveal_index SMALLINT the γ for cut-and-choose, chosen by the exchange
+ h_blind_evs BYTEA[] the blinded coin evelopes, i.e. (many) m_γ above
+ r_nonce BYTEA the master seed for the refresh, the r above
+ denom_serials INT8[] the row ID's of the denominations in the DB
+ denom_sigs BYTEA[] the denom signatures for each h_blind_evs
+ ============== ============ ================================================
+
API endpoints
^^^^^^^^^^^^^^
