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