[tahoe-dev] Idea for grid-based aliases

[Brian Warner]

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