[tahoe-dev] "Elk Point" design for mutable, add-only, and immutable files

[David-Sarah Hopwood]

David-Sarah Hopwood wrote:
> Re using an ECDSA keypair as the "upload id":
> I think it's desirable to continue to avoid relying on public key
> cryptography in the immutable file protocol. The above argument shows
> that we don't need it to prevent roadblock attacks. In fact the only
> advantage of using it, would be to make the authentication of
> uploaded data per-message rather than per-upload (since the integrity
> of the whole upload will still be protected by the check on T being
> derived from the UEBhash).

"derived from K1_enc, Dhash and UEBhash", I should have said.

(As long as T is long enough, i.e. >= n bits, it is not necessary for
S to be derived from K1_enc, Dhash and UEBhash, because if an attacker's
share uses a different S then the server will treat it as belonging to
a different file.)

> That might be of benefit against an
> attacker who can disrupt individual messages only with some probability
> significantly less than 1; but I think it is more reasonable to
> assume that if an attacker can disrupt any messages between a given
> client and server, then it can disrupt all of them.

On further consideration, it might be easier for an attacker to
passively eavesdrop an upload id and then insert messages with the
same id, rather than changing any messages. Is that the kind of attack
that you were attempting to prevent with the ECDSA signatures on
messages?

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com