From b4e8d4c81630971a51b24044936bc305176c30e0 Mon Sep 17 00:00:00 2001
From: warner <>
Date: Tue, 25 Aug 2009 10:46:44 +0000
Subject: [PATCH] start to write down notes

[Imported from Trac: page NewMutableEncodingDesign, version 1]
---
 NewMutableEncodingDesign.md | 43 +++++++++++++++++++++++++++++++++++++
 1 file changed, 43 insertions(+)
 create mode 100644 NewMutableEncodingDesign.md

diff --git a/NewMutableEncodingDesign.md b/NewMutableEncodingDesign.md
new file mode 100644
index 0000000..1350cc1
--- /dev/null
+++ b/NewMutableEncodingDesign.md
@@ -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.