Changes between Version 16 and Version 17 of OneHundredYearCryptography
- Timestamp:
- 2011-12-21T22:25:13Z (13 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
OneHundredYearCryptography
v16 v17 32 32 Zooko posted [https://tahoe-lafs.org/pipermail/tahoe-dev/2011-February/006133.html "back of the envelope" performance constraints]. Bottom-line: you get 30 million ARM instructions to implement one complete digital signature verification. 33 33 34 Julian Wälde has [http://tahoe-lafs.org/pipermail/tahoe-dev/2011-March/006237.html posted an actual implementation] of hash-based digital signatures! Exciting fact: his implementation meets Zooko's performance criterion!34 Julian Wälde has [http://tahoe-lafs.org/pipermail/tahoe-dev/2011-March/006237.html posted an actual implementation] of (stateful) hash-based digital signatures! Exciting fact: his implementation meets Zooko's performance criterion! 35 35 36 Brian and David-Sarah wrote [source:trunk/misc/simulators/hashbasedsig.py a simulator] or two to explore performance trade-offs in hash-based signature parameters. The output of one run with the following parameters is this:36 Brian and David-Sarah wrote [source:trunk/misc/simulators/hashbasedsig.py a simulator] or two to explore performance trade-offs in (stateless) hash-based signature parameters. The output of one run with the following parameters is this (note that the signing times include regeneration of per-message signing keys from a small long-term private key): 37 37 {{{ 38 38 # range of hash output lengths … … 41 41 lg_M = 53 # lg(required number of signatures before losing security) 42 42 43 limit_bytes = 20000 # limit on signature length43 limit_bytes = 20000 # limit on signature length 44 44 limit_cost = 500 # limit on Mcycles_Sig + weight_ver*Mcycles_ver 45 45 weight_ver = 1 # how important verification cost is relative to signature cost