[tahoe-lafs-trac-stream] [tahoe-lafs] #1164: use XSalsa20+AES-128 encryption

[tahoe-lafs]

#1164: use XSalsa20+AES-128 encryption
-----------------------------+-----------------------------
     Reporter:  zooko        |      Owner:  somebody
         Type:  enhancement  |     Status:  new
     Priority:  major        |  Milestone:  soon
    Component:  code         |    Version:  1.8β
   Resolution:               |   Keywords:  confidentiality
Launchpad Bug:               |
-----------------------------+-----------------------------
Changes (by daira):

 * milestone:  1.11.0 => soon


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:
>
> http://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:
>
> http://tahoe-lafs.org/pipermail/tahoe-dev/2010-August/004878.html
> http://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.
>
> [http://tahoe-lafs.org/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]

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:

 http://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:

 http://tahoe-lafs.org/pipermail/tahoe-dev/2010-August/004878.html
 http://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.

 [http://tahoe-lafs.org/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]

--

Comment:

 We pushed many goals back a release when we decided to have release 1.10
 just based on features and bugfixes that were already on trunk. So it is
 now 1.11 that is going to focus primarily on bug fixes including share
 placement and repair behaviour. I suggest that XSalsa+AES support go into
 1.12, unless it is ready for 1.11 without slipping the schedule. Note that
 some design issues about cap format etc. have not been resolved yet.

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