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 |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
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 |