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

[Brian Warner]

[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