<div dir="ltr">This is fairly interesting question, anyone got insight?<br><div><br><div class="gmail_quote"><div dir="ltr">po 3. 8. 2015 v 13:40 odesílatel Adam Hunt <<a href="mailto:voxadam@gmail.com">voxadam@gmail.com</a>> napsal:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-size:13.1999998092651px;line-height:17.9999980926514px;font-family:arial,helvetica,sans-serif">I just recently discovered Tahoe-LAFS and find it not only incredibly fascinating but also a refreshingly novel approach to distributed data stores.</div><div class="gmail_default" style="font-size:13.1999998092651px;line-height:17.9999980926514px;font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-size:13.1999998092651px;line-height:17.9999980926514px;font-family:arial,helvetica,sans-serif">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 <i>then</i> <span>encrypt</span> each fragment/chunk/segment? <span style="font-size:13.1999998092651px;line-height:17.9999980926514px">I can see a few possible benefits to this order of operation:</span></div><div class="gmail_default"><ol><li><font face="arial, helvetica, sans-serif"><span style="font-size:13.1999998092651px;line-height:17.9999980926514px">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.</span></font></li><li>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 </li><li><span style="font-family:arial,helvetica,sans-serif;font-size:13.1999998092651px;line-height:17.9999980926514px"><br></span></li><li><span style="font-family:arial,helvetica,sans-serif;font-size:13.1999998092651px;line-height:17.9999980926514px"><br></span></li><li><span style="font-family:arial,helvetica,sans-serif;font-size:13.1999998092651px;line-height:17.9999980926514px"> 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></span><br></li></ol></div><div class="gmail_default" style="font-size:13.1999998092651px;line-height:17.9999980926514px;font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-size:13.1999998092651px;line-height:17.9999980926514px;font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-size:13.1999998092651px;line-height:17.9999980926514px;font-family:arial,helvetica,sans-serif"><br></div></div>
_______________________________________________<br>
tahoe-dev mailing list<br>
<a href="mailto:tahoe-dev@tahoe-lafs.org" target="_blank">tahoe-dev@tahoe-lafs.org</a><br>
<a href="https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev" rel="noreferrer" target="_blank">https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev</a><br>
</blockquote></div></div></div>