2 |
One-time Signature Key Boosting: Full Digital Signature Feature Set without Trapdoor Functions |
One-time Signature Key Boosting: Full Digital Signature Feature Set without Trapdoor Functions |
3 |
============================================================================================== |
============================================================================================== |
4 |
|
|
|
.. Benja: I'm restarting the writing. |
|
|
|
|
|
We *don't* need to review all existing schemes, since I figured |
|
|
our combination with merkle hashes still is a *linear* operation |
|
|
from source to target characteristics. We'll get off much lighter |
|
|
without reviewing, no need to search too much for optimums &c. |
|
|
|
|
|
I'm sure the referees will tell us if we should review them... |
|
|
|
|
5 |
Abstract: |
Abstract: |
6 |
|
|
7 |
- recursive application of one-time signature to sign |
- recursive application of one-time signature to sign |
8 |
nodes along a single branch of a tree of |
nodes along a single path through a virtual tree of |
9 |
new pubkeys corresponding to privkeys |
new pubkeys corresponding to privkeys |
10 |
deterministically |
deterministically |
11 |
generated by random oracle from the tree node |
generated by random oracle from the tree node |
16 |
|
|
17 |
- good |
- good |
18 |
|
|
19 |
- existentially unforgeable in adaptive chosen message attack, |
- existentially unforgeable in adaptive chosen message attack |
|
even if underlying one-time-signature algorithm isn't |
|
20 |
|
|
21 |
- We believe that as long as the random oracle, |
- We believe that as long as the random oracle, |
22 |
used to generate the new private keys |
used to generate the new private keys |
305 |
Conclusion |
Conclusion |
306 |
========== |
========== |
307 |
|
|
308 |
- key idea: using the deterministic bit string for each privkey |
- presented a new signature scheme with several benefits |
309 |
|
|
310 |
|
- no trapdoor funcs |
311 |
|
|
312 |
|
- This scheme is existentially |
313 |
|
unforgeable with an adaptive chosen message attack. |
314 |
|
|
315 |
|
- no state beyond the private key: no need to keep track |
316 |
|
of signed documents &c. |
317 |
|
|
318 |
|
- no need for expiration of key or signature |
319 |
|
|
320 |
|
- application in long-term digital publishing, |
321 |
|
the time limits on normal digital signatures |
322 |
|
are inconvenient |
323 |
|
|
324 |
|
- downsides |
325 |
|
|
326 |
|
- signatures relatively large and signing and |
327 |
|
verifying relatively slow |
328 |
|
|
329 |
|
- considerable improvements |
330 |
|
probably possible |
331 |
|
|
332 |
|
- naturally not foolproof: e.g. hashes *do* get broken, REF |
333 |
|
|
334 |
|
- key idea: using the deterministic random oracle |
335 |
|
to create a huge virtual tree of private keys, |
336 |
|
|
337 |
|
- in one instance `$2^{160}$`, enough to have a separate private |
338 |
|
key for each value to be signed. |
339 |
|
|
340 |
|
- also probabilistic, faster versions, which can be made |
341 |
|
to work if only a predetermined number of documents is ever signed |
342 |
|
with a key. |
343 |
|
|
344 |
|
|
345 |
|
|
|
In long-term digital publishing, the time limits on normal digital signatures |
|
|
are |
|
346 |
|
|
|
- we expect our methods to be improved on considerably; we have shown it is *feasible*, |
|
|
now someone needs to show it's *practical* |
|
347 |
|
|
|
- hashes *do* get broken, REF |
|
348 |
|
|