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

> 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].

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]
 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:20>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage