[tahoe-dev] append-only files, write-only backups

[Brian Warner]

Zooko Wilcox-O'Hearn wrote:
> On Tuesday,2009-08-18, at 19:45 , David-Sarah Hopwood wrote:
> 
>> For off-line backup, the security property I want is that I can  
>> perform backups, which do not overwrite any information, using a  
>> key that is stored on-line, but need a separate key (that cannot be  
>> derived from the first) to retrieve the data as it existed on a  
>> given date.

Hmmmmm...

I've created #795 for append-only files and #796 for the specific case
of append-only backups.

Basically, each append-only-able file would have three keypairs:

 A: the whole-file-changing DSA keypair (As/Av)
 B: an appending DSA keypair (Bs/Bv)
 C: an appending RSA (encryption) keypair (Ce/Cd)

The writecap would get you everything, the appendcap gets you Bs+Ce, and
the readcap gets you just the three verification/decryption keys
Av+Bv+Cd. The server must know (and enforce with) the verification keys
Av+Bv.

The server would be responsible for:

 * only allowing full-file rewrites that are signed by As
 * accepting "append" messages signed by Bs and appending them to the
   file (or putting them in a unique file in the share directory, or
   something)

Appendcap holders would need to encrypt their message with Ce, sign it
with Bs, then send it to the servers. Readcap holders would check all
the signature and then use Cd to decrypt the append messages.

Every once in a while, the writecap holder might merge all the append
messages down into the "base object". Until this happened, a colluding
set of servers could discard arbitrary append messages (meaning the file
would not be monotonically increasing). There might be ways to have each
message include the hash of the previous ciphertext to detect this sort
of thing (forcing the server to discard all-or-nothing, restoring
monotonicity, but introducing race conditions).

Maybe "add-only collection" would be a better model for this, instead of
implying that the object contains a linear sequence of bytes. In fact,
we might say that the objects stored in this collection are arbitrary
strings, with IDs based upon hashing their contents, and make the
append(X) operation be idempotent, and give readers an unsorted set of
these strings. This would make things like the add-only directory easier
to model.

So, Zooko, right after you get finished adding ECDSA to pycryptopp,
let's talk about adding RSA/El-Gamal/DH encryption :-).

intrigued,
 -Brian