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

[David-Sarah Hopwood]

Zooko O'Whielacronx wrote:
> Nikita Borisov posted on twitter:
> 
> "Do you need VCs [verify caps] to be generatable from RCs [read caps] offline?
> If not, make RC=H2(VK), lookup VK to generate VC=H1(VK)"
> 
> I haven't thought through this suggestion yet, but I thought I would
> post it in case I don't get time to do so anytime soon.

What was the motivation for this suggestion?

I think Elk Point is already a refinement of this: the read and verify caps
are both derived from hashes of (Dhash, V), but they share the T field,
which increases the cost of roadblock attacks. And the key K1 is also
input to the hash that generates R (based on your idea at
<http://zooko.com/imm-short-readcap-simple-drawing.svg>), which is what
enables all bits of the read cap to act as integrity-checking bits.

Also, Elk Point does allow a verify cap to be derived offline from a
read cap. (If T is not sufficiently long then it must be a read cap that
includes the U field, but that's unavoidable. Note that for immutable files,
then to ensure collision resistance, T should be sufficiently long that
a verify cap can be derived offline from any read cap.)

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