summaryrefslogtreecommitdiff
path: root/doc/paper/postquantum_melt.tex
blob: 2dfefeeed6800b19f1e5a7cc9f0cc741281ca664 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
\documentclass{llncs}
%\usepackage[margin=1in,a4paper]{geometry}
\usepackage[T1]{fontenc}
\usepackage{palatino}
\usepackage{xspace}
\usepackage{microtype}
\usepackage{tikz,eurosym}
\usepackage{amsmath,amssymb}
\usepackage{enumitem}
\usetikzlibrary{shapes,arrows}
\usetikzlibrary{positioning}
\usetikzlibrary{calc}

% Relate to:
% http://fc14.ifca.ai/papers/fc14_submission_124.pdf

% Terminology:
% - SEPA-transfer -- avoid 'SEPA transaction' as we use
%       'transaction' already when we talk about taxable
%        transfers of Taler coins and database 'transactions'.
% - wallet = coins at customer
% - reserve = currency entrusted to exchange waiting for withdrawal
% - deposit = SEPA to exchange
% - withdrawal = exchange to customer
% - spending = customer to merchant
% - redeeming = merchant to exchange (and then exchange SEPA to merchant)
% - refreshing = customer-exchange-customer
% - dirty coin = coin with exposed public key
% - fresh coin = coin that was refreshed or is new
% - coin signing key = exchange's online key used to (blindly) sign coin
% - message signing key = exchange's online key to sign exchange messages
% - exchange master key = exchange's key used to sign other exchange keys
% - owner = entity that knows coin private key
% - transaction = coin ownership transfer that should be taxed
% - sharing = coin copying that should not be taxed


\title{Post-quantum anonymity in Taler}

\begin{document}
\mainmatter

\author{Jeffrey Burdges}
\institute{Intria / GNUnet / Taler}


\maketitle

\begin{abstract}
David Chaum's original RSA blind sgnatures provide information theoretic
anonymity for customers' purchases.  In practice, there are many schemes
that weaken this to provide properties.  We describe a refresh protocol
for Taler that provides customers with post-quantum anonymity.
It replaces an elliptic curve Diffe-Hellman operation with a unique
hash-based encryption scheme for the proof-of-trust via key knoledge
property that Taler requires to distinguish untaxable operations from
taxable purchases. 
\end{abstract}


\section{Introduction}

David Chaum's RSA blind sgnatures \cite{} can provide financial
security for the exchange, or traditionally mint,
 assuming RSA-CTI \cite{,}. 

A typical exchange deployment must record all spent coins to prevent
double spending.  It would therefore rotate ``denomination'' signing
keys every few weeks or months to keep this database from expanding
indefinitely \cite{Taler??}.  As a consequence, our exchange has
ample time to respond to advances in cryptgraphy by increasing their
key sizes, updating wallet software with new algorithms, or
even shutting down.

In particular, there is no chance that quantum computers will emerge
and become inexpensive within the lifetime of a demonination key.
Indeed, even a quantum computer that existed only in secret posses
little threat because the risk of exposing that secret probably exceeds
the exchange's value. 

\smallskip

We cannot make the same bold pronouncement for the customers' anonymity
however.  We must additionally ask if customers' transactions can be
deanonymized in the future by the nvention of quantum computes, or
mathematical advances. 

David Chaum's original RSA blind sgnatures provide even information
theoretic anonymity for customers, giving the desired negative answer.
There are however many related schemes that add desirable properties
at the expense of customers' anonymity.  In particular, any scheme
that supports offline merchants must add a deanonymization attack
when coins are double spent \cite{B??}.  

Importantly, there are reasons why exchanges must replace coins that
do not involve actual financial transactons, like to reissue a coin
before the exchange rotates the denomination key that signed it, or
protect users' anonymity after a merchant recieves a coin, but fails
to process it or deliver good.

In Taler, coins can be partially spent by signing with the coin's key
for only a portion of the value determined by the coin's denomination
key.  This allows precise payments but taints the coin with a
transaction,  which frequently entail user data like a shipng address.  
To correct this, a customer does a second transaction with the exchange
where they sign over the partially spent coin's risidual balance
in exchange for new freshly anonymized coins.  
Taler employs this {\em refresh} or {\em melt protocol} for
both for coins tainted through partial spending or merchant failures,
as well as for coin replacement due to denomination key roration.

If this protocol were simply a second transaction, then customers
would retain information theoreticaly secure anonymity.  
In Taler however, we require that the exchange learns acurate income
information for merchants.  If we use a regular transaction, then
a customer could conspire to help the merchant hide their income
\cite[]{Taler??}.
To prevent this, the refresh protocol requires that a customer prove
that they could learn the private key of the resulting new coins.

At this point, Taler employs an elliptic curve Diffie-Hellman key
exchange between the coin's signing key and a new linking key 
\cite[??]{Taler??}.  As the public linking key is exposed,
an adversary with a quantum computer could trace any coins involved
in either partial spending operations or aborted transactions.
A refresh prompted by denomination key rotation incurs no anonymity
risks regardless.

\smallskip

We could add an existing post-quantum key exchange, but these all
incur significantly larger key sizes, requiring more badwidth and
storage space for the exchange, and take longer to run.
In addition, the established post-quantum key exchanges based on
Ring-LWE, like New Hope \cite{}, require that both keys be
ephemeral.  
Super-singular isogenies \cite{,} would work ``out of the box'',
if it were already packeged in said box.

Instead, we observe that 







In this paper, we describe a post-quantum 

It replaces an elliptic curve Diffe-Hellman operation with a unique
hash-based encryption scheme for the proof-of-trust via key knoledge
property that Taler requires to distinguish untaxable operations from
taxable purchases. 

...

\smallskip

