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 _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
