No subject

[Adam Hunt]

I just recently discovered Tahoe-LAFS and find it not only incredibly
fascinating but also a refreshingly novel approach to distributed data
stores.

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).
Wouldn't it make more sense to fragment/chunk the file *then* encrypt each
fragment/chunk/segment? I can see a few possible benefits to this order of
operation:

   1. In the case of file which is inherently linear (e.g. a large media
   file), the segments could be requested in order allowing the file to be
   accessed as it is retrieved. This would make it possible to, say, begin
   watching a large video file prior to the entire file being retrieved. It
   might also be possible to seek to a point in the file in question prior to
   the intervening segments being received. Such features would be useful in a
   VOD (Video On Demand) scenario.
   2. Another possibility that such a scheme would potentially allow for is
   each segment to be encrypted using a different key. Such feature may
   present issues with the "key-in-URL" nature of Tahoe-LAFS but I don't
   imagine such a detail is
   3.
   4.
   5.  time, I'm not exactly an expert when it comes to cutting edge
   cryptographically secure decentralized peer-to-peer distributed data stores
   that scale, though, it would appear that there are at least a few people
   who are. <G>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20150803/c6cab691/attachment.html>