[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:4 zooko]:
 > I guess the question is how much is it worth to the attacker to deny the
 user the ability to update this file.

 But it isn't doing that, it's only forcing the user to perform another
 signature and round-trip.

 > ... the attacker could accomplish the same goal by preventing all of the
 user's packets from reaching the servers, or by compromising the servers.

 That would achieve a stronger denial of service.

 Replying to [comment:3 davidsarah]:
 > Replying to [comment:2 zooko]:
 > > 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.

 Wait; for the above defence, the client would need to know the hash of the
 ''previous'' write-enabler in order to calculate the current one. So the
 server would have to store the previous hash and send both hashes. This is
 getting a bit complicated -- is it really important to prevent this
 attack?

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