Hello, I am currently developing a few small pieces of software for storing all my mails in couchdb so that syncing local mails and mails on the server becomes faster, I can easily get notifications about new mail and so on. I already have a helper that's specified in my .forward file on the mailserver which is written in C and automatically puts all new mails into a couchdb on the server. Also, I have set up replication between my server and my computer, written a small FUSE filesystem in nodejs that lets me access my mails like a Maildir using mutt and written a small helper that shows notifications on my display whenever I have new mail.
However, I'm a bit uncomfortable with storing my mails in a couchdb on the server in plaintext. On my computer, I want the DB to contain plaintext so that it's easy to use view functions so that I can easily work on views in Futon and so on, but on the server, I would like the documents to be encrypted using public-key crypto: I would have a private key on my devices from which I want to be able to read mail. The server would only have the public key. My C program that inserts new mails into the database would first encrypt them using the public key and then insert them into the database. So, the server-side couchdb would have to do nothing special. However, I would like my client-side couchdb to decrypt the documents together with their attachments during pull replication and to encrypt them during push replication. For this, I would need couchdb to support either special crypto options for replication or a generic replication handler with write access to both the document itself and its attachments. However, as a generic replication handler would mean that crypto operations would have to be done in JS, the public-key crypto operations would probably be unusably slow (2048-bit decryption takes 361ms on my laptop with the JS implementation at <http://www-cs-students.stanford.edu/~tjw/jsbn/>). Therefore, this way would also require a native crypto library to be exposed to the JS code. So, my question is: How about adding access to a native crypto API for JS code and adding a document handler for replication that has access to attachments? Alternatively, in case you don't like that idea, what do you think about adding special `encrypt` and `decrypt` options to the Replicator API that cause all replicated documents to be encrypted or decrypted using the key provided as the option's value? If you don't totally dislike this idea, I'll try to write a patch (although that could take quite some time because I don't really know Haskell yet).
signature.asc
Description: Digital signature
