Why encrypt first? (tahoe-dev Digest, Vol 101, Issue 4)

Stuart W. Card stu.card at critical.com
Sat Aug 8 19:48:38 UTC 2015


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The following is not exactly on topic for this thread but is generally
related...

We are trying to build a Delay/Disruption Tolerant Networking (DTN)
stack with:

- - metadata markup (gollum?)

- - versioning (git-annex?)

- - delta encoding (rsync?)

- - compression (bzip2?)

- - encryption / secret sharing / FEC (Tahoe-LAFS)

- - chaffing & winnowing (maybe)

- - concurrent multipath onion routing (some of our own old work)

Some but not all these functions are integrated in duplicity/duplicati
when run with a Tahoe storage backend.

We are trying to keep these functions loosely coupled as installation
scenarios (and user preferences) differ.

We are focusing on immutable files as mutable files seem unnecessary
given our layers above Tahoe.

Any suggestions?

> On 8/3/15 4:47 AM, Adam Hunt wrote:
> 
>> One part of Tahoe-LAFS' design that I'm particularly curious about is
>> why each file is encrypted in its entirety prior to "chunking" (my
>> term).
> 
> Good question!

- -- 
Stuart W. Card, PhD: VP & Chief Scientist, Critical Technologies Inc.
* Creativity * Diversity * Expertise * Flexibility * Integrity *
Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501
315-793-0248 x141 FAX -9710 <Stu.Card at critical.com> www.critical.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlXGXRYACgkQS7PQ0a2weL453gCeJQQ0yYWStc4/OL1MJoDRwFwO
8iEAn2v85NLag+0ep+eRX0ANiZvzkwCa
=z61Q
-----END PGP SIGNATURE-----



More information about the tahoe-dev mailing list