tahoe-lafs
/
trac-2024-07-25
2
0
Issues 1.1k Wiki

use ChaCha⊕AES encryption #1164

New Issue
Open
opened 2010-08-09 22:00:12 +00:00 by zooko · 15 comments
zooko commented 2010-08-09 22:00:12 +00:00
Copy Link

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

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

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

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] 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: * source:src/allmydata/dirnode.py@35f37cc5#L175 * source:src/allmydata/dirnode.py@35f37cc5#L294 * source:src/allmydata/immutable/filenode.py@0ef59394#L185 * source:src/allmydata/immutable/upload.py@196bd583#L620 * source:src/allmydata/immutable/upload.py@196bd583#L738 * source:src/allmydata/mutable/filenode.py@4563ba45#L161 * source:src/allmydata/mutable/filenode.py@4563ba45#L166 * source:src/allmydata/mutable/publish.py@45adde71#L693 * source:src/allmydata/mutable/retrieve.py@7956e22d#L883 * source:src/allmydata/util/fileutil.py@c85060c4#L118 This is inspired by [The One-Hundred-Year Cryptography Project](wiki/OneHundredYearCryptography).
zooko added the
code
major
defect
1.8β
 labels 2010-08-09 22:00:12 +00:00
zooko added this to the undecided milestone 2010-08-09 22:00:12 +00:00
zooko modified the milestone from undecided to 1.9.0 2010-08-09 22:16:28 +00:00
zooko commented 2010-09-03 18:13:20 +00:00
Author
Copy Link

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:-1@@)

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

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:-1](/tahoe-lafs/trac-2024-07-25/issues/1164#issuecomment--1)@@) I would be interested in the feedback of Jack, Yu Xue, David-Sarah, or Brian about this issue.
zooko added
enhancement
 and removed
defect
 labels 2010-09-29 05:07:19 +00:00
zooko modified the milestone from 1.9.0 to soon 2011-04-24 04:05:49 +00:00
zooko modified the milestone from soon to 1.10.0 2011-04-24 04:07:01 +00:00
zooko commented 2011-09-03 18:50:43 +00:00
Author
Copy Link

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

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 commented 2012-03-29 21:10:01 +00:00
Owner
Copy Link

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.

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 commented 2012-03-29 21:31:12 +00:00
Owner
Copy Link

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

Hmm, I see this is explicitly listed as one of the goals for the 1.10 milestone. So, I'll leave it in.
zooko commented 2012-09-13 14:08:19 +00:00
Author
Copy Link

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

I currently intend to get this landed in trunk for Tahoe-LAFS v1.11.
davidsarah commented 2012-10-11 20:09:42 +00:00
Owner
Copy Link

Replying to zooko:

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

+1.

Replying to [zooko](/tahoe-lafs/trac-2024-07-25/issues/1164#issuecomment-79290): > I currently intend to get this landed in trunk for Tahoe-LAFS v1.11. +1.
daira commented 2013-07-18 19:14:00 +00:00
Owner
Copy Link

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.

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.
tahoe-lafs modified the milestone from 1.11.0 to soon 2013-07-18 19:14:00 +00:00
zooko commented 2013-07-18 19:43:18 +00:00
Author
Copy Link

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

Replying to [daira](/tahoe-lafs/trac-2024-07-25/issues/1164#issuecomment-79292): > I suggest that XSalsa+AES support go into 1.12, unless it is ready for 1.11 without slipping the schedule. +1
tahoe-lafs modified the milestone from soon to 1.12.0 2013-07-22 20:42:02 +00:00
zooko commented 2013-09-30 05:21:24 +00:00
Author
Copy Link

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.

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 commented 2013-09-30 14:15:08 +00:00
Author
Copy Link

I opened [//trac/pycryptopp/ticket/15#comment:79286 pycryptopp ticket #94] to track adding ChaCha into pycryptopp.

I opened [//trac/pycryptopp/ticket/15#[comment:79286](/tahoe-lafs/trac-2024-07-25/issues/1164#issuecomment-79286) pycryptopp ticket #94] to track adding ChaCha into pycryptopp.
zooko changed title from use XSalsa20+AES-128 encryption to use ChaCha⊕AES encryption 2013-10-11 11:32:38 +00:00
warner commented 2016-03-22 05:02:25 +00:00
Copy Link

Milestone renamed

Milestone renamed
warner modified the milestone from 1.12.0 to 1.13.0 2016-03-22 05:02:25 +00:00
warner commented 2016-06-28 18:17:14 +00:00
Copy Link

renaming milestone

renaming milestone
warner modified the milestone from 1.13.0 to 1.14.0 2016-06-28 18:17:14 +00:00
daira commented 2016-08-04 14:52:59 +00:00
Owner
Copy Link

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.

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](https://cryptography.io/en/latest/hazmat/primitives/)' (which Tahoe-LAFS already depends on via pyOpenSSL >= 0.14) where possible. It doesn't look like cryptography supports [ChaCha](wiki/ChaCha)20 unfortunately; we could either fix that, or use pysodium for that instead.
exarkun commented 2020-06-30 14:45:13 +00:00
Copy Link

Moving open issues out of closed milestones.

Moving open issues out of closed milestones.
exarkun modified the milestone from 1.14.0 to 1.15.0 2020-06-30 14:45:13 +00:00
meejah commented 2021-03-30 18:40:19 +00:00
Owner
Copy Link

Ticket retargeted after milestone closed

Ticket retargeted after milestone closed
meejah modified the milestone from 1.15.0 to soon 2021-03-30 18:40:19 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels   
0.2.0

   
0.3.0

   
0.4.0

   
0.5.0

   
0.5.1

   
0.6.0

   
0.6.1

   
0.7.0

   
0.8.0

   
0.9.0

   
1.0.0

   
1.1.0

   
1.10.0

   
1.10.1

   
1.10.2

   
1.10a2

   
1.11.0

   
1.12.0

   
1.12.1

   
1.13.0

   
1.14.0

   
1.15.0

   
1.15.1

   
1.2.0

   
1.3.0

   
1.4.1

   
1.5.0

   
1.6.0

   
1.6.1

   
1.7.0

   
1.7.1

   
1.7β

   
1.8.0

   
1.8.1

   
1.8.2

   
1.8.3

   
1.8β

   
1.9.0

   
1.9.0-s3branch

   
1.9.0a1

   
1.9.0a2

   
1.9.0b1

   
1.9.1

   
1.9.2

   
1.9.2a1

   
LeastAuthority.com automation

   
blocker

   
cannot reproduce

   
cloud-branch

   
code

catch-all for anything that can be fixed by writing code but isn't classified better

  
code-dirnodes

anything involving tahoe directories

  
code-encoding

immutable-file encoding format/layout, cap format, encoding/decoding algorithms

  
code-frontend

general frontend things: new user-facing interfaces, FTP/SFTP servers, FUSE-like interfaces

  
code-frontend-cli

CLI tools

  
code-frontend-ftp-sftp

   
code-frontend-magic-folder

   
code-frontend-web

webapi interfaces, user-facing "WUI" interfaces

  
code-mutable

anything involving mutable files: encoding/decoding, share format

  
code-network

Introducer, locating storage servers, establishing/maintaining connections to them

  
code-nodeadmin

node startup/shutdown, tools to create nodes, logging tools, management/monitoring tools, manhole, disk-space-limiting tools

  
code-peerselection

server selection/sorting algorithm, rebalancing code, allocation policy, swarming-download

  
code-storage

storage-server implementation, share-storage directory layout, client-to-server share transfer protocol

  
contrib

problems with non-core things that live in the source:contrib/ directory

  
critical

   
defect

   
dev-infrastructure

things that help us build Tahoe: buildbot, automated speed/memory/code-coverage tests and results-displayers, IRC channels, mailing lists, this Trac instance

  
documentation

docs items. Also use 'docs' keyword on tickets in more specific components.

  
duplicate

   
enhancement

   
fixed

   
invalid

   
major

   
minor

   
n/a

   
normal

   
operational

things involved in running a tahoe grid, external tools to monitor/maintain a grid (like "nodeadmin" but larger-scale). Was also used for issues with the allmydata.com grid.

  
packaging

setup.py script, library dependencies, binary packages, licensing, installation instructions

  
somebody else's problem

   
supercritical

   
task

   
trivial

   
unknown

Uncategorized. All tickets default to this component until someone updates it.

  
was already fixed

   
website

things about the tahoe-lafs.org website (and sometimes this Trac instance, shared with 'dev-infrastructure')

  
wontfix

   
worksforme
No Label
0.2.0
0.3.0
0.4.0
0.5.0
0.5.1
0.6.0
0.6.1
0.7.0
0.8.0
0.9.0
1.0.0
1.1.0
1.10.0
1.10.1
1.10.2
1.10a2
1.11.0
1.12.0
1.12.1
1.13.0
1.14.0
1.15.0
1.15.1
1.2.0
1.3.0
1.4.1
1.5.0
1.6.0
1.6.1
1.7.0
1.7.1
1.7β
1.8.0
1.8.1
1.8.2
1.8.3
1.8β
1.9.0
1.9.0-s3branch
1.9.0a1
1.9.0a2
1.9.0b1
1.9.1
1.9.2
1.9.2a1
LeastAuthority.com automation
blocker
cannot reproduce
cloud-branch
code
code-dirnodes
code-encoding
code-frontend
code-frontend-cli
code-frontend-ftp-sftp
code-frontend-magic-folder
code-frontend-web
code-mutable
code-network
code-nodeadmin
code-peerselection
code-storage
contrib
critical
defect
dev-infrastructure
documentation
duplicate
enhancement
fixed
invalid
major
minor
n/a
normal
operational
packaging
somebody else's problem
supercritical
task
trivial
unknown
was already fixed
website
wontfix
worksforme
Milestone
Clear milestone
No items
No Milestone
soon
Assignees
Clear assignees
No Assignees
5 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Reference: tahoe-lafs/trac-2024-07-25#1164
No description provided.
Delete Branch "%!s(<nil>)"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?