#1164 new enhancement

use ChaCha⊕AES encryption

Reported by: zooko Owned by: somebody
Priority: major Milestone: soon
Component: code Version: 1.8β
Keywords: confidentiality Cc: dragonxue, jack.lloyd, randombit
Launchpad Bug:

Description (last modified by daira)

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:


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:

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

This tahoe-dev letter listed all the places where the source code as of Tahoe-LAFS v1.8.0c1 used encryption. Here are those links updated to current master:

This is inspired by The One-Hundred-Year Cryptography Project.

Change History (30)

comment:1 Changed at 2010-08-09T22:16:28Z by zooko

  • Milestone changed from undecided to 1.9.0

comment:2 Changed at 2010-09-03T18:13:20Z by zooko

Upon Samuel Neves's questioning, I added some notes about AES-128 vs. AES-256 for this:


I would be interested in the feedback of Jack, Yu Xue, David-Sarah, or Brian about this issue.

comment:3 Changed at 2010-09-29T05:07:19Z by zooko

  • Keywords confidentiality added
  • Type changed from defect to enhancement

comment:4 Changed at 2011-04-24T04:05:49Z by zooko

  • Cc changed from dragonxue,jack.lloyd,randombit to dragonxue, jack.lloyd, randombit
  • Milestone changed from 1.9.0 to soon

comment:5 Changed at 2011-04-24T04:07:01Z by zooko

  • Milestone changed from soon to 1.10.0

comment:6 Changed at 2011-09-03T18:50:43Z by zooko

Yu Xue contributed a patch to pycryptopp to make it support XSalsa20 and XSalsa20⊕AES-128: http://tahoe-lafs.org/trac/pycryptopp/ticket/46

comment:7 Changed at 2012-03-29T21:10:01Z by davidsarah

It's not clear to me that this should go into 1.10, which is going to focus primarily on bug fixes (especially robustifying mutable files and repair behaviour) and accounting. However, I may be persuadable.

comment:8 Changed at 2012-03-29T21:31:12Z by davidsarah

Hmm, I see this is explicitly listed as one of the goals for the 1.10 milestone. So, I'll leave it in.

comment:9 follow-up: Changed at 2012-09-13T14:08:19Z by zooko

I currently intend to get this landed in trunk for Tahoe-LAFS v1.11.

comment:10 in reply to: ↑ 9 Changed at 2012-10-11T20:09:42Z by davidsarah

Replying to zooko:

I currently intend to get this landed in trunk for Tahoe-LAFS v1.11.


comment:11 follow-up: Changed at 2013-07-18T19:14:00Z by daira

  • Description modified (diff)
  • Milestone changed from 1.11.0 to soon

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

Last edited at 2013-07-18T19:14:37Z by daira (previous) (diff)

comment:12 in reply to: ↑ 11 Changed at 2013-07-18T19:43:18Z by zooko

Replying to daira:

I suggest that XSalsa+AES support go into 1.12, unless it is ready for 1.11 without slipping the schedule.


comment:13 Changed at 2013-07-22T20:42:02Z by daira

  • Milestone changed from soon to 1.12.0

comment:14 Changed at 2013-09-11T03:59:56Z by zooko

  • Description modified (diff)

comment:15 Changed at 2013-09-11T04:00:44Z by zooko

  • Description modified (diff)

comment:16 Changed at 2013-09-30T05:21:24Z by zooko

Because of the fact that ChaCha looks like it might become a standard cipher in TLS soon (http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-01), then this makes me think we should use ChaCha instead of XSalsa20 for this.

comment:17 Changed at 2013-09-30T14:15:08Z by zooko

I opened pycryptopp ticket #94 to track adding ChaCha into pycryptopp.

comment:18 Changed at 2013-10-11T11:32:38Z by zooko

  • Summary changed from use XSalsa20+AES-128 encryption to use ChaCha⊕AES encryption

comment:19 Changed at 2014-12-30T21:12:20Z by zooko

  • Description modified (diff)

comment:20 Changed at 2014-12-30T21:12:52Z by zooko

  • Description modified (diff)

comment:21 Changed at 2014-12-30T21:14:58Z by zooko

  • Description modified (diff)

comment:22 Changed at 2014-12-30T21:15:19Z by zooko

  • Description modified (diff)

comment:23 Changed at 2014-12-30T21:53:51Z by zooko

  • Description modified (diff)

comment:24 Changed at 2014-12-30T22:02:46Z by daira

  • Description modified (diff)

comment:25 Changed at 2014-12-30T22:04:48Z by daira

  • Description modified (diff)

comment:26 Changed at 2016-03-22T05:02:25Z by warner

  • Milestone changed from 1.12.0 to 1.13.0

Milestone renamed

comment:27 Changed at 2016-06-28T18:17:14Z by warner

  • Milestone changed from 1.13.0 to 1.14.0

renaming milestone

comment:28 Changed at 2016-08-04T14:52:59Z by daira

As part of the programme of reducing our cryptography library dependencies (and getting out of the business of writing C/Python wrappers ourselves), I think we should move away from pycryptopp and use 'cryptography' (which Tahoe-LAFS already depends on via pyOpenSSL >= 0.14) where possible. It doesn't look like cryptography supports ChaCha20 unfortunately; we could either fix that, or use pysodium for that instead.

comment:29 Changed at 2020-06-30T14:45:13Z by exarkun

  • Milestone changed from 1.14.0 to 1.15.0

Moving open issues out of closed milestones.

comment:30 Changed at 2021-03-30T18:40:19Z by meejah

  • Milestone changed from 1.15.0 to soon

Ticket retargeted after milestone closed

Note: See TracTickets for help on using tickets.