suggest AES-256 instead of AES-128 (changed my mind)

[Imported from Trac: page OneHundredYearCryptography, version 15]

OneHundredYearCryptography.md

@@ -11,7 +11,7 @@ Convert from AES/CTR to using AES/CTR combined (by XOR) with XSalsa20. This has
 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 in Tahoe-LAFS's case, the initial CTR IV will be secret and chosen via a cryptographic KDF.
 
 Open questions:
-  * 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! *
+  * 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> *
   * What KDF is used to generate the keys/IVs? *Zooko says: per [this mailing list thread](http://tahoe-lafs.org/pipermail/tahoe-dev/2010-June/004424.html) HKDF might be a good choice for KDF.*
   * Samuel Neves had an alternate proposal for encryption to use the same or similar mechanisms as we use for hashing: [Samuel Neves proposal](http://tahoe-lafs.org/pipermail/tahoe-dev/2010-June/004487.html). *Zooko says: Samuel Neves's hash-based encryption proposal could be used in addition to AES and XSalsa20, or in place of XSalsa20.*