[tahoe-dev] two reasons not to use semi-private keys in our new cap design

[Brian Warner]

Brian Warner wrote:

> The confidentiality comes from the A/B/C chain, and the integrity
> comes from the 1/2/3 chain. Excepting the master secret (1), there's
> no way to get a single bit to perform both jobs (and still be able to
> derive a storage-index from any cap).

I should clarify this a bit. We spent some time talking about this a
year ago, during earlier work on DSA-based mutable filecaps. At that
time, we were only thinking about server-side validation of shares to
prevent a "roadblock attack", in which someone who learns your storage
index (perhaps the first server you talk to) quickly runs to all the
other servers and uploads junk data under that SI, preventing you from
storing a share under the same index.

These days, we'd like to replace the mutable-file "write enabler" (a
shared secret that allows a writecap holder to modify an existing share)
with a signed share-update message: specifically, we'd like the server
to accept any update which results in 1) a valid share, with 2) a higher
sequence number than the previous version. (this would let us stop using
an encrypted channel to the storage servers, and enable mutable-file
repair from non-writecaps, among other things). So we are now more
interested in full server-side validation than we were before.

Each filecap has some number of bits. Each bit can fulfill one or more
purposes. Some of the purposes (and their abbreviations for this note)
are:

 * "C": confidentiality
 * "I": Integrity
 * "Ir": Integrity, but only useable by the holder of a readcap

For reference, our current URI:CHK: immutable filecaps have two fields:
128 bits of "C" (the readkey), and 256 bits of "I" (the UEB hash).
Likewise, the current URI:SSK: mutable writecaps have 128 "C" bits (the
writekey) and 256 bits of "I" (the pubkey hash). Our verifycaps are 256
"I" bits, and the storage-index is 128 bits that provide nothing, not
even "I".

Hashing a field with "C" bits causes them to lose their "C" status.
Anything hashed from the share data counts as an "I" bit, but if a
secret is mixed in, it only counts as an "Ir" bit.

The shortest conceivable writecap/readcap design would have every bit
offer both "C" and "I". I believe this to be impossible: if the bit is
used for confidentiality, you can't reveal it to a non-readcap-holder,
meaning it can't be used for integrity checking by anyone but a
readcap-holder. So I think the best you could do is to have readcap bits
offer both "C" and "Ir".

To enable full server-side validation, we'd like every bit of the
storage-index to offer "I": integrity checking that is usable by
everybody.

The work we were doing a year ago involved mutable readcaps which had
one section with "C+Ir" bits and a second section with pure "I" bits.
This gave readcap holders a full Ir+I bits of integrity checking, and
gave storage servers a smaller (but non-zero) I bits of integrity
checking (enough to discourage a roadblock attack but not enough to do
full validation and stop using the write-enabler). I think we were
planning on a mutable readcap with 128 C+Ir bits and an extra 64 I bits.

For immutable files, you have to encrypt+encode the file before you can
get the secure hash that forms the root of the integrity check (because
we want to validate the individual shares too). Since you must commit to
the encryption keys before you get those bits, so you can't just derive
the encryption keys from that hash. But you could combine that hash with
some other secret, and hide the main encryption key by encrypting it
with that secret, and then the bits of that secret would each provide
C+Ir. I think this is closely related to Zooko's scheme.

Mutable files are easier, because you can sign anything you like.
Anything that will get you to the right public key will serve as an I
bit: the private key, a semi-private key, or a hash of the public key.
The private and semi-private key bits also count as C bits, so writecaps
(made by using the private key directly) can be short.

Anyways, I hope that there's some way of applying this sort of "C/I/Ir"
analysis to filecap schemes that will let us either build something with
all the properties we want, or prove that we can't get them so we can
stop fussing about and start building some acceptable subset :-).

cheers,
 -Brian