On Jan 15, 2009, at 17:06 PM, Trent W. Buck wrote: > "Zooko O'Whielacronx" <[email protected]> writes: > >> cool thing #3: That URL contains a symmetric encryption secret, >> and all files stored in that directory are encrypted with it. If >> you give the URL to someone, they can read the contents of the >> files, but if they aren't given the URL, they can't. > > I can immediately see how the other properties are useful, but I > have a hard time believing that you will keep a URL secret. Have > you investigated ways URLs are disclosed to third parties, both > deliberately "Hey Fred, look at this cool repo!" and accidentally > "Hey, someone visited my site directly from <secret URL>, so now > it's in my httpd.log!"
Yes, we've thought about that a lot and so have others. You raise good objections, and the issue is deserving of more investigation and experimentation. > What benefits does this give over "traditional" security methods > such as restricting by originating IP, by username and password > (over e.g. SSL), or kerberos? Convenience and flexibility, and also, we think, better safety in some cases. If you rely on "cool property #3" as your way to prevent unauthorized readers from seeing your darcs repository (or other directory full of files), then it becomes very simple and easy to do things like make a new directory, put into that directory a link to repository A and also a link to repository B. Then give some people a read-cap to that directory, some people a read-cap to repository A, and some people a read-cap to repository B. You can do this using all your familiar tools of directory manipulation like "ln" and "rm" and "mkdir", and the resulting structure of who can see what is reified in an obvious and visible way in the resulting directory structure. > (Maybe you already have a paper or wiki article on this, in which > case a link would be sufficient to satisfy my curiosity.) The tahoe project itself doesn't have a paper or wiki article about this issue in particular. We do have quite a lot of detailed discussion about related issues -- see the "Hack Tahoe!" contest (http://hacktahoe.org ) and the tahoe-dev mailing list (http:// allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev ) for starters. The best thinker and writer on the subject of relying on the secrecy of secrets embedded into URLs is Tyler Close, whose "Web Keys" design is a guiding light for Tahoe: http://waterken.sourceforge.net/web-key Note that Tyler's web-key design (which has caps-in-URL-fragments) is actually more secure than Tahoe's "caps-in-URLs" design, in my opinion. Tyler's design is immune to the "Referer header leakage" problem that you mentioned earlier, for one thing. Tahoe might also be sufficiently safe against that threat, but the analysis of whether or not it is safe is more complicated than the simple safety of web- keys. Tyler is currently engaged in helping the sages of the Web -- w3c, "web architecture group" or such -- think about this approach and whether it is appropriate for standardization. > Have you tested this theory by using a different client (e.g. > curl), tweaking that clients properties, and watching the packets > go by (e.g. wireshark)? That's a good idea. Hopefully someone will do this and report what they find. Regards, Zooko _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
