[tahoe-dev] UEB hash size

[Zooko Wilcox-O'Hearn]

On Jul 12, 2009, at 20:56 PM, Shawn Willden wrote:

> In fact, as far as I can see the UEB hash is entirely redundant --  
> it's a sort of an integrity optimization that allows shares to be  
> checked more quickly, but as far as ensuring the integrity of the  
> file as a whole, it's redundant, because the read key is derived  
> from the content hash, so you can use it to verify integrity.

Hey -- you're starting to come up with the same sort of thing that I  
came up with as I mentioned in my previous note -- a way to do both  
decryption and integrity checking on the file with only one "strong  
crypto worth" of bits.  :-)  However, you're not quite there yet,  
because the downloader wouldn't have the ability to verify the  
integrity of the individual shares, only of the final plaintext, so  
if the integrity check fails you wouldn't know which server(s) were  
serving corrupted shares.  Also that scheme wouldn't allow  
incremental integrity checking of the file before the whole thing was  
downloaded.  Finally, that would not work if the uploader used a  
randomly-chosen (not-content-hash-key) or an added-convergence secret.

Still, I like the way you think...

> As for the impact of the size, the smaller the URI data, the more  
> read cap index entries I can pack into an index file in the grid- 
> based burst trie (without making the files so big they're slow to  
> upload and retrieve), and since those files have to get uploaded  
> and downloaded frequently, tighter packing improves performance.

Hm, this is definitely the kind of reason why I greatly value small  
capabilities.

Can you characterize it as something like "the difference between a  
24-byte immutable read cap and a 32-byte and a 64-byte is X times as  
many trie node fetches for an average file download"?

Regards,

Zooko