Encrypting attachments

[Travis Jensen <tr...@gmail.com>]

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

Re: Encrypting attachments

[Michael Zedeler <mi...@zedeler.dk>]

On 2011-04-12 21:51, Travis Jensen wrote:
> On Apr 12, 2011, at 11:41 AM, Benoit Chesneau<bc...@gmail.com>  wrote:
>> On Tue, Apr 12, 2011 at 7:33 PM, Travis Jensen<tr...@gmail.com>  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.
>> for better security I would encode them at the client level so the
>> server isn't aware of the decryption key or anything.
> While I totally agree with you, it isn't really practical for
> web-based applications.
What is the gain of having encrypted attachments if the key is available 
on the server?

Michael.

Re: Encrypting attachments

[Travis Jensen <tr...@gmail.com>]

On Wed, Apr 13, 2011 at 11:50 AM, Noah Slater <ns...@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???**

Re: Encrypting attachments

[Noah Slater <ns...@apache.org>]

Where would the encryption key be held?

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?

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

Encrypting attachments

[Travis Jensen <tr...@gmail.com>]

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

Re: Encrypting attachments

[Travis Jensen <tr...@gmail.com>]

My hope is to keep it self contained inside Couch. I am already
extending the auth to handle custom authentication, so I'm not afraid
to get into the code. :)

JS encryption won't work because you can't get access to files getting
posted.  If I could do that, I certainly would, but my only option
there (which I have investigated) is a plugin.

I'm not completely tied to the idea of using couch's attachments, but
it has a certain simplicity I am in favor of.

I did just realize that this is probably more applicable to the dev
list than here, though.
-
Travis Jensen

On Apr 12, 2011, at 2:03 PM, Ryan Ramage <ry...@gmail.com> wrote:

> I think Benoit is talking about a middle layer. Like node.js or an app server.
>
> If you are doing a thin couchapp style, then yes it's harder. You
> could use a javascript encryption lib on the client.
>
> Although, I could see value of having it handled as a "couch plugin"
> to the attachment system.
>
>
> On Tue, Apr 12, 2011 at 1:51 PM, Travis Jensen <tr...@gmail.com> wrote:
>> On Apr 12, 2011, at 11:41 AM, Benoit Chesneau <bc...@gmail.com> wrote:
>>
>>> On Tue, Apr 12, 2011 at 7:33 PM, Travis Jensen <tr...@gmail.com> 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
>>>>
>>>
>>> for better security I would encode them at the client level so the
>>> server isn't aware of the decryption key or anything.
>>>
>>> - benoît
>>
>> While I totally agree with you, it isn't really practical for
>> web-based applications.
>>
>> Tj
>>
>> -
>> Travis Jensen
>>

Re: Encrypting attachments

[Ryan Ramage <ry...@gmail.com>]

I think Benoit is talking about a middle layer. Like node.js or an app server.

If you are doing a thin couchapp style, then yes it's harder. You
could use a javascript encryption lib on the client.

Although, I could see value of having it handled as a "couch plugin"
to the attachment system.


On Tue, Apr 12, 2011 at 1:51 PM, Travis Jensen <tr...@gmail.com> wrote:
> On Apr 12, 2011, at 11:41 AM, Benoit Chesneau <bc...@gmail.com> wrote:
>
>> On Tue, Apr 12, 2011 at 7:33 PM, Travis Jensen <tr...@gmail.com> 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
>>>
>>
>> for better security I would encode them at the client level so the
>> server isn't aware of the decryption key or anything.
>>
>> - benoît
>
> While I totally agree with you, it isn't really practical for
> web-based applications.
>
> Tj
>
> -
> Travis Jensen
>

Re: Encrypting attachments

[Benoit Chesneau <bc...@gmail.com>]

On Tuesday, April 12, 2011, Travis Jensen <tr...@gmail.com> wrote:
> On Apr 12, 2011, at 11:41 AM, Benoit Chesneau <bc...@gmail.com> wrote:
>
>> On Tue, Apr 12, 2011 at 7:33 PM, Travis Jensen <tr...@gmail.com> 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
>>>
>>
>> for better security I would encode them at the client level so the
>> server isn't aware of the decryption key or anything.
>>
>> - benoît
>
> While I totally agree with you, it isn't really practical for
> web-based applications.
>
> Tj
>
> -
> Travis Jensen
>


Yo can imagine to have private gateway from where mobile and web
clents can access, so the server knows nothing about the encryltion
and you cgan replicate it safely, the gateway will only need to point
the current online storage. Something done by tahoe-lafs for ex.


-benoit

Re: Encrypting attachments

[Travis Jensen <tr...@gmail.com>]

On Apr 12, 2011, at 11:41 AM, Benoit Chesneau <bc...@gmail.com> wrote:

> On Tue, Apr 12, 2011 at 7:33 PM, Travis Jensen <tr...@gmail.com> 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
>>
>
> for better security I would encode them at the client level so the
> server isn't aware of the decryption key or anything.
>
> - benoît

While I totally agree with you, it isn't really practical for
web-based applications.

Tj

-
Travis Jensen

Re: Encrypting attachments

[Benoit Chesneau <bc...@gmail.com>]

On Tue, Apr 12, 2011 at 7:33 PM, Travis Jensen <tr...@gmail.com> 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
>

for better security I would encode them at the client level so the
server isn't aware of the decryption key or anything.

- benoît