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