On Wed, Apr 4, 2012 at 5:49 PM, Chris Marisic <ch...@marisic.com> wrote:
> "We can have RavenDB store the data internally in an encrypted format
> quite easily. The question here is what is it that you are trying to do? "

> I want the data encrypted, without the performance cost of having full
> document encryption. Unless as I said that it's possible to make the
> performance cost of full document encryption (obviously including the
> effects indexes and searching) to be negligible when compared to file
> system encryption.

> On Wednesday, April 4, 2012 10:29:38 AM UTC-4, Oren Eini wrote:

>> Chris,
>> The major problem of handling encryption is simple, what is it that you
>> are trying to do?
>> Another aspect is key management, but we will deal with that a bit later.

>> We can have RavenDB store the data internally in an encrypted format
>> quite easily. The question here is what is it that you are trying to do?
>> Obviously RavenDB would have to have a way to decrypt them. And then the
>> question is who holds the key?
>> In this scenario, RavenHQ would have to hold the key, and anyone who
>> could gain access to the machine to examine the raw files would also very
>> likely get access to the key as well.

>> Other alternatives, like DPAPI and friends all rely on assuming that you
>> have access to the actual machine, which falls down when you realize that
>> we also need to be able to setup a new machine if the old one just died.

>> It would be the simplest thing in the world from our perspective to say
>> something like: "Oh, of course it is encrypted" by simply turning on FS
>> encryption. But that would be irresponsible to do without actually
>> considering all of these factors.

>> This is something that we put some thought about, but I won't feel
>> comfortable actually doing this without having good answers to all of those
>> problems.

>> On Wed, Apr 4, 2012 at 5:22 PM, Chris Marisic <ch...@marisic.com> wrote:

>>> This is extremely going to limit your ability to reach adoption in the
>>> business world. I suppose full document encryption would be a "work around"
>>> however I don't want to pay the price for dealing with encryption at the
>>> document level. Unless you can make it so optimized there's no noticeable
>>> difference between an encrypting file system vs document encryption.

>>> On Wednesday, April 4, 2012 10:18:17 AM UTC-4, Chris Marisic wrote:

>>>> Well this is unfortunate, this means it is impossible for me to host in
>>>> RavenHQ.

>>>> On Wednesday, April 4, 2012 4:25:38 AM UTC-4, Oren Eini wrote:

>>>>> We can't really do that, we handle backups via snapshotting the drive,
>>>>> not by actually doing the full backup.

>>>>> On Tue, Apr 3, 2012 at 6:59 PM, Chris Marisic <ch...@marisic.com>wrote:

>>>>>> If the backups are zipped using encryption before being moved to S3
>>>>>> storage that would eliminate the exposure of plain text data.

>>>>>> On Tuesday, April 3, 2012 11:41:57 AM UTC-4, Oren Eini wrote:

>>>>>>> I don't know, it would results in major complication for backups,
>>>>>>> for example.

>>>>>>> On Tue, Apr 3, 2012 at 4:21 PM, Chris Marisic <ch...@marisic.com>wrote:

>>>>>>>> Is there a time line for supporting this? I don't require the docs
>>>>>>>> themselves to be encrypted in the database, only the data to be on an
>>>>>>>> encrypting partition. Basically running BitLocker on the data directory or
>>>>>>>> entire host.

>>>>>>>> On Monday, April 2, 2012 7:50:57 PM UTC-4, Oren Eini wrote:

>>>>>>>>> Hi,
>>>>>>>>> No, the RavenHQ data is not encrypted at this time.

>>>>>>>>> On Mon, Apr 2, 2012 at 4:59 PM, Chris Marisic <ch...@marisic.com>wrote:

>>>>>>>>>> When using RavenHQ is the data stored on an encrypting file
>>>>>>>>>> system such that if someone broke into Amazon's data centers and stole hard
>>>>>>>>>> drives from the servers that my data would not be able to be compromised by
>>>>>>>>>> just directly accessing the esent storage directory?