[tahoe-lafs-trac-stream] [Tahoe-LAFS] #1164: use ChaCha⊕AES encryption

[Tahoe-LAFS]

#1164: use ChaCha⊕AES encryption
-----------------------------+-----------------------------
     Reporter:  zooko        |      Owner:  somebody
         Type:  enhancement  |     Status:  new
     Priority:  major        |  Milestone:  1.12.0
    Component:  code         |    Version:  1.8β
   Resolution:               |   Keywords:  confidentiality
Launchpad Bug:               |
-----------------------------+-----------------------------
Description changed by daira:

Old description:

> In order to protect against weaknesses in AES (such as timing or side-
> channel attacks, or cryptanalysis, possibly far in the future and applied
> against old ciphertexts), want to use a combined encryption of AES-128
> and XSalsa20. Yu Xue (Student) and Jack Lloyd (Mentor) are working on
> implementing that mode for GSoC 2010:
>
> [//trac/pycryptopp/ticket/46 https://tahoe-
> lafs.org/trac/pycryptopp/ticket/46]
>
> This ticket is to integrate that encryption mode into Tahoe-LAFS. The
> steps are to define new capability versions, such as by inserting an
> {{{X}}} into the cap type designator:
>
> [//pipermail/tahoe-dev/2010-August/004878.html https://tahoe-
> lafs.org/pipermail/tahoe-dev/2010-August/004878.html]
> [//pipermail/tahoe-dev/2010-August/004879.html https://tahoe-
> lafs.org/pipermail/tahoe-dev/2010-August/004879.html]
>
> And to make it so that caps of that new type get encrypted/decrypted with
> XSalsa20+AES-128 instead of with AES-256. For the first release of Tahoe-
> LAFS which includes that functionality, it will still by default create
> new caps using the old encryption of only AES-256. It is important that
> people feel free to upgrade to new versions of Tahoe-LAFS without having
> to take any steps to ensure backward-compatibility, and that means that
> the new version of Tahoe-LAFS ''must not'', by default, produce caps that
> older versions of Tahoe-LAFS (such as v1.8.0) can't read.
>
> [//pipermail/tahoe-dev/2010-August/004936.html This tahoe-dev letter]
> lists all the places where the current source code (which is Tahoe-LAFS
> v1.8.0c1) uses encryption:
>  *
> [source:trunk/src/allmydata/dirnode.py?annotate=blame&rev=35f37cc5b86465407a0eb85a7760f8442f5a969f#L175]
>  *
> [source:trunk/src/allmydata/dirnode.py?annotate=blame&rev=35f37cc5b86465407a0eb85a7760f8442f5a969f#L294]
>  *
> [source:trunk/src/allmydata/immutable/filenode.py?annotate=blame&rev=0ef593947755a8b81edc73d033219724268faf80#L185]
>  *
> [source:trunk/src/allmydata/immutable/upload.py?annotate=blame&rev=196bd583b6c4959c60d3f73cdcefc9edda6a38ae#L620]
>  *
> [source:trunk/src/allmydata/immutable/upload.py?annotate=blame&rev=196bd583b6c4959c60d3f73cdcefc9edda6a38ae#L756]
>  *
> [source:trunk/src/allmydata/mutable/filenode.py?annotate=blame&rev=4563ba456b1b2d640551956374b0cfbfc602dcec#L161]
>  *
> [source:trunk/src/allmydata/mutable/filenode.py?annotate=blame&rev=4563ba456b1b2d640551956374b0cfbfc602dcec#L166]
>  *
> [source:trunk/src/allmydata/mutable/publish.py?annotate=blame&rev=45adde71808bc27d41b5bc77a963184957e9b247#L693]
>  *
> [source:trunk/src/allmydata/mutable/retrieve.py?annotate=blame&rev=7956e22d2149b0fb7f3014d6f43d01fb520c1b81#L621]
>  *
> [source:trunk/src/allmydata/util/fileutil.py?annotate=blame&rev=c85060c436834b58cf7f1876811762d53c81ff90#L118]
>
> This is inspired by [wiki:OneHundredYearCryptography The One-Hundred-Year
> Cryptography Project].

New description:

 In order to protect against weaknesses in AES (such as timing or side-
 channel attacks, or cryptanalysis, possibly far in the future and applied
 against old ciphertexts), want to use a combined encryption of AES-128 and
 XSalsa20. Yu Xue (Student) and Jack Lloyd (Mentor) are working on
 implementing that mode for GSoC 2010:

 [//trac/pycryptopp/ticket/46 https://tahoe-
 lafs.org/trac/pycryptopp/ticket/46]

 This ticket is to integrate that encryption mode into Tahoe-LAFS. The
 steps are to define new capability versions, such as by inserting an
 {{{X}}} into the cap type designator:

 [//pipermail/tahoe-dev/2010-August/004878.html https://tahoe-
 lafs.org/pipermail/tahoe-dev/2010-August/004878.html]
 [//pipermail/tahoe-dev/2010-August/004879.html https://tahoe-
 lafs.org/pipermail/tahoe-dev/2010-August/004879.html]

 And to make it so that caps of that new type get encrypted/decrypted with
 XSalsa20+AES-128 instead of with AES-256. For the first release of Tahoe-
 LAFS which includes that functionality, it will still by default create
 new caps using the old encryption of only AES-256. It is important that
 people feel free to upgrade to new versions of Tahoe-LAFS without having
 to take any steps to ensure backward-compatibility, and that means that
 the new version of Tahoe-LAFS ''must not'', by default, produce caps that
 older versions of Tahoe-LAFS (such as v1.8.0) can't read.

 [//pipermail/tahoe-dev/2010-August/004936.html This tahoe-dev letter]
 listed all the places where the source code used encryption. Here are
 those links updated to current master:
  * [source:src/allmydata/dirnode.py at 35f37cc5#L175]
  * [source:src/allmydata/dirnode.py at 35f37cc5#L294]
  * [source:src/allmydata/immutable/filenode.py at 0ef59394#L185]
  * [source:src/allmydata/immutable/upload.py at 196bd583#L620]
  * [source:src/allmydata/immutable/upload.py at 196bd583#L738]
  * [source:src/allmydata/mutable/filenode.py at 4563ba45#L161]
  * [source:src/allmydata/mutable/filenode.py at 4563ba45#L166]
  * [source:src/allmydata/mutable/publish.py at 45adde71#L693]
  * [source:src/allmydata/mutable/retrieve.py at 7956e22d#L883]
  * [source:src/allmydata/util/fileutil.py at c85060c4#L118]

 This is inspired by [wiki:OneHundredYearCryptography The One-Hundred-Year
 Cryptography Project].

--

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1164#comment:24>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage