1: \documentclass[11pt,a4paper,oneside]{article}
2: \oddsidemargin 0.5cm \evensidemargin 0.5cm \topmargin 0cm
3: \setlength{\headheight}{0cm} \setlength{\headsep}{0cm}
4: \setlength{\textwidth}{15cm} \setlength{\textheight}{24cm}
5:
6: \usepackage {graphicx}
7:
8:
9: \begin{document}
10:
11: \title{Multi-Dimensional Hash Chains and Application to Micropayment Schemes}
12: \author{Quan Son Nguyen\\
13: \\
14: Faculty of Information Technology\\
15: Hanoi University of Technology\\
16: Hanoi, Vietnam\\
17: e-mail: sonnq@tinhvan.com} \maketitle
18:
19:
20: \begin{abstract}
21: One-way hash chains have been used in many micropayment schemes due
22: to their simplicity and efficiency. In this paper we introduce the
23: notion of multi-dimensional hash chains, which is a new
24: generalization of traditional one-way hash chains. We show that this
25: construction has storage-computational complexity of $O(\log _2 N)$
26: per chain element, which is comparable with the best result reported
27: in recent literature. Based on multi-dimensional hash chains, we
28: then propose two cash-like micropayment schemes, which have a number
29: of advantages in terms of efficiency and security. We also point out
30: some possible improvements to PayWord and similar schemes by using
31: multi-dimensional hash chains.
32: \end{abstract}
33:
34:
35:
36: \section{Introduction}
37:
38: One-way hash chains are an important cryptographic primitive and
39: have been used as a building block of a variety of cryptographic
40: applications such as access control, one-time signature, electronic
41: payment, on-line auction, etc.
42:
43: In particular, there are many micropayment schemes based on one-way
44: hash chains, including PayWord \cite{RS96}, NetCard \cite{AMS96},
45: micro-iKP \cite{HSW96} and others.
46:
47: By definition, micropayments are electronic payments of low value.
48: Other schemes designed for payments of high value normally use a
49: digital signature to authenticate every payment made. Such an
50: approach is not suitable for micropayments because of high
51: computational cost and bank processing cost in comparison with the
52: value of payment.
53:
54: The use of hash chains in micropayment schemes allows minimizing the
55: use of digital signature, whose computation is far slower than the
56: computation of a hash function (according to \cite{RS96}, hash
57: functions are about 100 times faster than RSA signature
58: verification, and about 10,000 times faster than RSA signature
59: generation). Moreover, because a whole hash chain is authenticated
60: by a single digital signature on the root of chain, successive
61: micropayments can be aggregated into a single larger payment, thus
62: reducing bank processing cost.
63:
64: There are a variety of improvements to hash chains. For example, in
65: the PayTree payment scheme \cite{JY96}, Jutla and Yung generalized
66: the hash chain to a hash tree. This construction allows the customer
67: to use parts of a tree to pay different vendors. Recently,
68: researchers have proposed a number of improved hash chains, which
69: are more efficient in terms of computational overhead and storage
70: requirement \cite{CJ02,Jak02,Sel03,HJP03}.
71:
72: This paper is organized as follows. In section \ref{MDHC} we
73: introduce the notion of multi-dimensional hash chains (MDHC for
74: short). We also analyze efficiency of this construction and show
75: that RSA modular exponentiations could be used as one-way hash
76: functions of a MDHC. Section \ref{CashLikeSchemes} describes two
77: cash-like micropayment schemes based on MDHC, which have a number of
78: advantages in terms of efficiency and security. In section
79: \ref{ImprovePayword} we also examine some possible improvements to
80: PayWord and similar schemes. Finally, section \ref{Conclusion}
81: concludes the paper.
82:
83:
84:
85: \section{Multi-Dimensional Hash Chain}
86: \label{MDHC}
87:
88: \subsection{Motivation}
89:
90: The notion of MDHC originates from one-way hash chains and one-way
91: accumulators \cite{BM94}. Here we briefly describe these two
92: constructions.
93:
94: A hash chain is generated by applying a hash function multiple
95: times. Suppose that we have a one-way hash function $y = h(x)$ and
96: some starting value $x_n$. A hash chain consists of values $x_0 ,x_1
97: ,x_2 ,...,x_n$ where $x_i = h(x_{i + 1})$ for $i = 0,1,...,n - 1$.
98: The value $x_0 = h^n(x_n )$ is called the root of hash chain. The
99: figure below depicts a hash chain of size $n$:
100: \begin{figure}[htbp]
101: \centerline{
102: \mbox{\includegraphics[width=2.90in,height=0.53in]{mdhcfig1.eps}}
103: } \caption{A one-way hash chain} \label{HashChain}
104: \end{figure}
105:
106: In contrast, a one-way accumulator is the output of multiple hash
107: functions, each of them applied only once:
108: \[
109: y = h_1 (h_2 (...(h_m (x))))
110: \]
111:
112: In order to ensure that the output is uniquely determined regardless
113: of the application order, functions $h_1 ,h_2 ,...,h_m$ must be in
114: pairs commutative, i.e. $h_i (h_j (x)) = h_j (h_i (x))$ for any $x$.
115:
116: Combining the two constructions described above, we define a
117: multi-dimensional hash chain as the result of multiple applications
118: of different commutative hash functions, so the root of an
119: $m$-dimensional hash chain is:
120: \[
121: X_0 = h_1 ^{n_1 }(h_2 ^{n_2}(...(h_m ^{n_m }(X_N ))))
122: \]
123:
124: It is necessary to note that MDHC differs from other generalizations
125: of normal hash chain such as hash tree, which is used in PayTree
126: scheme. In particular such trees are generated from multiple leaf
127: nodes, while a MDHC is generated from a single starting value (i.e.
128: the value $X_N $ above).
129:
130: \subsection{Definitions}
131:
132: We begin with necessary definitions.
133:
134: \noindent\textbf{\textit{Definition 1.}} Two functions $h_1 ,h_2
135: :\mbox{X} \to \mbox{X}$ are called commutative if $h_1 (h_2 (x)) =
136: h_2 (h_1 (x))$ for any $x \in \mbox{X}$.
137:
138: \noindent\textbf{\textit{Definition 2.}} A one-way function
139: $h:\mbox{X} \to \mbox{Y}$ is called one-way independent of one-way
140: functions $h_1 ,h_2 ,...,h_m $ of the same domain if for any $x \in
141: \mbox{X}$, computing $h^{ - 1}(x)$ is intractable even if values
142: $h_1 ^{ - 1}(x),\;h_2 ^{ - 1}(x),...,\;h_m ^{ - 1}(x)$ are known.
143:
144: And now we define MDHC as follows.
145:
146: \noindent\textbf{\textit{Definition 3.}} Let $h_1 ,h_2 ,...,h_m $ be
147: $m$ one-way hash functions that are in pairs commutative and every
148: of them is one-way independent from all others. An $m$-dimensional
149: hash chain of size $(n_1 ,n_2 ,...,n_m )$ consists of values $x_{k_1
150: ,k_2 ,...,k_m } $ where:
151: \[
152: x_{k_1 ,k_2 ,...,k_i ,...,k_m } = h_i (x_{k_1 ,k_2 ,...,k_i +
153: 1,...,k_m }) \quad\textrm{for } i = 1,2,...,m \textrm{ and } k_i =
154: 0,1,...,n_i
155: \]
156:
157: The value $X_N = x_{n_1 ,n_2 ,...,n_m } $ is called the starting
158: node, and the value $X_0 = x_{0,0,...0} $ is called the root of the
159: MDHC, which is uniquely determined from $X_N $ due to commutativity
160: of hash functions:
161: \[
162: X_0 = h_1 ^{n_1 }(h_2 ^{n_2 }(...(h_m ^{n_m }(X_N )))) =
163: \prod\limits_{i = 1}^m {h_i ^{n_i }(X_N )}
164: \]
165:
166: As an illustration, the figure below depicts a two-dimensional hash
167: chain of size (3,2):
168: \begin{figure}[htbp]
169: \centerline{
170: \mbox{\includegraphics[width=2.71in,height=1.91in]{mdhcfig2.eps}}
171: } \caption{A two-dimensional hash chain}
172: \label{TwoDimensionalHashChain}
173: \end{figure}
174:
175: \subsection{Efficiency analysis}
176:
177: In recent literature, there are a number of improvements to one-way
178: hash chains that aim to be more efficient in terms of computational
179: overhead and storage requirement. A widely used metric for one-way
180: hash chain efficiency is the storage-computational complexity, which
181: is the product of the traversal overhead and the storage required to
182: compute consecutive nodes of the hash chain.
183:
184: It is easy to see that a linear hash chain size of $n$ has
185: storage-computational complexity of $O(n)$. In fact, if we
186: precompute and store all nodes (storage of $O(n))$, then no
187: computation is needed when a node is requested (traversal of
188: $O(1))$. Alternatively, we can store only the starting value, and
189: compute every node from the beginning each time it is requested.
190: This approach requires storage of $O(1)$ and $O(n)$ computations.
191: Also, if we store each of $t$ nodes, then storage of $O(n / t)$ and
192: $O(t)$ computations are required. So, in any case, the
193: storage-computational complexity of the linear hash chain is $O(n)$.
194:
195: In \cite{CJ02,Jak02,Sel03} the authors have proposed new techniques
196: that make traversal and storage more efficient, which require
197: $O(\log _2 n)$ computations and $O(\log _2 n)$ storage, resulting in
198: storage-computational complexity of $O(\log _2 ^{\phantom{2}2}n)$.
199: Recently, Hu et al. \cite{HJP03} have presented a new hierarchical
200: construction for one-way hash chains that requires $O(\log _2 n)$
201: storage and only $O(1)$ traversal overhead.
202:
203: In our case of $m$-dimensional hash chain of size $n$ (for
204: simplicity we assume all dimensions have the same size $n_1 = n_2 =
205: ... = n_m = n)$, the number of nodes is $N = (n + 1)^m$. If we store
206: only the starting node of the chain (storage of $O(1))$ then maximal
207: number of calculations required to compute any node is $nm = n\log
208: _{n + 1} N$, or $\log _2 N$ if we select $n = 1$. In that case the
209: storage-computational complexity of MDHC is $O(\log _2 N)$, which is
210: equivalent to the results in \cite{HJP03}.
211:
212: The advantage of MDHC is its simple implementation that does not
213: rely on the so-called pebbling technique, which is used in the
214: constructions mentioned above. However, the main limitation of this
215: construction is the fact that hash functions have to meet the
216: conditions described in the definition of MDHC. The RSA modular
217: exponentiation is known to meet these conditions, but it is not as
218: fast as the traditional hash functions, e.g. MD5 or SHA.
219:
220: \subsection{RSA modular exponentiation}
221:
222: Let consider the function of RSA modular exponentiation:
223: \[
224: y = x^c\bmod M
225: \]
226: \noindent where $c$ is some constant value and $M$ is an RSA
227: modulus, which is a product of two large primes of equal bit length
228: $p$ and $q$.
229:
230: According to \cite{BM94}, the RSA modular exponentiation functions
231: with appropriately selected exponents could meet MDHC requirements.
232:
233: First, obviously these functions are in pairs commutative: $h_i (h_j
234: (x)) = x^{c_i \,c_j }\bmod M = h_j (h_i (x))$
235:
236: Second, one-wayness of these functions is derived from the RSA
237: assumption \cite{RSA78}, which states that the problem of finding
238: the modular root $x = y^{1 / c}\bmod M$ is intractable.
239:
240: Finally, regarding one-way independence of functions, Shamir
241: \cite{Sha83} showed that if $c$ is not a divisor of the product
242: $c_{1\,} c_2 \,...\,c_m $ then the modular roots $y^{1 / c_1 }\bmod
243: M,\;y^{1 / c_2 }\bmod M,\;...,\;y^{1 / c_m }\bmod M$ are
244: insufficient to compute the value of $y^{1 / c}\bmod M$.
245:
246: Therefore we can use the functions of RSA modular exponentiation as
247: one-way hash functions to construct multi-dimensional hash chains.
248:
249: In that case we have following recursive expression:
250: \[
251: x_{k_1 ,k_2 ,...,k_i ,...,k_m } = (x_{k_1 ,k_2 ,...,k_i + 1,...,k_m
252: } )^{c_i }\bmod M \quad\textrm{for } i = 1,2,...,m \textrm{ and }
253: k_i = 0,1,...,n_i
254: \]
255: \noindent where $c_1 ,c_2 ,...,c_m $ are exponents of RSA functions
256: $h_1 ,h_2 ,...,h_m $ respectively.
257:
258: Note that if one knows the factorization of $M$ (i.e. knows $p$ and
259: $q)$, then one can compute $X_0 $ quickly by using following
260: expression:
261: \[
262: X_0 = X_N \,^{\prod\limits_{i = 1}^m {c_i ^{n_i }\bmod E} }\bmod M
263: \]
264: \noindent where $E = \varphi (M) = (p - 1)(q - 1)$, and $\varphi $
265: denotes the Euler's totient function.
266:
267: The expression above consists of only one modular exponentiation
268: with modulus $M$ and $\log _2 N$ modular multiplications with
269: modulus $E$. Since a multiplication is far faster than an
270: exponentiation, this expression allows us to compute $X_0 $ from
271: $X_N $ in a very effective manner.
272:
273:
274:
275: \section{Cash-like Schemes Based on MDHC}
276: \label{CashLikeSchemes}
277:
278: Cash-like payment schemes use the notion of electronic coin, which
279: is an authenticated (by the bank) bit string that is easy to verify,
280: but hard to forge. Examples of such coin are hash collisions (as in
281: MicroMint \cite{RS96}), or digital signatures (as in Ecash
282: \cite{Sch98}).
283:
284: Let's recall the definition of MDHC. If we select the size of the
285: hash chain with $n = 1$ then all nodes $X_i = x_{0,0,...,1,...0} $
286: (with all $k_{j \ne i} = 0$, except $k_i = 1)$ have the same hash
287: value: $h_i (X_i ) = X_0 $. So we can use a pair $(X_i ,h_i )$ as an
288: electronic coin since:
289:
290: \begin{itemize}\itemsep 0pt\parskip 0pt\vspace{-1ex}
291:
292: \item[--] It is easy to verify by just one hashing.
293:
294: \item[--] It is hard to forge because hash functions $h_i $ are
295: one-way, and their one-way independence assures that coin forgery is
296: impossible even if one knows other coins with the same root $X_0 $.
297:
298: \end{itemize}\vspace{-1ex}
299:
300: As a proof of that concept, we suggest two micropayment schemes
301: based on MDHC with the RSA modular exponentiation. We refer to these
302: as S1 and S2 schemes.
303:
304: \subsection{The S1 scheme}
305:
306: We assume that there are three parties involved in a micropayment
307: scheme, namely a bank (B), a customer (C) and a vendor (V). B is
308: trusted by both C and V.
309:
310: \noindent\textsc{Setup}:
311:
312: \begin{itemize}\itemsep 0pt\parskip 0pt\vspace{-1ex}
313:
314: \item[--] B selects an RSA modulus $M = pq$ where $p$ and $q$ are large
315: \textit{safe} primes of equal bit length. A prime p is called safe
316: if $p = 2p' + 1$ where $p'$ is also an odd prime.
317:
318: \item[--] B chooses $m$ constant values $c_1 ,c_2 ,...,c_m $ that satisfy
319: the condition of one-way independence, i.e. each $c_i $ is not a
320: factor of $\prod\nolimits_{j \ne i} {c_j } $. These values together
321: with modulus $M$ are public parameters and can be used for multiple
322: coin generations.
323:
324: \item[--] To generate $m$ coins, B picks a random value
325: $X_N $ and computes:
326: \[
327: C = c_1 c_2 ...c_m \bmod E \quad\textrm{where } E = (p - 1)(q - 1)
328: \]
329: \[
330: X_0 = h_1 (h_2 (...(h_m (X_N )))) = X_N ^{\phantom{N}C}\bmod M
331: \]
332: \[
333: X_i = h_1 (h_2 (...(h_{i - 1} (h_{i + 1} (...(h_m (X_N ))))))) = X_N
334: ^{\phantom{N}C\,c_i ^{ - 1}\bmod E}\bmod M\mbox{ , }i = 1,...,m
335: \]
336:
337: Now B has $m$ coins $(X_i ,c_i )$.
338:
339: \item[--] B keeps $X_0 $ in a public list of coin roots.
340:
341: \item[--] For prevention of double-spending B keeps another list of all
342: unspent coins. In addition, B can also generate vendor-specific as
343: well as customer-specific coins by using some bit portions of
344: constants $c_i $ to form vendor ID and customer ID, similar to the
345: technique used in MicroMint scheme.
346:
347: \item[--] C buys a sufficiently large number of coins from B before making
348: purchases.
349:
350: \end{itemize}\vspace{-1ex}
351:
352: \noindent\textsc{Payment}:
353:
354: \begin{itemize}\itemsep 0pt\parskip 0pt\vspace{-1ex}
355:
356: \item[--] C pays a coin $(X_i ,c_i )$ to vendor V.
357:
358: \item[--] V verifies the coin by computing $X_0 = X_i ^{c_i }\bmod M$, and
359: checks if $X_0 $ is in the list of coin roots. Note that this list
360: is relative small and does not change frequently so C could keep it
361: locally.
362:
363: \item[--] To assure that a coin was not double-spent, V either checks the
364: list of unspent coins on-line with B, or checks (off-line) the list
365: of coins he already received if the coin is vendor-specific.
366:
367: \end{itemize}\vspace{-1ex}
368:
369: \noindent\textsc{Redemption}:
370:
371: \begin{itemize}\itemsep 0pt\parskip 0pt\vspace{-1ex}
372:
373: \item[--] V deposits the coins he got from customers to B and receives an
374: amount corresponding to number of coins.
375:
376: \end{itemize}\vspace{-1ex}
377:
378: At the end of the coin validity period, C can sell unused coins back
379: to B or exchange them for new coins.
380:
381: The proposed above scheme has several advantages:
382:
383: \begin{itemize}\itemsep 0pt\parskip 0pt\vspace{-1ex}
384:
385: \item[--] Coins are hard to forge under the RSA assumption.
386:
387: \item[--] Payment can be made off-line by using vendor-specific coins.
388:
389: \item[--] If customer-specific coins are not used, the scheme is anonymous
390: and untraceable because coins contain no customer information and
391: there are no links between coins.
392:
393: \end{itemize}\vspace{-1ex}
394:
395: However, the disadvantages of this scheme are:
396:
397: \begin{itemize}\itemsep 0pt\parskip 0pt\vspace{-1ex}
398:
399: \item[--] Generation and verification of coins is not very efficient. Each
400: coin requires one modular exponentiation to generate or verify it,
401: which is much slower than normal hash calculation.
402:
403: \item[--] The list of unspent coins can be very big, though this is a
404: common problem of most coin-based schemes.
405:
406: \end{itemize}\vspace{-1ex}
407:
408: To overcome these disadvantages, we propose a modified scheme with
409: larger size hash chains (i.e. with $n > 1)$. In this scheme, B
410: generates $m$ chains of coins at once, rather than $m$ single coins.
411: Each coin chain is similar to the hash chain used in the PayWord
412: scheme.
413:
414: \subsection{The S2 scheme}
415:
416: \noindent\textsc{Setup}:
417:
418: \begin{itemize}\itemsep 0pt\parskip 0pt\vspace{-1ex}
419:
420: \item[--] B selects public parameters $M$ and $c_1 ,c_2 ,...,c_m $ in the
421: same way as in the S1 scheme. Let $n$ be the size of the hash chains
422: (for simplicity we assume all dimensions have the same size i.e.
423: $n_1 = n_2 = ... = n_m = n)$.
424:
425: \item[--] B picks a random value $X_N $ and computes:
426: \[
427: C = c_1 ^nc_2 ^n...c_m ^n\bmod E \quad\textrm{where } E = (p - 1)(q
428: - 1)
429: \]
430: \[
431: X_0 = X_N ^{\phantom{N}C}\bmod M
432: \]
433: \[
434: X_i = X_N ^{\phantom{N}C\,c_i ^{ - n}\bmod E}\bmod M
435: \quad\textrm{for }i = 1,2,...,m
436: \]
437:
438: Now B has $m$ coin chains $(X_i ,c_i )$. Each of those chains
439: contains exactly $n$ coins $(x_{i,j} ,c_i ,j)$ for $j = 1,2,...,n$
440: where:
441:
442: \[
443: x_{i,j} = x_{i,j + 1} ^{\phantom{ij}c_i }\bmod M \quad\textrm{for }
444: i = 1,2,...,m \textrm{ and } j = 0,1,...,n - 1
445: \]
446: \[
447: x_{i,n} = X_i \quad\textrm{and}\quad x_{i,0} = X_0
448: \]
449:
450: The coins from one coin chain must be paid to the same vendor.
451:
452: \item[--] For double-spending prevention, now there is no need to keep
453: track of all unspent coins. Instead, B keeps the list of first coins
454: of all unused chains.
455:
456: \item[--] As in the S1 scheme, coin chains can be vendor-specific as well
457: as customer-specific.
458:
459: \item[--] C buys coin chains from B before making purchases.
460:
461: \end{itemize}\vspace{-1ex}
462:
463: \noindent\textsc{Payment}:
464:
465: \begin{itemize}\itemsep 0pt\parskip 0pt\vspace{-1ex}
466:
467: \item[--] C pays a vendor V the coins from a coin chain. The first coin of
468: the chain $(x_{i,1} ,c_i ,1)$ is verified by computing $X_0 =
469: x_{i,0} = x_{i,1} ^{\phantom{i}c_i }\bmod M$ and lookup of $X_0 $ in
470: the list of chain roots. It is also checked for double-spending by
471: lookup in the list of unused chains. Any subsequent coin is verified
472: by checking that it hashes to the previous coin in the chain, as in
473: the PayWord scheme:
474: \[
475: h_i (x_{i,j + 1} ) = x_{i,j + 1} ^{\phantom{ij}c_i }\bmod M \equiv
476: x_{i,j}
477: \]
478:
479: \end{itemize}\vspace{-1ex}
480:
481: \noindent\textsc{Redemption}:
482:
483: \begin{itemize}\itemsep 0pt\parskip 0pt\vspace{-1ex}
484:
485: \item[--] V deposits the last coin (i.e. the coin with highest index $j)$
486: of each coin chain he got from customers to B and receives an amount
487: corresponding to number of coins.
488:
489: \end{itemize}\vspace{-1ex}
490:
491: Comparing with the S1 scheme, this modified scheme retains all
492: advantages of S1, but storage requirement is reduced by factor of
493: $n$. In fact, B keeps track of only the first coins of $n$-coin
494: chains.
495:
496: Another advantage of this scheme is more efficient coin generation.
497: Because B knows the factorization of M, he can compute the starting
498: node of a coin chain by just one modular exponentiation. Thus the
499: cost of this computational expensive operation is shared over all
500: coins of the chain. Similarly, B can also verify coin chains that he
501: got from vendors by computing one modular exponentiation per chain.
502:
503: Generally speaking, the S2 scheme combines the advantages of two
504: approaches. A first approach uses unrelated coins that are
505: convenient for payments to multiple vendors. Another approach uses
506: chains of coins that are easy to generate and verify. In our scheme
507: different coin chains are unrelated, while coins within a chain are
508: generated and verified only by repeated hashing.
509:
510:
511:
512: \section{Improve PayWord Scheme by Using MDHC}
513: \label{ImprovePayword}
514:
515: The PayWord scheme has been proposed in \cite{RS96}. It is based on
516: one-way hash chains described in the section \ref{MDHC}. In this
517: scheme, before making purchases a customer C generates a hash chain
518: $x_0 ,x_1 ,...x_n $ (that is a chain of paywords) and sends his
519: signature of the root $x_0 $ to the vendor V. The customer then
520: makes a payment to V by revealing the next payword, which can be
521: verified by checking that it hashes to the previous payword.
522:
523: The PayWord scheme allows a vendor to aggregate successive payments
524: from a customer by sending only last payword he got from the
525: customer to the bank for redemption. However, a vendor cannot
526: aggregate payments of different customers, nor can a customer use
527: the same chain of paywords to make payments to different vendors,
528: because there is no way to merge different hash chains.
529:
530: By using MDHC, we can improve PayWord scheme in a number of ways.
531: Below we briefly describe two of such possible improvements. Note
532: that some irrelevant details in these descriptions are omitted for
533: convenience.
534:
535: \subsection{Multiple denominations}
536:
537: In the original PayWord scheme the size of the hash chain must be
538: large enough. For example, if each micropayment is worth 1 cent and
539: total payment is up to {\$}100, then a chain with size of 10,000
540: must be generated, which requires 10,000 hash calculations.
541:
542: We can reduce the number of hash calculations by using MDHC instead
543: of linear hash chain. The idea is that every dimension of MDHC will
544: be associated with different weight (or denomination) according to
545: some number system (e.g. decimal or binary).
546:
547: Suppose we have an $m$-dimensional hash chain with size of $n$. If
548: one step in the ($i$+1)$^{th}$ dimension is equivalent to $(n + 1)$
549: steps in $i^{th}$ dimension, then a node $x_{k_1 ,k_2 ,...,k_m } $
550: corresponds to the value:
551: \[
552: k_1 + k_2 (n + 1) + k_3 (n + 1)^2 + ... + k_m (n + 1)^{m - 1}
553: \]
554:
555: The maximal value that could be represented by this hash chain is $N
556: = (n + 1)^m - 1$ and the number of hash calculations required to
557: generate the hash chain is $n\log _{n + 1} (N + 1)$. In the case of
558: a binary number system (i.e. $n = 1)$ it is $\log _2 (N + 1)$.
559:
560: Returning to the example above, the hash chain now requires just 14
561: calculations to generate.
562:
563: Similarly, verification of the payword also requires significantly
564: less calculations than in the case of the original PayWord scheme.
565:
566: \subsection{Multiple vendors}
567:
568: In the PayWord scheme a hash chain can be used for payments to only
569: one vendor. A customer must generate different hash chains for
570: payment to different vendors.
571:
572: We can overcome this drawback by using MDHC as well. Let every
573: vendor $\mbox{V}_i $ in the payment system is assigned a different
574: hash function $h_i $ (i.e. a public parameter $c_i $ in the case of
575: RSA modular exponentiation).
576:
577: Now, in order to make payment to $m$ different vendors, a customer
578: generates an $m$-dimensional hash chain with their public parameters
579: $c_i $ and signs its root. The customer then makes a payment to
580: $\mbox{V}_i $ by revealing the next payword in the $i^{th}$
581: dimension, starting from the root of hash chain.
582:
583: In particular, if the current payword is $x_{k_1 ,k_2 ,...,k_i
584: ,...,k_m } $, the next payword in $i^{th}$ dimension will be $x_{k_1
585: ,k_2 ,...,k_i + 1,...,k_m } $.
586:
587: At the end of the day, vendors deposit the last paywords they got to
588: the bank for redemption. The bank picks the last payword (which is
589: the one with highest indices) among paywords with certain root
590: (which all come from one customer). Finally, the bank credits
591: vendors $\mbox{V}_i $ by the amount equivalent to $k_i $, and debits
592: the customer's account accordingly.
593:
594: There could be other possible improvements to the PayWord scheme by
595: using MDHC. For example we can aggregate payments of different
596: customers into a single MDHC that is generated by the bank, or we
597: can construct a payment scheme with multiple currencies, etc.
598:
599:
600:
601: \section{Conclusion}
602: \label{Conclusion}
603:
604: The proposed multi-dimensional hash chain is a simple and efficient
605: construction for one-way hash chains. Whereas a traditional one-way
606: hash chain has a storage-computational complexity of $O(n)$, our
607: construction achieves a complexity of $O(\log _2 n)$, which is
608: comparable with the best result among other recently proposed
609: constructions.
610:
611: We show that multi-dimensional hash chains can be very useful in
612: micropayment schemes. In particular, we suggest two cash-like
613: micropayment schemes based on MDHC with RSA modular exponentiation
614: as one-way hash function. The first scheme utilizes coins that are
615: hard to forge under the RSA assumption. This scheme could be also
616: off-line and untraceable. The second scheme has additional
617: advantages including very efficient coin generation/verification and
618: much less storage requirements.
619:
620: We also point out some possible improvements to PayWord and similar
621: schemes by using MDHC, including payword chains with multiple
622: denominations, and a scheme that allows payment to multiple vendors
623: using the same payword chain.
624:
625: An open issue for our construction is whether another one-way hash
626: function can be found that meets MDHC requirements, and at the same
627: time is more efficient than RSA modular exponentiation.
628:
629:
630:
631: \begin{thebibliography}{99}
632:
633: \bibitem {AMS96}R. Anderson, H. Manifavas, and C. Sutherland. NetCard - a
634: practical electronic cash system. \textit{Proceedings of the 4th
635: Security Protocols International Workshop (Security Protocols)},
636: pp.49--57, Lecture Notes in Computer Science vol. 1189.
637: Springer-Verlag, Berlin, 1996.
638:
639: \bibitem {BM94}J. Benaloh, M. de Mare. One-Way Accumulators: A Decentralized
640: Alternative to Digital Signatures. \textit{Advances in Cryptology --
641: EUROCRYPT `93}. LNCS, vol.765, pp.274--285, Springer-Verlag, 1994.
642:
643: \bibitem {CJ02}D. Coppersmith and M. Jakobsson. Almost optimal hash sequence
644: traversal. \textit{Proceedings of the Fourth Conference on Financial
645: Cryptography (FC `02)}, Lecture Notes in Computer Science, 2002.
646:
647: \bibitem {HJP03}Y. Hu, M. Jakobsson and A. Perrig. Efficient Constructions
648: for One-way Hash Chains. \textit{SCS Technical Report Collection}, 2003.\\
649: http://reports-archive.adm.cs.cmu.edu/anon/2003/CMU-CS-03-220.ps
650:
651: \bibitem {HSW96}R. Hauser, M. Steiner, and M. Waidner. Micro-payments based
652: on iKP. \textit{Proceedings of the} \textit{14th Worldwide Congress
653: on Computer and Communications Security Protection}, pp.67--82,
654: Paris, 1996.
655:
656: \bibitem {Jak02}M. Jakobsson. Fractal hash sequence representation and
657: traversal. \textit{Proceedings of the 2002 IEEE International
658: Symposium on Information Theory (ISIT `02)}, pp.437--444, 2002.
659:
660: \bibitem {JY96}C. Jutla and M. Yung. PayTree: amortized-signature for
661: flexible micropayments. \textit{Proceedings of the 2nd USENIX
662: Workshop on Electronic Commerce}, pp.213--21, Oakland, California,
663: November 1996.
664:
665: \bibitem {RS96}R. Rivest and A. Shamir. PayWord and MicroMint: two simple
666: micropayment schemes. \textit{Proceedings of the 4th Security
667: Protocols International Workshop (Security Protocols)}, pp.69--87,
668: Lecture Notes in Computer Science vol. 1189. Springer-Verlag,
669: Berlin, 1996.
670:
671: \bibitem {RSA78}R. Rivest, A. Shamir, and L.M. Adleman. A method for
672: obtaining digital signatures and public-key cryptosystems. In
673: \textit{Communications of the ACM, 21(2).} pp.120--126, February
674: 1978.
675:
676: \bibitem {Sch98}B. Schoenmakers. Security aspects of the Ecash payment
677: system. \textit{State of the Art in Applied Cryptography: Course on
678: Computer Security and Industrial Cryptography - Revised Lectures},
679: pp.338--52, Lecture Notes in Computer Science vol. 1528.
680: Springer-Verlag, Berlin, 1998.
681:
682: \bibitem {Sel03}Yaron Sella. On the computation-storage trade-offs of hash
683: chain traversal. \textit{Proceedings of Financial Cryptography 2003
684: (FC 2003)}, 2003.
685:
686: \bibitem {Sha83}A. Shamir. On the Generation of Cryptographically Strong
687: Pseudorandom Sequences. \textit{ACM Transactions on Computer Systems
688: (TOCS)}, Volume 1, Issue 1, pp.38--44, 1983.
689:
690: \end{thebibliography}
691: \end{document}
692: