Why encrypt first?

[Adam Hunt]

One little typo and there goes anything resembling a reasonably
professional layout :) Please ignore my last message, it was sent by
accident when I slipped and hit the wrong combo of keys.

-------------------------------------------------------

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.


   1. 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 insurmountable.

I really appreciate everyone's 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 working on this project who are.

Adam Hunt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20150803/e3b11ebd/attachment.html>