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

[David-Sarah Hopwood]

David-Sarah Hopwood wrote:
> Brian Warner wrote:
>> [only responding to one point right now since I don't have much time;
>> I'll try to respond to the rest later]
>>
>>> Actually the KC_sign value acts either as an add-only cap, or as a
>>> write-only cap when it is used for mutable files. A write-only cap
>>> does not allow reading any of the previous plaintexts or future
>>> plaintexts. I don't know how useful this is, but it was trivial to
>>> support.
>>>
>>> Also note that "full-writecap" doesn't make sense in the add-only
>>> case, since there is no writing, only adding and destroying. (It might
>>> have been a mistake to try to explain the mutable and add-only cases
>>> in the same diagram, but the crypto was identical.)
>>
>> Actually, the add-only (or "write-only") cap needs another couple layers
>> of boxes, because we'll need asymmetric encryption (as opposed to
>> authentication) for it. KC_sign allows an adder/writer to create signed
>> values that will be accepted by readers, but it doesn't give them a way
>> to add confidential data which can only be read by readers (and not by
>> everyone else).
> 
> Oh, good point. I'll fix that in the next version.

<http://jacaranda.org/tahoe/mutable-addonly-elkpoint-3.png>
<http://jacaranda.org/tahoe/mutable-addonly-elkpoint-3.svg>

I'll explain it in more detail tomorrow. I dropped the ability to have
write-only caps that do not allow reading, so only needed symmetric
encryption.

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