Shawn Willden wrote: > There has been some discussion of ways to create aliases for Tahoe > URLs, in order to allow users to provide shorter, nicer URLs. I > suggested (though I'm sure I wasn't the first) the idea of > variable-security aliases that would allow the user to ask Tahoe to > generate aliases of arbitrary length.
We might want to find a different name for these things, given the existing claim to "alias" used by the things you pass to commands like "tahoe get", which are stored in NODEDIR/private/aliases . Maybe "shortcaps"? It might also be good if the name implied immutability. > Here's the process I envision: > ... > 4. Hash the URI file contents and verify that the result matches the > alias. I don't see any fatal flaws in that, although the lack of a UEB hash on the "alias" cap means that servers can flip bits and the client won't notice until they perform the download verification step (#4). The erasure coding makes this particularly troubling, because without a validated share hash tree, you've got no way of knowing *which* share/s was/were bad, so it's not easy to try decoding again with a different set of shares. Worst case you're looking at something like k-choose-N different possibilities to try. On the other hand, all shares are supposed to have the same UEB, and you can validate the rest of the share up to that (i.e. you can tell if the share its UEB match, even if you don't know the right UEB yet). So you could count the different variations of the UEB that you find (knowing that there's only really supposed to be one), start with the majority, validate the shares up to that, attempt a decode/decrypt with the ones that pass, then perform step 4. If step 4 passes, you're done, else iterate to the next-least-popular UEB variant and try again. This sort of loopback-authentication trick, where CHK is used as an integrity check (and not just for its convergence behavior), is also (I think) at the heart of the immutable filecap design scheme that zooko tried to describe to me, which I tried to capture in NewImmutableEncodingDesign. It works better when the data being stored is short. I'd like to see this kind of approach used to provide a more-secure tinyurl service (where you send a hash of the tinyurl to the server, and get back the encrypted full-url), but of course browsers don't make it easy to run specialized code as a URL-preprocessor. Hmm, maybe I should ask the Jetpack gang if their stuff would make it possible for firefox to be given a "tiny-but-secure:" or "tahoe:" URL scheme and then auto-download and safely execute the necessary code to fetch the resource. That'd be cool. thanks, -Brian _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
