[tahoe-dev] my blog on an decentralized filesystem

[Brian Warner]

> on a strictly functional note - what's the current thinking on sending
> these links around in email?  they're really long (by necessity), but of
> course, don't format well in the email client.

We've got two plans. The long-term one is to switch to DSA-based directory
caps and make them short enough to email conveniently, formatted to resist
word-breaking. I'm not sure where the cap format details are, I think they're
on a whiteboard somewhere around the office, but the new format should look
something like:

 http://127.0.0.1:8123/uri/IRF1ht4xztp7poyujbjzZUGNRDIe7b11sy4E717NB4ppg

The significant features: the overall cap is <= 72 characters, the important
crypto bits use base-62 encoding (A-Za-z0-9) with no word-breaking characters
like underscores or commas, and we still retain reasonable security
properties (192 bits of key material). See ticket #217 (and #102 to a lesser
extent) for details.

We hope to improve CHK URIs too.

The medium-term one is to use a tinyurl-like service, with a central server
that will translate your short (emailable) index into a full-size URI. Of
course, there are a number of security implications to remain aware of: the
naive implementation ('return uritable[index]') means the server operator
gets to see all your files, and if the index is too tiny then it becomes
possible for an attacker to guess the index and thus get the file. A slightly
more clever implementation (AES_decrypt(key=hash1(index),
data=fetch(hash2(index)))) doesn't let the server see the links but could
still be vulnerable to guessing attacks. We don't yet have an open ticket for
this one, but our target is to get it done within the next 6 weeks or so
(it's on the 0.9.0 milestone list).

> is there an approved way to shorten them when emailing them around?

Not yet.. there's no short-term plan in place.

> it would probably require a central point of failure, which of course,
> is not ideal...

Yeah, exactly. The DSA-based caps will help a lot, without introducing the
failure point.. beyond that, you've got to pick tradeoffs between integrity,
confidentiality, availability, and complexity..

cheers,
 -Brian