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 _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
