340 |
Conclusion |
Conclusion |
341 |
========== |
========== |
342 |
|
|
343 |
- presented a new signature scheme with several benefits |
We have presented a new signature scheme with several benefits |
344 |
as far as we know not found together so far |
which, as far as we know, have not been embodied in the same |
345 |
|
algorithm so far. |
346 |
|
Our scheme uses |
347 |
|
no trapdoor funcs, so its security does not rely on |
348 |
|
hardness of factoring or some other such problem. |
349 |
|
There is |
350 |
|
no need for expiration of key or signature - keys don't |
351 |
|
degrade with use and cracking a signature seems to require |
352 |
|
a full search through the key space; |
353 |
|
there is also |
354 |
|
no state beyond the private key: there is no need to keep track |
355 |
|
of signed documents. |
356 |
|
The scheme is existentially |
357 |
|
unforgeable with an adaptive chosen message attack since a different |
358 |
|
private key produced by the random oracle |
359 |
|
is used to sign each message. |
360 |
|
|
361 |
|
We see the most significant application of our scheme |
362 |
|
in long-term digital publishing, |
363 |
|
where the time limits and key management requirements |
364 |
|
of normal digital signatures |
365 |
|
are inconvenient. |
366 |
|
|
367 |
|
The downsides of the present scheme are that |
368 |
|
signatures are relatively large and signing |
369 |
|
and verifying require considerably more time |
370 |
|
than with other schemes. However, with modern |
371 |
|
computers storage space is cheap and the estimated |
372 |
|
signature times are not prohibitive. Additionally, |
373 |
|
considerable algorithmic improvements may be possible. |
374 |
|
|
375 |
|
Naturally, this scheme is not foolproof. Weaknesses in cryptographic |
376 |
|
hash functions may be found. Also, while |
377 |
|
all digital |
378 |
|
signatures in practice do depend on a hash function for |
379 |
|
long messages, our demands for are stricter: the hash |
380 |
|
function must also be a random oracle. |
381 |
|
|
382 |
|
The key idea of the scheme is to use |
383 |
|
a deterministic random oracle |
384 |
|
to define a huge virtual tree of private keys, |
385 |
|
of which one path is traversed to find the private key to |
386 |
|
use to sign a particular document. |
387 |
|
|
388 |
|
We believe that as long as the random oracle, |
389 |
|
used to generate the new private keys |
390 |
|
and to implement the one-time signatures, |
391 |
|
isn't broken, an exhaustive |
392 |
|
key search is the only way to break the scheme. |
393 |
|
At the very least, this scheme is |
394 |
|
not worse than RSA, where giving more signatures increases |
395 |
|
the possibility of factoring. |
396 |
|
|
397 |
- no trapdoor funcs |
.. However, a full security analysis |
|
|
|
|
- This scheme is existentially |
|
|
unforgeable with an adaptive chosen message attack. |
|
|
|
|
|
- no state beyond the private key: no need to keep track |
|
|
of signed documents &c. |
|
|
|
|
|
- no need for expiration of key or signature |
|
|
|
|
|
- application in long-term digital publishing, |
|
|
the time limits on normal digital signatures |
|
|
are inconvenient |
|
|
|
|
|
- downsides |
|
|
|
|
|
- signatures relatively large and signing and |
|
|
verifying relatively slow |
|
|
|
|
|
- considerable improvements |
|
|
may be possible |
|
|
|
|
|
- naturally not foolproof: e.g. hashes *do* get broken, REF |
|
|
|
|
|
- signatures in practice do depend on a hash function for |
|
|
long messages. however, it only needs to be collision-resistant, |
|
|
not a random oracle |
|
|
|
|
|
- key idea: using the deterministic random oracle |
|
|
to create a huge virtual tree of private keys, |
|
|
|
|
|
- in one instance `$2^{160}$`, enough to have a separate private |
|
|
key for each value to be signed. |
|
|
|
|
|
- also probabilistic, faster versions, which can be made |
|
|
to work if only a predetermined number of documents is ever signed |
|
|
with a key. |
|
|
|
|
|
- we believe that as long as the random oracle, |
|
|
used to generate the new private keys |
|
|
and to implement the one-time signatures, |
|
|
isn't broken, an exhaustive |
|
|
key search is the only way to break the scheme. |
|
|
|
|
|
- (however, we don't give full security analysis) |
|
|
|
|
|
- not worse than RSA, where giving more signatures increases |
|
|
the possibility of factoring |
|
398 |
|
|
399 |
Acknowledgments |
Acknowledgments |
400 |
=============== |
=============== |
401 |
|
|
402 |
|
|