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

Diff of /manuscripts/Sigs/internal.rst

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

revision 1.1 by tjl, Mon May 19 13:35:54 2003 UTC revision 1.2 by tjl, Mon May 19 15:06:00 2003 UTC
# Line 49  One-time Signature Key Boosting Line 49  One-time Signature Key Boosting
49  Introduction  Introduction
50  ============  ============
51    
 One-time signatures were originally proposed independently  
 by [XXX] and [XXX]. Since then, numerous variations  
 and improvements have been published [XXX].  
 Despite their limitations, one-way signatures have  
 attracted considerable interest because  
 their operation  
 does not  
 rely on  
 trapdoor functions, whose strength is based on  
 unproven number-theoretic assumptions such as the  
 difficulty of factoring large integers [XXX].  
   
 This is important for, e.g., long-term digital publishing  
 where the usual recommended digital signature expiration  
 time of two years[XXX] is inconvenient.  
   
   
 In this article, we introduce a new signature scheme,  
 based on one-time signatures and a random oracle,  
 that can be used any number of times without keeping track  
 of private keys that have already been used.  
 In the following Sections, we first  
 review one-time signatures, and subsequently  
 describe our algorithm.  
 Then, we analyze the tradeoffs in it and other one-time signature  
 schemes.  
 After this, we discuss the different variants of our  
 algorithm based on how the path through the key tree  
 is selected, and finally conclude.  
   
52  One-time Signatures  One-time Signatures
53  ===================  ===================
54    
# Line 93  One-time Signatures Line 63  One-time Signatures
63      may be orders of magnitude faster than operations      may be orders of magnitude faster than operations
64      in schemes like DSA or RSA.      in schemes like DSA or RSA.
65    
 One-time signature schemes [XXX] are based  
 on one-way functions, i.e., functions `$y=f(x)$` such  
 as block ciphers or cryptographic hashes so that  
 that given `$y$` it is infeasible to find `$x$`.  
 Generally, given a one-way function f, the signer generates a set  
 of (pseudo)random numbers and and publishes `$f(x)$` for each  
 `$x$` in the set. This is the public key. To sign a message,  
 the signer employs a deterministic algorithm to select  
 a subset of the random numbers, and publishes them  
 as the signature. The signature can be verified by running  
 the same deterministic algorithm, checking that the  
 resultant set of numbers has been published, and comparing  
 f(x) for each published number x against the values  
 in the public key.  
   
 To prevent an attacker from using a subset of the  
 published numbers to sign a different message,  
 the deterministic algorithm is chosen so that no set  
 in its range is a true subset of any other set in its range,  
 or that finding such a pair of sets is infeasible.  
   
 Private keys in one-time signature schemes can generally  
 only be used to sign a single message. If the same key  
 were used to sign multiple messages, an attacker might  
 be able to combine the random numbers published in each  
 signature to find a new valid signature.  
 However, some schemes have been recently proposed that  
 allow a small number of messages to be signed without  
 becoming completely insecure [BiBa-andalso-betterthanbiba]_.  
   
 Another way to allow n messages to be signed with the  
 same public key is to create n different key pairs,  
 and then compute a hash tree over the public keys.  
 This is only practical for relatively small n.  
   
 Yet another approach is to sign one or more new public keys  
 as the last message signed with the old key. This way,  
 an arbitrary number of messages can be signed.  
 However, verification time increases, and the signer  
 still needs to keep track of which private keys  
 have already been used in order not to compromise security.  
   
 In section XXX, we give a description of existing  
 one-time signature algorithms with their different  
 tradeoffs.  
   
66  One-time Signature Key Boosting  One-time Signature Key Boosting
67  ===============================  ===============================
68    
# Line 147  algorithm which takes a random number as Line 71  algorithm which takes a random number as
71  2) a random oracle which generates an apparently random  2) a random oracle which generates an apparently random
72  bitstring from a given number.  bitstring from a given number.
73    
 The private key for this scheme is simply a private key  
 for the underlying one-time-signature primitive,  
 and the public key is the corresponding one-time-signature  
 public key.  
   
 To generate a signature for the message `$m$`,  
 we start by setting `$p$` to the  
 private key.  
 Then, we iterate over the following steps `$N$` times:  
   
 1. Choose `$x \\in [1,q]$`. The exact algorithm for making this  
    choice parametrizes the algorithm; possible choices are discussed  
    below.  
   
 2. Use the random oracle to generate the `$x$th` new private key  
    `$p_x$` from `$p$`.  
   
 3. Sign the corresponding public key with `$p$`. This does  
    not present  
    a problem for the `$q$`-time signature algorithm, since  
    the random oracle is deterministic and  
    no more than `$q$` strings will therefore be signed  
    with any given `$p$`.  
   
 4.  `$p \\leftarrow p_x$`  
   
 After the last iteration, `$p$` contains the private key to be used to sign  
 the actual message `$m$` using the one-time-signature primitive.  
 The signature consists of this signature and the whole chain  
 of signatures connecting this to the original public key.  
   
 To verify a signature, the verifier only needs to traverse the  
 chain of signatures  
   
 As long as the algorithm for choosing `$x$` does not yield the same  
 chain for two messages, the signatures XXX  
 The effects of this algorithm and the parameters `$q$` and `$N$`  
 are analyzed in the next section.  
   
