| | 1 | This page is for notes and design considerations for the next version of |
| | 2 | tahoe's mutable files. NewCapDesign includes a lot of desired features, this |
| | 3 | page is about the backend layout that would make those features possible. |
| | 4 | |
| | 5 | * #217 contains a lot of the original notes. |
| | 6 | * #492 adds a ciphertext hash tree |
| | 7 | * #794 is about creating writecaps from passphrases |
| | 8 | * #795 is about append-only filecaps, #796 is closely related |
| | 9 | * #308 is about deep-traversal dircaps, which will require support from the |
| | 10 | underlying mutable files |
| | 11 | |
| | 12 | = Yay ECDSA = |
| | 13 | |
| | 14 | Once we have ECDSA (#331), we'll have a general-purpose signing primitive |
| | 15 | with short fields (K=kappa bits for the signing key, 2K for the verifying |
| | 16 | key, and 4K for the signature, with an expected K=128bits, so 16-byte signing |
| | 17 | keys, 32-byte verifying keys, and 64-byte signatures). Our current RSA-based |
| | 18 | signatures use 1216-*byte* signing keys, 292-byte verifying keys, and |
| | 19 | 256-byte signatures. |
| | 20 | |
| | 21 | The RSA fields are so large that we clearly cannot put them in the filecaps, |
| | 22 | so the encoding scheme requires them to be stored in the shares, encrypted |
| | 23 | and hashed as necessary. The DSA keys are short enough (in most cases) to put |
| | 24 | directly in the filecap, simplifying the design considerably. |
| | 25 | |
| | 26 | = Desired Features = |
| | 27 | |
| | 28 | * fewer roundtrips: mutable retrieve must currently fetch the pubkey (or |
| | 29 | encrypted privkey) from at least one server, which complicates the state |
| | 30 | machine and can add roundtrips when we guess incorrectly about a good |
| | 31 | amount of data to fetch on the initial read |
| | 32 | * offline attenuation: it should be possible to attenuate/diminish the |
| | 33 | writecap into the readcap without retrieving any shares, otherwise |
| | 34 | operations like adding a child dircap to a parent directory will be much |
| | 35 | slower (a roundtrip per child). |
| | 36 | * writecap -> readcap -> deep-traversal-cap -> verifycap . This requires |
| | 37 | some form of intermediate key scheme. |
| | 38 | * server-side share validation |
| | 39 | * one option is to get rid of the "write-enabler" shared secret and rely |
| | 40 | upon server validation exclusively. This would make share migration |
| | 41 | easier and remove one need for an encrypted channel (lease secrets would |
| | 42 | continue to need protection unless/until they too are replaced with |
| | 43 | signature verification). However, it would also increase server load. |
