couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Travis Jensen <travis.jen...@gmail.com>
Subject Re: Encrypting attachments
Date Wed, 13 Apr 2011 18:19:59 GMT
On Wed, Apr 13, 2011 at 11:50 AM, Noah Slater <nslater@apache.org> wrote:

> Where would the encryption key be held?
>
> Encryption key would be held in a hardware security module (well, it would
be derived from a key in the HSM). Wouldn't make much sense to hold it in
the db. :)


> If the database holds it, why bother encrypting? And how will that work
> with replication?
>
> Would it make more sense to en/decrypt in the client app?
>
> I am hoping to build everything out as a CouchApp, which doesn't give me
anywhere else to add the cipher operations.

The alternative I've thought of are:

1. Have a "cipher service" that the browser posts to, which does the
encryption and then turns around and posts to couchdb.  That is certainly a
viable option, but increases the complexity of my architecture.
2. Have a special handler within couch that uses the internal Erlang API to
write the attachment.  Downside is it then uses a non-standard API to use
attachments, but I could live with that (if I could understand the Erlang
API :).
3. Tie into the couch_stream similar to gzip and use a configured "key
provider" that knows how to communicate with the HSM to get the key (derived
from some information being passed in [the document id would probably work,
but I don't know if that is passed]). One potential issue is I wouldn't want
couchapp attachments encrypted (e.g. html/png/etc), just my "documents'"
attachments.

The last feel most clean to me.  It allows me to ensure all document
attachments are always encrypted, which is one of my requirements, without
altering how clients interact with the system.

The middle is probably "next best" because it keeps my architecture simpler.
 Of course, then I need to balance CPU versus disk usage to keep scaling
correctly. Given that, part of me is saying "do that" because it is less
tightly coupled.

The first is by far my least preferable, because it involves adding an
additional infrastructure piece, unless the encryption kills my CPU
performance too much, at which point it probably becomes the most
preferable.

tj

On 13 Apr 2011, at 18:36, Travis Jensen wrote:
>
> > If I wanted to encrypt all attachments, where would I go about hooking
> > in to couch? I'm guessing I would have to replace the current
> > attachment handler, right?
> >
> > I haven't started digging on this; I thought it might be useful to get
> > some feedback first.
> >
> > Thanks
> >
> > Tj
> >
> > -
> > Travis Jensen
>
>


-- 
*Travis Jensen*
***
*Read the Software Maven @ http://softwaremaven.innerbrane.com/
Read my LinkedIn profile @ http://www.linkedin.com/in/travisjensen
Read my Twitter mumblings @ http://twitter.com/SoftwareMaven
Send me email @ travis.jensen@gmail.com

**What kind of guy calls himself the Software Maven???**

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message