278 |
\end{table*} |
\end{table*} |
279 |
|
|
280 |
For example, using the Merkle signature scheme [XXX], |
For example, using the Merkle signature scheme [XXX], |
281 |
|
with X long sigs and X ... |
282 |
|
|
283 |
|
|
284 |
with `$N=32$` and `$n=5$` and a 160-bit hash, |
with `$N=32$` and `$n=5$` and a 160-bit hash, |
285 |
we obtain a signature scheme |
we obtain a signature scheme |
286 |
with 110.0KB signatures and `$2.1\cdot 10^{5}$` |
with 110.0KB signatures and uses |
287 |
|
`$2.1\cdot 10^{5}$` |
288 |
hash invocations for signing and `$5.6\cdot 10^3$` |
hash invocations for signing and `$5.6\cdot 10^3$` |
289 |
hash invocations for verification. |
hash invocations for verification. |
290 |
Using SHA-1, we obtained the estimated times 1s and 30ms |
Using SHA-1, we obtained the estimated times 1s and 30ms |
308 |
In practice, it may be useful to relax the security |
In practice, it may be useful to relax the security |
309 |
requirements somewhat to obtain more practical schemes. |
requirements somewhat to obtain more practical schemes. |
310 |
|
|
311 |
- For smaller sigs and faster verification, |
For smaller signatures and faster verification, |
312 |
key_boosting_real(8, 7, 160):: |
we can set `$N=8$` and `$n=7$` to obtain a scheme |
313 |
|
with `$2^{56}$` distinct private keys for signing documents, |
314 |
|
which produces |
315 |
|
28KB signatures, and uses |
316 |
|
`$1.9\cdot 10^{5}$` |
317 |
|
hash invocations for signing and `$1.4\cdot 10^3$` |
318 |
|
hash invocations for verification. |
319 |
|
|
320 |
|
|
321 |
|
|
322 |
|
.. key_boosting_real(8, 7, 160) |
323 |
|
|
324 |
(q=2^56.0, b=160, s=27.8125 KB, |
(q=2^56.0, b=160, s=27.8125 KB, |
325 |
r=20 B, h=20 B, |
r=20 B, h=20 B, |
326 |
t0=2.31e+04 [~115.315ms], |
t0=2.31e+04 [~115.315ms], |
327 |
ts=1.85e+05 [~922.52ms], |
ts=1.85e+05 [~922.52ms], |
328 |
tv=1.41e+03 [~7.04ms]) |
tv=1.41e+03 [~7.04ms]) |
329 |
|
|
330 |
|
If faster signing is desirable, |
331 |
|
we can set `$N=12$` and `$n=5$` to obtain a scheme |
332 |
|
with `$2^{60}$` distinct private keys. |
333 |
|
This scheme produces |
334 |
|
41KB signatures, and uses |
335 |
|
`$7.6\cdot 10^{4}$` |
336 |
|
hash invocations for signing and `$2.1\cdot 10^3$` |
337 |
|
hash invocations for verification. |
338 |
|
|
339 |
- For faster signing, |
.. For faster signing, |
340 |
key_boosting_real(12, 5, 160):: |
key_boosting_real(12, 5, 160) |
341 |
|
|
342 |
(q=2^60.0, b=160, s=41.25 KB, |
(q=2^60.0, b=160, s=41.25 KB, |
343 |
r=20 B, h=20 B, |
r=20 B, h=20 B, |
344 |
t0=6.31e+03 [~31.555ms], |
t0=6.31e+03 [~31.555ms], |
345 |
ts=7.57e+04 [~378.66ms], |
ts=7.57e+04 [~378.66ms], |
346 |
tv=2.09e+03 [~10.44ms]) |
tv=2.09e+03 [~10.44ms]) |
347 |
|
|
348 |
These may be used freely, bounded only by the birthday |
If the first message hash bits are directly used |
349 |
paradox collision probability within the number of keys |
as the bits for the choise of `$x$`, the |
350 |
|
algorithm becomes |
351 |
|
vulnerable to adaptive chosen-message plaintext. |
352 |
|
An easy way around this is to use the private key as salt |
353 |
|
for the selection of `$x$`. |
354 |
|
|
355 |
|
With this caveat, these smaller schemes |
356 |
|
are only bounded by the birthday |
357 |
|
paradox collision probability within the number of distinct |
358 |
|
private keys |
359 |
defined in the virtual tree. |
defined in the virtual tree. |
360 |
|
|
361 |
It is also possible to use key boosting to form `$k$`-time |
It is also possible to use key boosting to form `$k$`-time |