[tahoe-lafs-trac-stream] [tahoe-lafs] #308: add directory traversal / deep-verify capability?

[tahoe-lafs]

#308: add directory traversal / deep-verify capability?
-------------------------------+--------------------------------------------
     Reporter:  warner         |       Owner:                              
         Type:  enhancement    |      Status:  new                         
     Priority:  major          |   Milestone:  2.0.0                       
    Component:  code-dirnodes  |     Version:  0.7.0                       
   Resolution:                 |    Keywords:  vdrive newcaps verify repair
Launchpad Bug:                 |  
-------------------------------+--------------------------------------------

Comment (by davidsarah):

 In http://tahoe-lafs.org/pipermail/tahoe-dev/2009-July/002302.html , zooko
 asks whether we should make all verify caps deep (in the same way that all
 directory read caps are deep). He also points out this counterargument:

 > Now the reason why it could be useful to have a Shallow Verify Cap -- to
 give someone the ability to verify the integrity of a directory without
 also giving them the ability to get the verify-caps of the children -- is
 for a kind of data-privacy.  You might want to give lots of people the
 ability to verify the integrity of your directories without also giving
 them the ability to trace your directory structure -- the sizes and link
 structure of your directories and files.  As we've recently been
 discussing, it might be nice for every storage server to have a verify cap
 to go with every share that it holds.  We generally agree that "verify
 caps are not secret" -- everyone in the world can see everyone else's
 verify caps.  You might not want everyone to be able to see the shape of
 your filesystem though!

 For the next version of the Elk Point protocol I'm working on (v4), I plan
 to make shallow verify caps the same as storage indices. So, it would be
 automatic that every storage server has a shallow verify cap for each
 share that it holds.

 In this context I agree with the counterargument. A server shouldn't
 automatically get deep verify authority for the shares it holds.

 zooko argued for a different conclusion:
 > The only problem is: *they can do that anyway*.  Anybody who can observe
 your Tahoe storage service connections (even though they are encrypted) or
 who operates a storage server can easily detect the exact structure of
 your filesystem -- which directories are linked to which other directories
 and files, as well as the precise size of all of the files. To defend
 against this sort of traffic analysis or pattern detection is somewhere
 between "hard" and "impossible".  Our comrades over at the GNUnet project,
 the Freenet project, and others have been trying to develop such
 techniques for years (both Brian and I have contributed to such projects
 in the past, Brian more recently than I).  Whether they're close to
 succeeding is not clear to me (perhaps some representative of such
 projects or someone whose expertise is more current than mine could speak
 up).  But it is certain that TahoeLAFS will not offer such privacy in the
 next couple of releases.

 I don't agree that the cap protocol should be designed in a way that
 precludes this privacy gain. It's certainly hard to achieve privacy of
 directory structure against storage servers (even when running Tahoe-LAFS
 over Tor, I2P, etc.). However, if we move to an unencrypted storage
 protocol (or make encryption optional for that protocol), then making all
 verify caps deep would reveal the whole directory structure even to
 ''passive'' observers.

-- 
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/308#comment:10>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage