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