[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 zooko:

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:src/allmydata/dirnode.py at 4539#L174]
>  * [source:src/allmydata/dirnode.py at 4539#L293]
>  * [source:src/allmydata/immutable/filenode.py at 4661#L166]
>  * [source:src/allmydata/immutable/upload.py at 4655#L619]
>  * [source:src/allmydata/immutable/upload.py at 4655#L728]
>  * [source:src/allmydata/mutable/filenode.py at 4329#L131]
>  * [source:src/allmydata/mutable/filenode.py at 4329#L136]
>  * [source:src/allmydata/mutable/publish.py at 4329#L400]
>  * [source:src/allmydata/mutable/retrieve.py at 4329#L518]
>  * [source:src/allmydata/util/fileutil.py at 4609#L118]
>
> This is inspired by [wiki:OneHundredYearCryptography The One-Hundred-Year
> Cryptography Project].

New description:

 meaningless change to trigger the mysterious "everything has changed"
 diff, that happens the first time you change an old ticket.

 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:src/allmydata/dirnode.py at 4539#L174]
  * [source:src/allmydata/dirnode.py at 4539#L293]
  * [source:src/allmydata/immutable/filenode.py at 4661#L166]
  * [source:src/allmydata/immutable/upload.py at 4655#L619]
  * [source:src/allmydata/immutable/upload.py at 4655#L728]
  * [source:src/allmydata/mutable/filenode.py at 4329#L131]
  * [source:src/allmydata/mutable/filenode.py at 4329#L136]
  * [source:src/allmydata/mutable/publish.py at 4329#L400]
  * [source:src/allmydata/mutable/retrieve.py at 4329#L518]
  * [source:src/allmydata/util/fileutil.py at 4609#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:19>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage