use ChaCha⊕AES encryption

[zooko]

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:

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:

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:

• src/allmydata/dirnode.py@35f37cc5#L175​
• src/allmydata/dirnode.py@35f37cc5#L294​
• src/allmydata/immutable/filenode.py@0ef59394#L185​
• src/allmydata/immutable/upload.py@196bd583#L620​
• src/allmydata/immutable/upload.py@196bd583#L738​
• src/allmydata/mutable/filenode.py@4563ba45#L161​
• src/allmydata/mutable/filenode.py@4563ba45#L166​
• src/allmydata/mutable/publish.py@45adde71#L693​
• src/allmydata/mutable/retrieve.py@7956e22d#L883​
• src/allmydata/util/fileutil.py@c85060c4#L118​

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

[zooko]

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

​http://tahoe-lafs.org/trac/pycryptopp/ticket/46#comment:2

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

[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

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

[davidsarah]

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

[zooko]

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

[davidsarah]

Replying to zooko:

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

+1.

[daira]

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.

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

+1

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

[zooko]

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