Changes between Version 24 and Version 25 of OneHundredYearCryptography


Ignore:
Timestamp:
2013-10-09T12:08:59Z (11 years ago)
Author:
zooko
Comment:

fix links, edit a little

Legend:

Unmodified
Added
Removed
Modified

  • OneHundredYearCryptography

    v24 v25  
    1212
    1313Open questions:
    14   * Should we use AES-128, AES-192, or AES-256? //Zooko says: I guess it is worth the added CPU cycles to use AES-256. The added CPU cycles on ARM, according to bench.cr.yp.to, is about 40 cycles per byte for AES-256 compared to about 28 cycles per byte for AES-128. See recent attacks on AES-128: http://eprint.iacr.org/2011/449 // Here are measurements of performance: https://tahoe-lafs.org/trac/pycryptopp/ticket/46#comment:13
    15   * What KDF is used to generate the keys/IVs? //Zooko says: per [http://tahoe-lafs.org/pipermail/tahoe-dev/2010-June/004424.html this mailing list thread] HKDF might be a good choice for KDF.//
    16   * Samuel Neves had an alternate proposal for encryption to use the same or similar mechanisms as we use for hashing: [http://tahoe-lafs.org/pipermail/tahoe-dev/2010-June/004487.html Samuel Neves proposal]. //Zooko says: Samuel Neves's hash-based encryption proposal could be used in addition to AES and XSalsa20, or in place of XSalsa20.//
     14  * Should we use AES-128, AES-192, or AES-256? //Zooko says: I guess it is worth the added CPU cycles to use AES-256. The added CPU cycles on ARM, according to bench.cr.yp.to, is about 40 cycles per byte for AES-256 compared to about 28 cycles per byte for AES-128. See recent attacks on AES-128: http://eprint.iacr.org/2011/449 // Here are measurements of performance: [//trac/pycryptopp/ticket/46#comment:13 pycryptopp ticket #46, comment 13]
     15  * What KDF is used to generate the keys/IVs? //Zooko says: per [//pipermail/tahoe-dev/2010-June/004424.html this mailing list thread] HKDF might be a good choice for KDF.//
     16  * Samuel Neves had an alternate proposal for encryption to use the same or similar mechanisms as we use for hashing: [//pipermail/tahoe-dev/2010-June/004487.html Samuel Neves proposal]. //Zooko says: Samuel Neves's hash-based encryption proposal could be used in addition to AES and XSalsa20, or in place of XSalsa20.//
    1717
    1818== Hashing ==
    1919
    20 We'll combine two hash functions using an appropriate combiner depending on the hash function properties that are required, see [http://tahoe-lafs.org/pipermail/tahoe-dev/2010-June/004575.html Zooko's notes] about hash function combiners. The Comb4P hash function combiner preserves most (but not all) security properties of the hashes, though because the extra work comes in the form of a set of final Feistel rounds, this may negatively effect performance when combined with the tree hashing mode Tahoe-LAFS uses.
     20We'll combine two hash functions using an appropriate combiner depending on the hash function properties that are required, see [//pipermail/tahoe-dev/2010-June/004575.html Zooko's notes] about hash function combiners. The Comb4P hash function combiner preserves most (but not all) security properties of the hashes, though because the extra work comes in the form of a set of final Feistel rounds, this may negatively effect performance when combined with the tree hashing mode Tahoe-LAFS uses.
    2121
    2222== Signatures ==
    2323
    24 David-Sarah has proposed to use hash-based digital signatures.
     24Daira has proposed to use hash-based digital signatures.
    2525 * [wiki:Bibliography#Hash-BasedDigitalSignatures]
    26  * http://tahoe-lafs.org/pipermail/tahoe-dev/2010-June/004439.html
    27  * http://tahoe-lafs.org/pipermail/tahoe-dev/2010-June/004496.html
    28  * http://tahoe-lafs.org/pipermail/tahoe-dev/2010-June/004497.html
    29  * http://tahoe-lafs.org/pipermail/tahoe-dev/2010-June/004509.html
    30  * http://tahoe-lafs.org/pipermail/tahoe-dev/2010-July/004587.html
    3126
    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.
     27Discussion on the tahoe-dev list with Zooko, Brian Warner, Jack Lloyd, and Daira (then David-Sarah): [//pipermail/tahoe-dev/2010-June/004439.html 1], [//pipermail/tahoe-dev/2010-June/004496.html 2], [//pipermail/tahoe-dev/2010-June/004497.html 3], [//pipermail/tahoe-dev/2010-June/004509.html 4], [//pipermail/tahoe-dev/2010-July/004587.html 5].
    3328
    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 [//pipermail/tahoe-dev/2011-July/006554.html meets] Zooko's [//pipermail/tahoe-dev/2011-February/006133.html performance criteria]!
     29Zooko posted [//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.
     30
     31Julian Wälde has [//pipermail/tahoe-dev/2011-March/006237.html posted an actual implementation] of hash-based digital signatures! Exciting fact: his implementation [//pipermail/tahoe-dev/2011-July/006554.html meets] Zooko's [//pipermail/tahoe-dev/2011-February/006133.html performance criteria]!
    3532
    3633Brian 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):