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 _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
