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

[Brian Warner]

David-Sarah Hopwood wrote:
> 
> 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?

Yes. The idea is that the first message contains a "prepare to accept
share" message which is signed by some Accounting-based key (i.e. the
key which enables the uploader to consume space at all). Then the second
and subsequent messages will contain "here's some more share data"
packets, and finally the last message says "that's the last one, please
commit to disk, and oh here's the storage-index to use for it".

We need a way to bind all of these packets together, rather than signing
every one with the Accounting key. (in fact, the Accounting-key-signed
message might be authorizing a Helper to do the upload, so it might be
inconvenient to use the Accounting key for every one). If we had a
confidential transport channel, we could create an unguessable string,
put it in the signature on the first message, then simply copy it into
all subsequent messages. The server would keep a table mapping this
string to a filehandle for the new share.

But if we want to get away from encrypted transports, we need something
more than a shared secret. So the per-upload ECDSA key could take its
place: the first message says "by the power of my Accounting key, please
accept a share upload defined by the following (short-lived) upload
key", and then all other messages would be signed by the upload key. The
upload pubkey would be used to index the server's table.

Really, the idea is to let you send the share in lots of small messages,
to reduce your memory footprint, while still making sure that every
message was authorized by the same Account holder. And, to make Helpers
still feasible: the Helper could generate the upload keypair, hand the
pubkey back to the uploading client, the client could sign it with their
Accounting key (along with some annotations that say "this is only good
for this one file, for the next 10 minutes, for no more than 10MB"), and
then the Helper could do the rest without further authorization
exchanges with the client.

cheers,
 -Brian