Changes between Version 1 and Version 2 of Ticket #1426, comment 2
- Timestamp:
- 2011-07-10T14:26:44Z (13 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #1426, comment 2
v1 v2 1 1 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. 2 2 3 One good defense would be to include the one-way hash of the previous write-enabler in the message. 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 anyway, in order to inform the client about whether they need to rekey.3 One good defense would be to include the one-way hash of the previous write-enabler in the message. 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.