We observe that several elliptic curve blind signature schemes provide
information theoreticly secure blinding as well, but 
 Schnorr sgnatures require an extra round trip \cite{??}, and
 pairing based schemes offer no advnatages over RSA \cite{??}.

There are several schemes like Anonize \cite{} in Brave \cite{}, 
or Zcash \cite{} used in similar situations to blind signatures. 
% https://github.com/brave/ledger/blob/master/documentation/Ledger-Principles.md
In these systems, anonymity is not post-quantum due to the zero-knowledge
proofs they employ.




\section{Background}


\section{Refresh}


Let $\kappa$ and $\theta$ denote
 the exchange's security parameter and
 the maximum number of coins returned by a refresh, respectively. 

We define a Merkle tree/sequence function 
  $\mlink(m,i,j) = H(m || "YeyCoins!" || i || j)$ 
        Actual linking key for jth cut of ith target coin
  $\mhide(m,i,j) = H( \mlink(m,i,j) )$
        Linking key hidden for Merkle
  $\mcoin(m,i) = H( \mhide(m,i,1) || \ldots || \mhide(m,i,\kappa) )$
        Merkle root for refresh into the ith coin
  $\mroot(m) = M( \m_coin(m,1), \ldots, \mcoin(m,\theta) )$
        Merkle root for refresh of the entire coin
  $mpath(m,i)$ is the nodes adjacent to Merkle path to $\mcoin(m,i)$
If $\theta$ is small then $M(x[1],\ldots,x[\theta])$ could be simply be
the concatenate and hash function $H( x[1] || ... || x[\theta] )$ like
in $\mcoin$, giving $O(n)$ time.  If $\theta$ is large, then $M$ should
be a hash tree to give $O(\log n)$ time.  We could use $M$ in $\mcoin$
too if $\kappa$ were large, but concatenate and hash wins for $\kappa=3$.
All these hash functions should have a purpose string.


A coin now consists of 
  a Ed25519 public key $C = c G$,
  a Merkle root $M = \mroot(m)$, and 
  an RSA signature $S = S_d(C || M)$ by a denomination key $d$.
There was a blinding factor $b$ used in the creation of the coin's signature $S$.
In addition, there was a value $s$ such that 
  $c = H(\textr{"Ed25519"} || s)$,
  $m = H(\textr{"Merkle"} || s)$, and
  $b = H(\textr{"Blind"} || s)$,
but we try not to retain $s$ if possible.


We have a tainted coin $(C,M,S)$ that we wish to
 refresh into $n \le \theta$ untained coins.  
For simplicity, we allow $x'$ to stand for the component
 normally denoted $x$ of the $i$th new coin being created.  
So $C' = c' G$, $M' = \mroot(m')$, and $b'$ must be derived from $s'$.
For $j=1\cdots\kappa$,
 we allow $x^j$ to denote the $j$th cut of the $i$th coin.  
So again
 $C^j = c^j G$, $M^j = \mroot(m^j)$, and $b^j$ must be derived from $s^j$.

Wallet phase 1.
  For $j=1 \cdots \kappa$:
    Create random $s^j$ and $l^j$.
    Compute $c^j$, $m^j$, and $b^j$ from $s^j$ as above.
    Compute $C^j = c^j G$ and $L^j = l^j G$ too.
    Compute $B^j = B_{b^j}(C^j || \mroot(m^j))$.
    Set $k = H(\mlink(m,i,j) || l^j C)$
    Encrypt $E^j = E_k(s^j,l^j)$.
  Send commitment $S' = S_C( (L^j,E^1,B^1), \ldots, (E^\kappa,B^\kappa) )$
%  Note : If $\mlink$ were a stream cypher then $E()$ could just be xor.

Exchange phase 1.
  Pick random $\gamma \in \{1 \cdots \kappa\}$.
  Mark $C$ as spent by saving $(C,gamma,S')$.
  Send gamma and $S(C,gamma,...)$

Wallet phase 2.
  Save ...
  Set $\Beta_gamma = \mhide(m,i,gamma) = H( \mlink(m,i,gamma) )$ and
      $\beta_i = \mlink(m,i,j)$ for $j=1\cdots\kappa$ not $\gamma$
  Prepare a responce tuple $R^j$ consisting of 
    $Beta_gamma$,  $(beta_j,l^j)$ for $j=1\cdots\kappa$ not $\gamma$,  
    and  $\mpath(m,i)$, including $\mcoin(m,i)$,
  Send $S_C(R^j)$.

Exchange phase 2.
  Set $Beta_j = H(beta_j)$ for $j=1\ldots\kappa$ except $\gamma$,
    keep $Beta_gamma$ untouched.
  Verify $M$ with $\mpath(m,i)$ including $\mcoin(m,i)$.
  Verify $\mcoin(m,i) = H( Beta_1 || .. || Beta_kappa )$.
  For $j=1 \cdots \kappa$ except $\gamma$:
    Decrypt $s^j$ from $E^i$ using $k = H(beta_j || l^j C)$
    Compute $c^j$, $m^j$, and $b^j$ from $s^j$.
    Compute $C^j = c^j G$ too.
    Verify $B^i = B_{b^j}(C^j || \mroot(m^j))$.
  If verifications pass then send $S_{d_i}(B^\gamma)$.


\section{Withdrawal}


\bibliographystyle{alpha}
\bibliography{taler,rfc}

% \newpage
% \appendix

% \section{}



\end{document}



$l$ denotes Merkle tree levels
yields $2^l$ leaves
costs $2^{l+1}$ hashing operations

$a$ denotes number of leaves used
yields $2^{a l}$ outcomes






commit  H(h)  and  h l C  and  E_{l C)(..)
reveal h and l



x_n ... x_1 c G






waiting period of 10 min