From d84f3d8c925132b7d4ee61716e5cb31978219d55 Mon Sep 17 00:00:00 2001 From: zooko <> Date: Wed, 9 Oct 2013 12:08:59 +0000 Subject: [PATCH] fix links, edit a little [Imported from Trac: page OneHundredYearCryptography, version 25] --- OneHundredYearCryptography.md | 21 +++++++++------------ 1 file changed, 9 insertions(+), 12 deletions(-) diff --git a/OneHundredYearCryptography.md b/OneHundredYearCryptography.md index faf1a0d..ee0f2a8 100644 --- a/OneHundredYearCryptography.md +++ b/OneHundredYearCryptography.md @@ -11,27 +11,24 @@ 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: 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: * Here are measurements of performance: - * 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.* + * 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: * Here are measurements of performance: [//trac/pycryptopp/ticket/46#comment:13 pycryptopp ticket #46, comment 13] + * 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.// + * 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.// ## Hashing -We'll combine two hash functions using an appropriate combiner depending on the hash function properties that are required, see [Zooko's notes](http://tahoe-lafs.org/pipermail/tahoe-dev/2010-June/004575.html) 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. +We'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. ## Signatures -David-Sarah has proposed to use hash-based digital signatures. +Daira has proposed to use hash-based digital signatures. * [Bibliography#Hash-BasedDigitalSignatures](Bibliography#Hash-BasedDigitalSignatures) - * - * - * - * - * -Zooko posted ["back of the envelope" performance constraints](https://tahoe-lafs.org/pipermail/tahoe-dev/2011-February/006133.html). Bottom-line: you get 30 million ARM instructions to implement one complete digital signature verification. +Discussion 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]. -Julian Wälde has [posted an actual implementation](http://tahoe-lafs.org/pipermail/tahoe-dev/2011-March/006237.html) 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]! +Zooko 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. + +Julian 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]! Brian and David-Sarah wrote [a simulator]source:trunk/misc/simulators/hashbasedsig.py 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): ```