74  Security of this construction  Security of this construction
75    
76    
# Line 214  Choice of `$x$` Line 99  Choice of `$x$`
99  Deterministic: a Full Digital Signature Algorithm Feature Set  Deterministic: a Full Digital Signature Algorithm Feature Set
100  -------------------------------------------------------------  -------------------------------------------------------------
101    
 - Arbitrary (pseudo-infinite, i.e. infinite wouldn't help any more)  
   number of keys, if for each *hash* its own private key for signing it!  
   This means that `$N \\log k \\ge h$`  
   
     - this is a nice theoretical result: it *is* possible to sign anything  
       without trapdoors - full feature set of normal (non-one-time) DSs  
   
     - feasible  
   
     - impractical; actual numbers below  
   
   
   
       - Works with `$k=10$`, `$N=16$` for SHA-1; sig length  
         is about `$16(r'+s')$`; realistically, about  
         25KB using Merkle-Winternitz with `$n=2$`.  
   
         Formally, this is:  
         Key boosting(16, Merkle hash tree(10, Merkle-Winternitz(160,160,2), 10))  
   
         and has the octuplet??  
   
 - Security not straightforward:  
   There is a large number of hashes used, and a collision  
   between any two could allow forging of signatures.  
   birthday attacks, ...  
   
 - AAAGH We can't use 80-bit hashes inside the tree, and it's  
   questionable whether we can even use 160-bit!  
   Reason: if you sign a lot of docs, chances are  
   you get a common birthday: two instances  
   of the same key used at two different branches.  
   
   Especially since we use N primitive signatures for each sig.  
   
   This needs to be reasoned out carefully.  
   
102  Probabilistic limited  Probabilistic limited
103  ---------------------  ---------------------
104    
# Line 661  Efficiency of key boosting Line 509  Efficiency of key boosting
509  Octuplet: `${q'}^N, b, N(r'+s'), r', h,  Octuplet: `${q'}^N, b, N(r'+s'), r', h,
510  c_0', N(c_0'+c_s'), Nc_v)$`  c_0', N(c_0'+c_s'), Nc_v)$`
511    
512    - We can't use 80-bit hashes inside the tree,
513    
514  Tradeoffs in deterministic key boosting    Reason: if you sign a lot of docs, chances are
515  ---------------------------------------    you may a common birthday: two instances
516      of the same key used at two different branches.
517      An accidental attack ;)
518    
519  Supporting multiple signatures is possible e.g. in BiBa,    Especially since we use N primitive signatures for each sig.
 but inefficient. Merkle hash trees better  
520    
521  we want the full deterministic    This needs to be reasoned out carefully.
 algorithm,  
 that, which requires `$ nN = 160 $`.  
   
 All choices produce a *linear* operation from the characteristics  
 of a scheme to the characteristics of the other scheme.  
 Particularly, the signature length increases linearly with `$N$`,  
 and the time to sign grows exponentially with `$n$` and  
 linearly (in the opposite direction!) with `$N$`.  
522    
523    
524    
525    Tradeoffs in deterministic key boosting
526    ---------------------------------------
527    
528    
529    
530  - we demand security level `$2^{-160}$` for our underlying schemes  - we demand security level `$2^{-160}$` for our underlying schemes
531    
# Line 704  linearly (in the opposite direction!) wi Line 550  linearly (in the opposite direction!) wi
550      `$t=168$`, `$k=69$`      `$t=168$`, `$k=69$`
551      `$t=175$`, `$k=62$`      `$t=175$`, `$k=62$`
552    
   - Bleichenbacher-Maurer.  
     To sign 160 bits, we need `$n=29$`.  
     Signatures are 90 hashes  
   
553    
554  Conclusion  Conclusion
555  ==========  ==========
556    
 - key idea: using the deterministic bit string for each privkey  
   
 In long-term digital publishing, the time limits on normal digital signatures  
 are  
   
 - we expect our methods to be improved on considerably; we have shown it is *feasible*,  
   now someone needs to show it's *practical*  
   
 - hashes *do* get broken, REF  
   
557  foo  foo
558    
559  .. bibliography:: gzigzag  .. bibliography:: gzigzag

Legend:
Removed from v.1.1  
changed lines
  Added in v.1.2

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