Changes between Version 12 and Version 13 of OneHundredYearCryptography


Ignore:
Timestamp:
2011-08-04T21:42:03Z (13 years ago)
Author:
zooko
Comment:

some edits

Legend:

Unmodified
Added
Removed
Modified

  • OneHundredYearCryptography

    v12 v13  
    33This describes a project to enhance Tahoe-LAFS's cryptographic system so that Tahoe shipped today/next year might remain safe from cryptographic attacks for a 100 years. The initial ideas were presented on a [http://pubgrid.tahoe-lafs.org/uri/URI:DIR2-RO:ixqhc4kdbjxc7o65xjnveoewym:5x6lwoxghrd5rxhwunzavft2qygfkt27oj3fbxlq4c6p45z5uneq/blog.html#%5B%5Bcan%20we%20build%20a%20crypto%20system%20to%20last%20for%20a%20hundred%20years%3F%5D%5D post by Zooko on his klog].
    44
    5 The basic idea is to combine two primitives, both thought to be safe, such that even if one of them fails catastrophically Tahoe-LAFS remains secure.
     5One idea is to combine two primitives, both thought to be safe, such that even if one of them fails catastrophically Tahoe-LAFS remains secure.
    66
    77== Bulk Encryption ==
    … …  
    99Convert from AES/CTR to using AES/CTR combined (by XOR) with XSalsa20. This has the advantage of being fully parallel, since you can compute both the AES and XSalsa20 keystreams in parallel and before the plaintext or ciphertext is known.
    1010
    11 It's worth noting that AES is being retained more for political/name brand reasons than actual security. If this wasn't a factor we might well be better of instead using a design that is safe against timing attacks, such as Serpent or Noekeon. On the other hand, CTR mode probably makes timing attacks rather more difficult because the attacker can't choose inputs. And, I believe, in Tahoe-LAFS's case, the initial CTR IV will be secret and chosen via a cryptographic KDF.
     11It's worth noting that AES is being retained more for political/name brand reasons than actual security. If this wasn't a factor we might well be better of instead using a design that is safe against timing attacks, such as Serpent or Noekeon. On the other hand, CTR mode probably makes timing attacks rather more difficult because the attacker can't choose inputs. And in Tahoe-LAFS's case, the initial CTR IV will be secret and chosen via a cryptographic KDF.
    1212
    1313Open questions:
    1414  * Should we use AES-128, AES-192, or AES-256? //Zooko says: maybe AES-128 because it wastes fewer CPU cycles and is plenty secure. Indeed, if you worry too much about the related key model (which I don't since we never use related keys in Tahoe-LAFS) then AES-128 is arguably safer than AES-256! //
    15   * What KDF is used to generate the keys/IVs? I think Zooko suggested using XSalsa20, but I haven't seen a concrete proposal. //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].
     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.//
    1717
    1818== Hashing ==