[tahoe-lafs-trac-stream] [tahoe-lafs] #1426: re-key (write-enabler) protocol

[tahoe-lafs]

#1426: re-key (write-enabler) protocol
------------------------------+-----------------------
     Reporter:  warner        |      Owner:
         Type:  enhancement   |     Status:  new
     Priority:  major         |  Milestone:  undecided
    Component:  code-mutable  |    Version:  1.8.2
   Resolution:                |   Keywords:
Launchpad Bug:                |
------------------------------+-----------------------

Comment (by davidsarah):

 Replying to [ticket:1426 warner]:
 > Mutation requests must be accompanied by the correct write-enabler. If
 > the WE is wrong, the server should return a distinctive error message,
 > and the client should perform the re-key protocol, then try the mutation
 > again. This incurs a CPU cost of N pubkey signatures for the client (one
 > per server) and one pubkey verification on each server. But it only
 > needs to be done once per file per migration, and can be done lazily as
 > the file is being modified anyways, so the delay is not likely to be
 > significant.
 >
 > The original mutable-share creation message can either provide the
 > initial write-enabler, or it can leave it blank (meaning all writes
 > should be denied until the share is re-keyed).

 As a small optimization, retrieving a share could also return a bit saying
 whether the share has a non-blank write-enabler. Since most updates of
 mutable objects are read-then-write, this means that the client will
 usually know whether it needs to re-key without incurring an extra round-
 trip.

 (The server could alternatively return a one-way hash of the write-
 enabler,
 to allow the client to determine whether it is correct, but that probably
 isn't a significant win. It's sufficient to optimize out the round-trip
 in the common case where the share has only been written by honest
 clients.)

 If new mutable objects always start with a blank write-enabler, then the
 extra
 cost of the rekeying protocol (N signatures by the client and a
 verification
 by each server) will only be paid for objects that are actually modified,
 i.e.
 when the second version is written.

-- 
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1426#comment:1>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage