Brian Warner wrote: > One design described on NewMutableEncodingDesign calls for a readcap > that contains a hash of the writecap and a hash of the verifying key.
For mutable files, I think that a variation of the scheme that Zooko described at the start of this thread is possible. Just replace 'v' with a public verification key. 'k' is still a symmetric decryption key, and 'r' and 'k_enc' are defined as before. So the only difference is that you check a signature on the ciphertext using 'v', rather than checking that 'v' is a hash of the ciphertext. The verify cap can be H(k_enc, v). (This also applies to the immutable scheme.) It is not possible to offline-attenuate a read cap to a verify cap, but it would be possible to have an URL format that includes both. As pointed out in <http://allmydata.org/trac/tahoe/ticket/217#comment:44>, we don't need collision resistance for mutable files. So a mutable read cap could be only 128 bits! (Less if we spend 2^k hash computations to reduce the size by k bits.) In base-62 encoding, that would be something like: tahoe:MR-4V2uIYVX0PcHu9fQrJ3GSH Impressively short, no? The write cap would be a seed from which the symmetric key and the signing key are generated. This means it can also be short, for example 128 bits. In this scheme you can still offline-attentuate a write cap to a read cap, provided that you can derive a public key from a private key in the signature scheme, which is true for most discrete-log-based cryptosystems including ECDSA. -- David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
