[tahoe-dev] [mm] unparseable directory
zooko
zooko at zooko.com
Mon May 5 11:48:20 PDT 2008
following-up to my own post:
On May 5, 2008, at 11:23 AM, zooko wrote:
> The code path for integrity verification of SSK ("Sub-Space Key", as
> called by Freenet, which in our docs are called "Small Distributed
> Mutable Files") is like this:
>
> http://allmydata.org/trac/tahoe/browser/docs/mutable.txt?rev=2514#L163
>
> The access pattern for read is:
> * hash read-key to get storage index
> * use storage index to locate 'k' shares with identical 'R' values
> * either get one share, read 'k' from it, then read k-1 shares
> * or read, say, 5 shares, discover k, either get more or be
> finished
> * or copy k into the URIs
Nathan Wilcox asked about this on IRC. What is the "or copy k into
the URIs" about? The answer is that it is an alternate design tweak
that we have been considering -- if k itself is included in the
capabilities (also known as "URIs") then the download process can
know k before it begins downloading instead of either getting one
share at first and parsing k out of it or getting several shares at
first and parsing k out of one of them.
This is merely a network engineering question, not a security
question, because the value of k is included in the message that is
digitally signed --
http://allmydata.org/trac/tahoe/browser/docs/mutable.txt?rev=2514#L150
http://allmydata.org/trac/tahoe/browser/src/allmydata/mutable/
servermap.py?rev=2514#L552
So two different encodings of the same file with different values of
k can be securely distinguished.
Regards,
Zooko
More information about the tahoe-dev
mailing list