[tahoe-dev] Removing the dependency of immutable read caps on UEB computation

[David-Sarah Hopwood]

[I'm having trouble with incoming email at the moment, so I'm having
to read this thread from the list archives. That means my responses may
be a bit delayed and won't be properly threaded.]

Brian Warner wrote:
> I *am* intrigued by the idea of immutable files being just locked-down
> variants of mutable files. A mutable-file readcap plus a hash of the
> expected contents (i.e. H(UEB1)) would achieve this pretty well.. might
> not be too much longer than our current immutable readcaps, and we could
> keep the encoding-parameter-sensitive parts (UEB2) in the signed (and
> therefore mutable) portion, so they could be changed later.

We can do better than that. Notice that the mutable and immutable
Elk Point protocols are (deliberately) already very similar.
In particular, the mutable protocol obtains the same (n+t)/2 bits of
collision-resistance as the immutable protocol does, for the values
that are hashed by hash_m to obtain T || U. (This is from the point
of view of a read cap holder. Assumptions: m >= n+t, K1 is at least
n bits, and all cryptographic primitives have the strength expected
from their security parameters.)

When it is used for mutable files, this collision-resistance for EncK1,
Dhash and V doesn't really buy you anything because even if those values
are fixed, the file contents can still vary. However, if a hash of the
plaintext (also of length m bits, say) is optionally included in the input
to hash_m, the same protocol can be used for immutable files, and still
obtains (n+t)/2 bits of collision resistance for the plaintext, from
the point of view of a read cap holder.

Although the protocol for mutable and immutable files would be the same
in this approach, the encoding of a read-cap should include a bit saying
whether it is immutable, and the client should require and check the
plaintext hash if this bit is set. This enables a read cap holder to
tell off-line whether they are getting immutability and collision-
resistance for that cap.

As Shawn points out, this approach allows an immutable file creator to
deny further access to the file. However, if the destroy cap functionality
is supported, then the file creator is intentionally authorized to do that
by using the destroy cap, so it's not an attack if they can also do it in
some other way.

(I'm distinguishing between the creator and uploader, since they may
not be the same. The creator of a file is the party who originally holds
all of the secret keys for that file.)

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com