[tahoe-dev] [mm] unparseable directory

zooko zooko at zooko.com
Mon May 5 18:48:20 UTC 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