[tahoe-dev] "Elk Point" design for mutable, add-only, and immutable files

[David-Sarah Hopwood]

David-Sarah Hopwood wrote:
> Thinking off the top of my head: suppose that there were an arbiter
> who you trusted not to disclose the read cap or the file contents,
> and that the server trusted to decide which shares are the correct
> ones. Then you could give the read cap to the arbiter, and they could
> sign a declaration that you could give to the server along with the
> shares.
> 
> I wonder whether there's a way to do the same thing without an arbiter
> by using some fancy zero knowledge proof. Effectively you have to prove
> that S = f(R || T), where f is currently a hash function but might be
> replaceable with some other kind of deterministic one-way function,
> without giving away R.

Actually that's not a correct description of what you would have to
prove in order to get the full integrity check -- for that you would also
have to prove hash_n(decrypt[R](K1_enc), Dhash, V) = R (which seems like
it is probably not amenable to a ZK proof, unless they've got a lot more
advanced since I last looked at them). But just proving that the creator
of the share knows R, as the scheme I suggested following the above
paragraph does, is helpful anyway.

I did find a way to eliminate K1_enc and to make S and V be group elements
in the same cryptographic group, that are related by V = S^x where the
share creator knows x. But that doesn't help by itself because a roadblock
attacker can choose an arbitrary x, so it doesn't tie S to a specific V.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com