[only responding to one point right now since I don't have much time; I'll try to respond to the rest later]
> Actually the KC_sign value acts either as an add-only cap, or as a > write-only cap when it is used for mutable files. A write-only cap > does not allow reading any of the previous plaintexts or future > plaintexts. I don't know how useful this is, but it was trivial to > support. > > Also note that "full-writecap" doesn't make sense in the add-only > case, since there is no writing, only adding and destroying. (It might > have been a mistake to try to explain the mutable and add-only cases > in the same diagram, but the crypto was identical.) Actually, the add-only (or "write-only") cap needs another couple layers of boxes, because we'll need asymmetric encryption (as opposed to authentication) for it. KC_sign allows an adder/writer to create signed values that will be accepted by readers, but it doesn't give them a way to add confidential data which can only be read by readers (and not by everyone else). It'll take an encryption key derived from KC_sign, and a decryption key that's available to readcap holders (probably by having the original master-cap-holder create the keypair, encrypt KC_encrypt with KC_sign, and KC_decrypt with R, or something). I suppose another useful diagram might to show the various caps in different columns, list the operations available for each (write, add, read, verify), the strengths of the security properties available to each (C/I/Ir bits, collision resistance, etc), and which attenuations can be performed with or without server interaction. There should be an additional column for the server itself, showing how strong of a verification step it can do rooted solely upon the storage-index. One more idea to throw out.. to make the immutable uploading process more stateless, we were thinking of defining an "upload id", which is used from the initial "will you accept my share" request to the final "that was the last byte of the share, make it visible to the world". This upload-id would bind together all of the various pipelined messages that will constitute the upload. (the storage-index could be used for this, except that in our new schemes, it won't be known until the end). The upload-id could also be used to resume an interrupted upload, assuming the client can remember (or re-derive) it, and the share hasn't been finalized. Now, to avoid needing an encrypted transport, we must avoid shared secrets, so one idea we've discussed was to use an ECDSA keypair as the "upload id". Basically the initial "will you hold my share" request includes a verifying key, and all subsequent upload messages will be signed by the corresponding signing key. When the upload process is finalized, the keypair is discarded. This keypair could even be shorter than usual, because it doesn't need to provide long-term security. Anyways, such a keypair might tie in to some of the other proof-of-knowledge schemes you've mentioned. Ok, off to dinner, I hope I can read over more of your messages later. thanks! -Brian _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
