/[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.85 by benja, Sun May 18 17:14:19 2003 UTC revision 1.86 by benja, Sun May 18 17:34:04 2003 UTC
# Line 138  have already been used in order not to c Line 138  have already been used in order not to c
138  XXX Following descriptions not into article, maybe into tech report?  XXX Following descriptions not into article, maybe into tech report?
139  We need these to make sure our numbers are right  We need these to make sure our numbers are right
140    
 Lamport  
 -------  
   
 - private key: `$2b$` random numbers  
   
 - public key: hashes of private key - calculate `$2b$` hashes  
   
 - sign: reveal one of each pair of RNs in private key corresponding to signing 0 or 1  
   Signature contains `$b$` of the random numbers  
   
 - verify: check that the revealed RNs hashes to right hash in public key -  
   calculate `$b$` hashes  
   
 Merkle (?)  
 ----------  
   
 This scheme is an improvement over Lamport, needing  
 only `$k=b+\\lceil \\log{2} b \\rceil$` hashes.  
   
 Let `$m_i$` be the `$i$`-th bit of the message.  
   
 - private key: A list of `$k$` random numbers `$R_i$`.  
   
 - public key: Compute a list of `$k$` hashes `$P_i=H(R_i)$`;  
   the hash of this list is the public key.  
   
 - sign: Reveal the `$R_i$` for `$i \\le b$` if the  
   `$m_i=0$`. Compute the checksum `$c=\\sum{m_i}$`,  
   and interpret as a bitstring. Reveal `$R_{b+i}$`  
   if the `$i$`-th bit of the bitstring is zero.  
   
 - verify:  
   
 Merkle-Winternitz  
 -----------------  
   
 This scheme relies on recursive application of the hash function.  
 Let `$n$` be a positive integer and `$k=\\frac{b}{n}$`.  
 Let `$H$` donate the hash function, with `$H^2(x)=H(H(x))$` etc.  
   
 - private key: A list of random numbers `$(R_0,...,R_k)$`.  
   
 - public key: Compute `$P_0=H^{k2^n}(R_0)$`, and  
   `$P_i=H^{2^n}(R_i)$` for `$i>0$`. The hash of  
   `$(P_0,...,P_k)$` is the public key.  
   
   Needs `$2k2^n + 1$` hash function invocations.  
   
 - signature: Split the `$b$`-bit message into `$k$`  
   parts of `$n$` bits each. Interpreted each part  
   as an integer `$k_i$` for `$0 < i \\le k$`.  
   Compute `$S_i=H^{k_i}(R_i)$` for `$i>0$`  
   and `$S_0=H^{2^nk-\\sum{k_i}}(R_0)$`. The tuple  
   `$(S_0,...,S_k)$` is the signature.  
   
   Signing requires `$k2^n$` invocations  
   of the hash function.  
   
 - verification: Compute `$k_i$` as above.  
   Compute `$V_0=H^{\\sum{k_i}}(S_0)$`  
   and `$V_i=H^{2^n-k_i}(S_i)$` for `$i>0$`.  
   Check that the hash of `$(V_0,...,V_i)$`  
   equals the public key.  
   
   Verification requires `$k2^n + 1$` invocations  
   of the hash function.  
   
 BiBa  
 ----  
   
 The signer generates `$t$` random numbers (balls) and publishes  
 their hashes as the public key. A hash function maps each ball  
 to one of `$n$` *bins*, depending on the signed message  
 and a counter, initially zero.  
 If `$w$` balls fall into the same bin, they are published  
 as the signature. If no bin contains at least `$w$` balls,  
 the counter is increased and the procedure is repeated  
 until a '`$w$`-time collision' is found.  
   
 - private key: the `$t$` random numbers  
   
 - public key: the hashes of the random numbers  
   
 - sign: apply the hash function to all balls  
   until a `$w$`-time collision is found  
   
 - verify: verify that the hash function maps the published balls  
   into the same bin; verify that the balls match the public key  
   (i.e., that the public key contains their hashes).  
   
   
 Reyzin  
 ------  
   
 We discuss only the second algorithm, based on subset-intractable  
 functions.  
   
 To sign `$b$` bits, choose `$t$` and `$k$` such that  
 `$ {t \\choose k} \\ge b $`  
   
 Parameters `$t$` and `$k$`.  
   
 - private key: `$t$` random numbers  
   
 - public key: hashes of the random numbers. Calculate `$t$` hashes  
   
 - sign: Hash the message, split hash to `$k$` strings of `$\\log t$` bits.  
   use these as indices to say which numbers to reveal in the signature.  
   Calculate one hash.  
   
 - verify: same deterministic part, check that revealed numbers hash right.  
   
 Probability for successful forgery after `$r$` signatures:  
 `$(rk/t)^k$`  
   
 ?  
   
 Bleichenbacher-Maurer  
 ---------------------  
   
 ASIACRPTO construction  
   
 - Construction for `$H_n$`: a binary tree,  
   at each node 2 hashes combined into one  
   
 - private key: `$3(n+1)$` hash values of tree leaves.  
   Calculate `$9n+2$` hashes. This can sign  
   `$\\lfloor {\\log 51 \\over \\log 2} n \\rfloor$` bits.  
   (XXX Some were not allowable because not minimal???)  
   
 - public key: one hash, the one calculated for the root of the tree  
   
 - sign: message determines which nodes of the tree to reveal;  
   Signature contains `$3(n+1)$` hashes.  
   
 - verify: check that right nodes revealed, and that tree computes right  
   public key - calculate some less than `$9n+2$` hashes  
   
 Merkle hash trees  
 -----------------  
   
 Assume an underlying one-time signature scheme `$S'$`.  
 Generate `$2^n$` public keys through `$S'$`,  
 compute a hash tree over them, publish the root  
 of the tree as the actual public key.  
   
 Assume underlying algorithm using same hash.  
   
 Signature using new public key will not need to contain  
 all the public keys, just path through the tree.  
   
 - private key: `$2^n$` private keys of the underlying algorithm.  
   
 - public key: Calculate the `$2^n$` public keys; hash each  
   public key (if it is longer than a single hash); compute  
   the hash tree. Calculating the public key takes  
   `$2^n c_0$` and calculating the hash tree takes  
   `$2^{n+1}-1$` hash function invocations.  
   
 - sign using one key: Sign with that private key, provide the  
   corresponding public key, and provide the chain of hashes  
   from the hash tree's root to the public key.  
   Only hash invocations in the signing using the underlying algorithm.  
   
 - verify: verify signature with new public key, verify hash chain.  
   
   
141  One-time Signature Key Boosting  One-time Signature Key Boosting
142  ===============================  ===============================
143    
# Line 370  are analyzed in the next section. Line 203  are analyzed in the next section.
203    
204      To sign a *b*-bit message *m*,      To sign a *b*-bit message *m*,
205    
206    Variants: Choosing the Tree Branch
207    ==================================
208    
209    Choice of `$x$`
210    
211    Deterministic: a Full Digital Signature Algorithm Feature Set
212    -------------------------------------------------------------
213    
214    - Arbitrary (pseudo-infinite, i.e. infinite wouldn't help any more)
215      number of keys, if for each *hash* its own private key for signing it!
216      This means that `$N \\log k \\ge h$`
217    
218        - this is a nice theoretical result: it *is* possible to sign anything
219          without trapdoors - full feature set of normal (non-one-time) DSs
220    
221        - realistic? How much does this need?
222    
223          - Works with `$k=10$`, `$N=16$` for SHA-1; sig length
224            is about `$16(r'+s')$`; realistically, about
225            25KB using Merkle-Winternitz with `$n=2$`.
226    
227            Formally, this is:
228            Key boosting(16, Merkle hash tree(10, Merkle-Winternitz(160,160,2), 10))
229    
230            and has the octuplet??
231    
232    - Security not straightforward:
233      There is a large number of hashes used, and a collision
234      between any two could allow forging of signatures.
235      birthday attacks, ...
236    
237    - AAAGH We can't use 80-bit hashes inside the tree, and it's
238      questionable whether we can even use 160-bit!
239      Reason: if you sign a lot of docs, chances are
240      you get a common birthday: two instances
241      of the same key used at two different branches.
242    
243      Especially since we use N primitive signatures for each sig.
244    
245      This needs to be reasoned out carefully.
246    
247    Ordered
248    -------
249    
250    - Keep count of number of signatures made
251    
252    - use bits of count for choosing
253    
254    - this is basically a k-time signature made feasible
255      for large k
256    
257    - mustn't lose count!
258    
259    - can't copy key or restore from backup!
260    
261    - any scheme mapping the *action* of signing uniquely to a number between 0 and `$q$`
262      will work.
263    
264    Probabilistic limited
265    ---------------------
266    
267    Shorter signatures
268    
269    - If less, cannot use information from hash directly, otherwise can attack
270      by giving close relatives
271    
272      - except! Algorithm for choosing `$x$` need not be public. If we hash
273        a different private key plus the content hash or content of the information,
274        we *can* use it here; random oracle
275    
276        - birthday paradox; if collision, someone can forge a signature
277          (relevant if a large number of chosen message attacks)
278    
279      - can use random number; if we sign only 2**20 messages total,
280        choosing randomly from 2**60 keys should be enough, since
281        we expect collisions only at about 2**30 messages signed
282    
283        - birthday paradox again: must not allow the attacker to have
284          2**30 messages being signed
285    
286    - however, collisions *only* invalidate one leaf of the key tree, so
287      it *is* possible to
288      revoke only that leaf, not the whole key.
289    
290  Analysis: Characterizing one-time signature schemes  Analysis: Characterizing one-time signature schemes
291  ===================================================  ===================================================
292    
# Line 474  The values for Bleichenbacher and Maurer Line 391  The values for Bleichenbacher and Maurer
391  - the first levels of signatures may be given in the public key,  - the first levels of signatures may be given in the public key,
392    giving a tradeoff between public key size and signature size.    giving a tradeoff between public key size and signature size.
393    
394  Variants: Choosing the Tree Branch  Lamport
395  ==================================  -------
396    
397  Choice of `$x$`  - private key: `$2b$` random numbers
398    
399  Deterministic: a Full Digital Signature Algorithm Feature Set  - public key: hashes of private key - calculate `$2b$` hashes
 -------------------------------------------------------------  
400    
401  - Arbitrary (pseudo-infinite, i.e. infinite wouldn't help any more)  - sign: reveal one of each pair of RNs in private key corresponding to signing 0 or 1
402    number of keys, if for each *hash* its own private key for signing it!    Signature contains `$b$` of the random numbers
   This means that `$N \\log k \\ge h$`  
403    
404      - this is a nice theoretical result: it *is* possible to sign anything  - verify: check that the revealed RNs hashes to right hash in public key -
405        without trapdoors - full feature set of normal (non-one-time) DSs    calculate `$b$` hashes
406    
407      - realistic? How much does this need?  Merkle (?)
408    ----------
409    
410        - Works with `$k=10$`, `$N=16$` for SHA-1; sig length  This scheme is an improvement over Lamport, needing
411          is about `$16(r'+s')$`; realistically, about  only `$k=b+\\lceil \\log{2} b \\rceil$` hashes.
         25KB using Merkle-Winternitz with `$n=2$`.  
412    
413          Formally, this is:  Let `$m_i$` be the `$i$`-th bit of the message.
         Key boosting(16, Merkle hash tree(10, Merkle-Winternitz(160,160,2), 10))  
414    
415          and has the octuplet??  - private key: A list of `$k$` random numbers `$R_i$`.
416    
417  - Security not straightforward:  - public key: Compute a list of `$k$` hashes `$P_i=H(R_i)$`;
418    There is a large number of hashes used, and a collision    the hash of this list is the public key.
   between any two could allow forging of signatures.  
   birthday attacks, ...  
419    
420  - AAAGH We can't use 80-bit hashes inside the tree, and it's  - sign: Reveal the `$R_i$` for `$i \\le b$` if the
421    questionable whether we can even use 160-bit!    `$m_i=0$`. Compute the checksum `$c=\\sum{m_i}$`,
422    Reason: if you sign a lot of docs, chances are    and interpret as a bitstring. Reveal `$R_{b+i}$`
423    you get a common birthday: two instances    if the `$i$`-th bit of the bitstring is zero.
   of the same key used at two different branches.  
424    
425    Especially since we use N primitive signatures for each sig.  - verify:
426    
427    This needs to be reasoned out carefully.  Merkle-Winternitz
428    -----------------
429    
430  Ordered  This scheme relies on recursive application of the hash function.
431  -------  Let `$n$` be a positive integer and `$k=\\frac{b}{n}$`.
432    Let `$H$` donate the hash function, with `$H^2(x)=H(H(x))$` etc.
433    
434  - Keep count of number of signatures made  - private key: A list of random numbers `$(R_0,...,R_k)$`.
435    
436  - use bits of count for choosing  - public key: Compute `$P_0=H^{k2^n}(R_0)$`, and
437      `$P_i=H^{2^n}(R_i)$` for `$i>0$`. The hash of
438      `$(P_0,...,P_k)$` is the public key.
439    
440  - this is basically a k-time signature made feasible    Needs `$2k2^n + 1$` hash function invocations.
   for large k  
441    
442  - mustn't lose count!  - signature: Split the `$b$`-bit message into `$k$`
443      parts of `$n$` bits each. Interpreted each part
444      as an integer `$k_i$` for `$0 < i \\le k$`.
445      Compute `$S_i=H^{k_i}(R_i)$` for `$i>0$`
446      and `$S_0=H^{2^nk-\\sum{k_i}}(R_0)$`. The tuple
447      `$(S_0,...,S_k)$` is the signature.
448    
449  - can't copy key or restore from backup!    Signing requires `$k2^n$` invocations
450      of the hash function.
451    
452  - any scheme mapping the *action* of signing uniquely to a number between 0 and `$q$`  - verification: Compute `$k_i$` as above.
453    will work.    Compute `$V_0=H^{\\sum{k_i}}(S_0)$`
454      and `$V_i=H^{2^n-k_i}(S_i)$` for `$i>0$`.
455      Check that the hash of `$(V_0,...,V_i)$`
456      equals the public key.
457    
458  Probabilistic limited    Verification requires `$k2^n + 1$` invocations
459      of the hash function.
460    
461    BiBa
462    ----
463    
464    The signer generates `$t$` random numbers (balls) and publishes
465    their hashes as the public key. A hash function maps each ball
466    to one of `$n$` *bins*, depending on the signed message
467    and a counter, initially zero.
468    If `$w$` balls fall into the same bin, they are published
469    as the signature. If no bin contains at least `$w$` balls,
470    the counter is increased and the procedure is repeated
471    until a '`$w$`-time collision' is found.
472    
473    - private key: the `$t$` random numbers
474    
475    - public key: the hashes of the random numbers
476    
477    - sign: apply the hash function to all balls
478      until a `$w$`-time collision is found
479    
480    - verify: verify that the hash function maps the published balls
481      into the same bin; verify that the balls match the public key
482      (i.e., that the public key contains their hashes).
483    
484    
485    Reyzin
486    ------
487    
488    We discuss only the second algorithm, based on subset-intractable
489    functions.
490    
491    To sign `$b$` bits, choose `$t$` and `$k$` such that
492    `$ {t \\choose k} \\ge b $`
493    
494    Parameters `$t$` and `$k$`.
495    
496    - private key: `$t$` random numbers
497    
498    - public key: hashes of the random numbers. Calculate `$t$` hashes
499    
500    - sign: Hash the message, split hash to `$k$` strings of `$\\log t$` bits.
501      use these as indices to say which numbers to reveal in the signature.
502      Calculate one hash.
503    
504    - verify: same deterministic part, check that revealed numbers hash right.
505    
506    Probability for successful forgery after `$r$` signatures:
507    `$(rk/t)^k$`
508    
509    ?
510    
511    Bleichenbacher-Maurer
512  ---------------------  ---------------------
513    
514  Shorter signatures  ASIACRPTO construction
515    
516  - If less, cannot use information from hash directly, otherwise can attack  - Construction for `$H_n$`: a binary tree,
517    by giving close relatives    at each node 2 hashes combined into one
518    
519    - except! Algorithm for choosing `$x$` need not be public. If we hash  - private key: `$3(n+1)$` hash values of tree leaves.
520      a different private key plus the content hash or content of the information,    Calculate `$9n+2$` hashes. This can sign
521      we *can* use it here; random oracle    `$\\lfloor {\\log 51 \\over \\log 2} n \\rfloor$` bits.
522      (XXX Some were not allowable because not minimal???)
523    
524      - birthday paradox; if collision, someone can forge a signature  - public key: one hash, the one calculated for the root of the tree
       (relevant if a large number of chosen message attacks)  
525    
526    - can use random number; if we sign only 2**20 messages total,  - sign: message determines which nodes of the tree to reveal;
527      choosing randomly from 2**60 keys should be enough, since    Signature contains `$3(n+1)$` hashes.
528      we expect collisions only at about 2**30 messages signed  
529    - verify: check that right nodes revealed, and that tree computes right
530      public key - calculate some less than `$9n+2$` hashes
531    
532    Merkle hash trees
533    -----------------
534    
535    Assume an underlying one-time signature scheme `$S'$`.
536    Generate `$2^n$` public keys through `$S'$`,
537    compute a hash tree over them, publish the root
538    of the tree as the actual public key.
539    
540    Assume underlying algorithm using same hash.
541    
542    Signature using new public key will not need to contain
543    all the public keys, just path through the tree.
544    
545    - private key: `$2^n$` private keys of the underlying algorithm.
546    
547    - public key: Calculate the `$2^n$` public keys; hash each
548      public key (if it is longer than a single hash); compute
549      the hash tree. Calculating the public key takes
550      `$2^n c_0$` and calculating the hash tree takes
551      `$2^{n+1}-1$` hash function invocations.
552    
553    - sign using one key: Sign with that private key, provide the
554      corresponding public key, and provide the chain of hashes
555      from the hash tree's root to the public key.
556      Only hash invocations in the signing using the underlying algorithm.
557    
558    - verify: verify signature with new public key, verify hash chain.
559    
     - birthday paradox again: must not allow the attacker to have  
       2**30 messages being signed  
560    
 - however, collisions *only* invalidate one leaf of the key tree, so  
   it *is* possible to  
   revoke only that leaf, not the whole key.  
561    
562  Conclusion  Conclusion
563  ==========  ==========

Legend:
Removed from v.1.85  
changed lines
  Added in v.1.86

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