[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 [comment:2 zooko]:
 > Hm, it is worth adding protection against replay attack? This attack
 would be a denial of service in which the attacker stores an old
 {{{writecap.key.sign([tag, new-write-enabler, storage-index, serverid])}}}
 and every time you try to set a ''new'' new write-enabler the attacker
 replays this old new write-enabler to reset it.

 The impact of that is an extra signature and round-trip (for each server
 whose write-enabler has been attacked, in parallel) when an honest client
 later tries to modify the file. Is it worth the attacker's cost (a round-
 trip to set the enabler) to perform that attack?

 > One good defense would be to include the one-way hash of the previous
 write-enabler in the message.

 Oh, good idea.

 > As davidsarah mentioned in comment:1, it might be convenient anyway for
 the server to send this one-way hash of the current write-enabler to the
 client, in order to inform the client about whether they need to rekey.

 Yes, I now think we should do this.

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