/[gzz]/manuscripts/Sigs/article.rst
ViewVC logotype

Diff of /manuscripts/Sigs/article.rst

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.108 by tjl, Mon May 19 13:40:36 2003 UTC revision 1.109 by tjl, Mon May 19 15:05:59 2003 UTC
# Line 1  Line 1 
1  ===============================  ==============================================================================================
2  One-time Signature Key Boosting  One-time Signature Key Boosting: Full Digital Signature Feature Set without Trapdoor Functions
3  ===============================  ==============================================================================================
4    
5  ..  Benja: I'm restarting the writing.  ..  Benja: I'm restarting the writing.
6    
# Line 11  One-time Signature Key Boosting Line 11  One-time Signature Key Boosting
11    
12      I'm sure the referees will tell us if we should review them...      I'm sure the referees will tell us if we should review them...
13    
14    Abstract:
15    
16    - Full DS feature set
17    
18    - unlimited time
19    
20    - hash function strength, no unproven complexity results
21    
22    - In conjunction with Merkle hash trees, used to generate
23      a family of trade-offed schemes whose time and space characteristics
24      depend linearly on the underlying schemes'.
25    
26    - recursive application of
27    
28    
29    
30  Introduction  Introduction
31  ============  ============
32    
33    One-time signatures were originally proposed independently
34    by [XXX] and [XXX]. Since then, numerous variations
35    and improvements have been published [XXX].
36    Despite their limitations, one-way signatures have
37    attracted considerable interest because
38    their operation
39    does not
40    rely on
41    trapdoor functions, whose strength is based on
42    unproven number-theoretic assumptions such as the
43    difficulty of factoring large integers [XXX].
44    
45    This is important for, e.g., long-term digital publishing
46    where the usual recommended digital signature expiration
47    time of two years[XXX] is inconvenient.
48    
49    
50    In this article, we introduce a new signature scheme,
51    based on one-time signatures and a random oracle,
52    that can be used any number of times without keeping track
53    of private keys that have already been used.
54    In the following Sections, we first
55    review one-time signatures, and subsequently
56    describe our algorithm.
57    Then, we analyze the tradeoffs in it and other one-time signature
58    schemes.
59    After this, we discuss the different variants of our
60    algorithm based on how the path through the key tree
61    is selected, and finally conclude.
62    
63    
64  One-time Signatures  One-time Signatures
65  ===================  ===================
66    
67    One-time signature schemes [XXX] are based
68    on one-way functions, i.e., functions `$y=f(x)$` such
69    as block ciphers or cryptographic hashes so that
70    that given `$y$` it is infeasible to find `$x$`.
71    Generally, given a one-way function f, the signer generates a set
72    of (pseudo)random numbers and and publishes `$f(x)$` for each
73    `$x$` in the set. This is the public key. To sign a message,
74    the signer employs a deterministic algorithm to select
75    a subset of the random numbers, and publishes them
76    as the signature. The signature can be verified by running
77    the same deterministic algorithm, checking that the
78    resultant set of numbers has been published, and comparing
79    f(x) for each published number x against the values
80    in the public key.
81    
82    To prevent an attacker from using a subset of the
83    published numbers to sign a different message,
84    the deterministic algorithm is chosen so that no set
85    in its range is a true subset of any other set in its range,
86    or that finding such a pair of sets is infeasible.
87    
88    Private keys in one-time signature schemes can generally
89    only be used to sign a single message. If the same key
90    were used to sign multiple messages, an attacker might
91    be able to combine the random numbers published in each
92    signature to find a new valid signature.
93    However, some schemes have been recently proposed that
94    allow a small number of messages to be signed without
95    becoming completely insecure [BiBa-andalso-betterthanbiba]_.
96    
97    Another way to allow n messages to be signed with the
98    same public key is to create n different key pairs,
99    and then compute a hash tree over the public keys.
100    This is only practical for relatively small n.
101    
102    Yet another approach is to sign one or more new public keys
103    as the last message signed with the old key. This way,
104    an arbitrary number of messages can be signed.
105    However, verification time increases, and the signer
106    still needs to keep track of which private keys
107    have already been used in order not to compromise security.
108    
109    
110  One-time Signature Key Boosting  One-time Signature Key Boosting
111  ===============================  ===============================
112    
113  Full Digital Signature Feature Set without Trapdoors  
114  ====================================================  - based on underlying $q$-time scheme --- usually Merkle hash tree
115      of one-time scheme.
116    
117    - req. also random oracle
118    
119    
120    
121    
122    The private key for this scheme is simply a private key
123    for the underlying one-time-signature primitive,
124    and the public key is the corresponding one-time-signature
125    public key.
126    
127    To generate a signature for the message `$m$`,
128    start by setting `$p$` to the
129    private key.
130    Then, we iterate over the following steps `$N$` times:
131    
132    1. Choose the tree branch `$x \\in [1,q]$`.
133       The exact algorithm for making this
134       choice parametrizes the algorithm; possible choices are discussed
135       below.
136    
137    2. Use the random oracle to generate the `$x$th` new private key
138       `$p_x$` from `$p$`.
139    
140    3. Sign the corresponding public key with `$p$`. This does
141       not present
142       a problem for the `$q$`-time signature algorithm, since
143       the random oracle is deterministic and
144       no more than `$q$` strings will therefore be signed
145       with any given `$p$`.
146    
147    4.  `$p \\leftarrow p_x$`
148    
149    After the last iteration, `$p$` contains the private key to be used to sign
150    the actual message `$m$` using the one-time-signature primitive.
151    The signature consists of this signature and the whole chain
152    of signatures connecting this to the original public key.
153    To verify a signature, the verifier only needs to traverse the
154    chain of signatures from the public key to the last signature.
155    
156    As long as the algorithm for choosing `$x$` does not yield the same
157    chain for two messages, the signatures will be no weaker than normal
158    one-time signatures of the underlying scheme.
159    
160    The length of the signature will be `$N$` times the length
161    of a signatures and a public key in the underlying scheme.
162    The time to sign is also `$N$` times the time to generate a public
163    key and sign in the
164    underlying scheme, plus the accesses to the random oracle.
165    The time to verify is also equal to the time of verifying `$N$`
166    signatures in the underlying scheme.
167    
168    Full Digital Signature Feature Set without Trapdoor Functions
169    =============================================================
170    
171    In this Section, we describe our central theoretical result:
172    a feasible scheme for general 160-bit digital signatures.
173    Our scheme has no time limits for private keys
174    because it is not based on complexity of inverting trapdoor functions.
175    The scheme requires only that one-way functions and random oracles exist.
176    To our knowledge, this is has not previously been possible without
177    remembering all previously signed documents or changing to a new
178    private key after a given number of signatures.
179    Our scheme only requires the private key to be remembered; no other
180    state is required.
181    
182    In key boosting, the choise of the tree branch `$x$` to follow at each
183    node is crucial to the nature of the algorithm.
184    In order to be able to sign 160-bit hashes securely, we generate
185    a unique private key for each 160-bit hash.
186    This is done by requiring that `$q^N > 2^{160}$` and choosing
187    `$x$` based on the bits of the hash to be signed.
188    - however, we *can* use OTS algorithms with chosen-message attacks since final pubkey
189      not known
190    
191    we want the full deterministic
192    algorithm, for 160-bit hashes
193    that, which requires `$ nN = 160 $`.
194    
195    All choices produce a *linear* operation from the characteristics
196    of a scheme to the characteristics of the other scheme.
197    Particularly, the signature length increases linearly with `$N$`,
198    and the time to sign grows exponentially with `$n$` and
199    linearly (in the opposite direction!) with `$N$`.
200    
201    
202        - feasible
203    
204        - impractical; actual numbers below
205    
206          - Works with `$k=10$`, `$N=16$` for SHA-1; sig length
207            is about `$16(r'+s')$`; realistically, about
208            25KB using Merkle-Winternitz with `$n=2$`.
209    
210            Formally, this is:
211            Key boosting(16, Merkle hash tree(10, Merkle-Winternitz(160,160,2), 10))
212    
213            and has the octuplet??
214    
215    - Security not straightforward:
216      There is a large number of hashes used, and a collision
217      between any two could allow forging of signatures.
218      birthday attacks, ...
219    
220      - Bleichenbacher-Maurer.
221        To sign 160 bits, we need `$n=29$`.
222        Signatures are 90 hashes
223    
224    Supporting multiple signatures is possible e.g. in BiBa,
225    but inefficient. Merkle hash trees better
226    
227    
228  Practical Variants  Practical Variants
229  ==================  ==================

Legend:
Removed from v.1.108  
changed lines
  Added in v.1.109

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26