CryptDB - FYI - it might be inspirational for Accumulo encryption architecture

[Edmon Begoli <eb...@gmail.com>]

You all might be aware of this, so please excuse the redundant information:

CryptDB
http://css.csail.mit.edu/cryptdb/

CryptDB is a system that provides practical
and provable confidentiality in the face of these attacks for
applications backed by SQL databases. It works by executing SQL
queries
over encrypted data using a collection of efficient SQL-aware
encryption schemes. CryptDB can also chain encryption keys to user
passwords, so that a data item can be decrypted only by using the
password of one of the users with access to that data. As a result,
a database administrator never gets access to decrypted data, and even
if all servers are compromised, an adversary cannot decrypt
the data of any user who is not logged in

CryptDB is MySQL based system, but I think that some of its mechanisms
could be relevant for key-value stores.
(In my work/research, I was looking for HIPAA compliant data store)

Regards,
Edmon

Re: CryptDB - FYI - it might be inspirational for Accumulo encryption architecture

[Marc Parisi <ma...@accumulo.net>]

Most certainly to the scan time iterator do the decryption. In fact, I've
done it, but only moved away from it to avoid the thrift RPC calls to be
sent in the clear.

Right now the iterator() method returns no exceptions, and instead returns
null. This behavior should be changed to show decryption failure; however,
I'm of the belief that we should still return data upon a failure. If one
cell fails, there's no reason to fail the other key/value entries.

On Tue, Jul 31, 2012 at 11:08 PM, Jim Klucar <kl...@gmail.com> wrote:

> Marc
>
> Thanks for posting this, I'll give it a look more thoroughly in the
> morning. From your description it sounds like one could write a scan
> time iterator to have the tablet servers decrypt the data for you. Is
> there anything in the decrypt process that lets you know if it was
> successful or not?
>
> Sent from my iPhone
>
> On Jul 31, 2012, at 9:15 PM, Marc Parisi <ma...@accumulo.net> wrote:
>
> > The link to the code is:  https://github.com/phrocker/OhCryptorMyCryptor
> >
> > This is a singular proof of concept. I have another with a decrypting
> > iterator and one that is more advanced that takes visibilities into
> > question. As it is here, all keys are visible to the main user. It was
> > simply a proof of concept that was hacked together quickly months ago ( I
> > only encrypt value, not key ), definitely not production quality. Unlike
> > creating an HDFS interconnect for at rest encryption, this approach
> > minimizes the raw data surface. That is, only the client actually uses
> the
> > secret key to decrypt the data. My other approach opened up the value and
> > keys at the iterator stack, meaning you could retrieve decrypted data at
> > the tablet servers from system memory.
> >
> > I ripped this code out of a large project I have on one machine ( hence
> why
> > I have no project ). I haven't cleaned it up, but I made sure it
> compiles.
> > I tested the CryptoTest class. It works.
> >
> > As I said earlier, a metakey is used to store the encrypted symmetric
> key.
> > this can be used to share encrypted data. Therefore, if you're building
> > a healthcare system ( for example ), and you want to share patient data
> > across doctor's offices, you could..and without duplicating the data.
> >
> > I doubt the code will be helpful, but if it is, more power to you.
> >
> > On Tue, Jul 31, 2012 at 10:04 AM, Edmon Begoli <eb...@gmail.com>
> wrote:
> >
> >> Looking forward to see it.
> >>
> >> Encrypting keys or not could be an interesting design tradeoff, as
> >> key, if based on some natural fact, might be a good candidate for
> >> encryption too ...
> >>
> >> On Tue, Jul 31, 2012 at 7:49 AM, Marc Parisi <ma...@accumulo.net> wrote:
> >>> k. as I designed it, a group. I had a decrypting iterator and a client
> to
> >>> do the scan. The symmetric keys decrypted groups of key/value pairs (
> >>> though ideally we wouldn't encrypt keys, only values, to maintain
> >> sorting ).
> >>> multiple asymmetric keys can be used to decode one or more symmetric
> >> keys.
> >>>
> >>> my proof of concept was very simple, but could be extended. I'll have
> to
> >>> look further, tonight.
> >>>
> >>>
> >>>
> >>> On Tue, Jul 31, 2012 at 7:39 AM, Jim Klucar <kl...@gmail.com> wrote:
> >>>
> >>>> Post a link here to the list too please. I'm sure others might be
> >>>> interested. Does the key scheme allow a group of keys to decrypt the
> >>>> data or only a single key?
> >>>>
> >>>> Sent from my iPhone
> >>>>
> >>>> On Jul 31, 2012, at 7:37 AM, Marc Parisi <ma...@accumulo.net> wrote:
> >>>>
> >>>>> I'll look for the code on my laptops and try and post it to my
> >> personal
> >>>>> github, and E-mail you directly, if you like.
> >>>>>
> >>>>> On Tue, Jul 31, 2012 at 7:35 AM, Marc Parisi <ma...@accumulo.net>
> >> wrote:
> >>>>>
> >>>>>> I have code, which I can share, to
> >>>>>>  use a symmetric key to encrypt data in cells
> >>>>>>  use a sharable public key to encrypt/decrypt the symmetric keys, so
> >>>>>> that data can be shared.
> >>>>>>
> >>>>>>
> >>>>>> You can use the visibilities to ensure users don't get other users'
> >>>> data,
> >>>>>> if you like. Data is encrypted at rest, and with a client, in
> >> transit.
> >>>>>>
> >>>>>> On Sat, Jul 28, 2012 at 4:29 PM, Edmon Begoli <eb...@gmail.com>
> >>>> wrote:
> >>>>>>
> >>>>>>> You all might be aware of this, so please excuse the redundant
> >>>>>>> information:
> >>>>>>>
> >>>>>>> CryptDB
> >>>>>>> http://css.csail.mit.edu/cryptdb/
> >>>>>>>
> >>>>>>> CryptDB is a system that provides practical
> >>>>>>> and provable confidentiality in the face of these attacks for
> >>>>>>> applications backed by SQL databases. It works by executing SQL
> >>>>>>> queries
> >>>>>>> over encrypted data using a collection of efficient SQL-aware
> >>>>>>> encryption schemes. CryptDB can also chain encryption keys to user
> >>>>>>> passwords, so that a data item can be decrypted only by using the
> >>>>>>> password of one of the users with access to that data. As a result,
> >>>>>>> a database administrator never gets access to decrypted data, and
> >> even
> >>>>>>> if all servers are compromised, an adversary cannot decrypt
> >>>>>>> the data of any user who is not logged in
> >>>>>>>
> >>>>>>> CryptDB is MySQL based system, but I think that some of its
> >> mechanisms
> >>>>>>> could be relevant for key-value stores.
> >>>>>>> (In my work/research, I was looking for HIPAA compliant data store)
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Edmon
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>
>

Re: CryptDB - FYI - it might be inspirational for Accumulo encryption architecture

[Jim Klucar <kl...@gmail.com>]

Marc

Thanks for posting this, I'll give it a look more thoroughly in the
morning. From your description it sounds like one could write a scan
time iterator to have the tablet servers decrypt the data for you. Is
there anything in the decrypt process that lets you know if it was
successful or not?

Sent from my iPhone

On Jul 31, 2012, at 9:15 PM, Marc Parisi <ma...@accumulo.net> wrote:

> The link to the code is:  https://github.com/phrocker/OhCryptorMyCryptor
>
> This is a singular proof of concept. I have another with a decrypting
> iterator and one that is more advanced that takes visibilities into
> question. As it is here, all keys are visible to the main user. It was
> simply a proof of concept that was hacked together quickly months ago ( I
> only encrypt value, not key ), definitely not production quality. Unlike
> creating an HDFS interconnect for at rest encryption, this approach
> minimizes the raw data surface. That is, only the client actually uses the
> secret key to decrypt the data. My other approach opened up the value and
> keys at the iterator stack, meaning you could retrieve decrypted data at
> the tablet servers from system memory.
>
> I ripped this code out of a large project I have on one machine ( hence why
> I have no project ). I haven't cleaned it up, but I made sure it compiles.
> I tested the CryptoTest class. It works.
>
> As I said earlier, a metakey is used to store the encrypted symmetric key.
> this can be used to share encrypted data. Therefore, if you're building
> a healthcare system ( for example ), and you want to share patient data
> across doctor's offices, you could..and without duplicating the data.
>
> I doubt the code will be helpful, but if it is, more power to you.
>
> On Tue, Jul 31, 2012 at 10:04 AM, Edmon Begoli <eb...@gmail.com> wrote:
>
>> Looking forward to see it.
>>
>> Encrypting keys or not could be an interesting design tradeoff, as
>> key, if based on some natural fact, might be a good candidate for
>> encryption too ...
>>
>> On Tue, Jul 31, 2012 at 7:49 AM, Marc Parisi <ma...@accumulo.net> wrote:
>>> k. as I designed it, a group. I had a decrypting iterator and a client to
>>> do the scan. The symmetric keys decrypted groups of key/value pairs (
>>> though ideally we wouldn't encrypt keys, only values, to maintain
>> sorting ).
>>> multiple asymmetric keys can be used to decode one or more symmetric
>> keys.
>>>
>>> my proof of concept was very simple, but could be extended. I'll have to
>>> look further, tonight.
>>>
>>>
>>>
>>> On Tue, Jul 31, 2012 at 7:39 AM, Jim Klucar <kl...@gmail.com> wrote:
>>>
>>>> Post a link here to the list too please. I'm sure others might be
>>>> interested. Does the key scheme allow a group of keys to decrypt the
>>>> data or only a single key?
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On Jul 31, 2012, at 7:37 AM, Marc Parisi <ma...@accumulo.net> wrote:
>>>>
>>>>> I'll look for the code on my laptops and try and post it to my
>> personal
>>>>> github, and E-mail you directly, if you like.
>>>>>
>>>>> On Tue, Jul 31, 2012 at 7:35 AM, Marc Parisi <ma...@accumulo.net>
>> wrote:
>>>>>
>>>>>> I have code, which I can share, to
>>>>>>  use a symmetric key to encrypt data in cells
>>>>>>  use a sharable public key to encrypt/decrypt the symmetric keys, so
>>>>>> that data can be shared.
>>>>>>
>>>>>>
>>>>>> You can use the visibilities to ensure users don't get other users'
>>>> data,
>>>>>> if you like. Data is encrypted at rest, and with a client, in
>> transit.
>>>>>>
>>>>>> On Sat, Jul 28, 2012 at 4:29 PM, Edmon Begoli <eb...@gmail.com>
>>>> wrote:
>>>>>>
>>>>>>> You all might be aware of this, so please excuse the redundant
>>>>>>> information:
>>>>>>>
>>>>>>> CryptDB
>>>>>>> http://css.csail.mit.edu/cryptdb/
>>>>>>>
>>>>>>> CryptDB is a system that provides practical
>>>>>>> and provable confidentiality in the face of these attacks for
>>>>>>> applications backed by SQL databases. It works by executing SQL
>>>>>>> queries
>>>>>>> over encrypted data using a collection of efficient SQL-aware
>>>>>>> encryption schemes. CryptDB can also chain encryption keys to user
>>>>>>> passwords, so that a data item can be decrypted only by using the
>>>>>>> password of one of the users with access to that data. As a result,
>>>>>>> a database administrator never gets access to decrypted data, and
>> even
>>>>>>> if all servers are compromised, an adversary cannot decrypt
>>>>>>> the data of any user who is not logged in
>>>>>>>
>>>>>>> CryptDB is MySQL based system, but I think that some of its
>> mechanisms
>>>>>>> could be relevant for key-value stores.
>>>>>>> (In my work/research, I was looking for HIPAA compliant data store)
>>>>>>>
>>>>>>> Regards,
>>>>>>> Edmon
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>

Re: CryptDB - FYI - it might be inspirational for Accumulo encryption architecture

[Marc Parisi <ma...@accumulo.net>]

The link to the code is:  https://github.com/phrocker/OhCryptorMyCryptor

This is a singular proof of concept. I have another with a decrypting
iterator and one that is more advanced that takes visibilities into
question. As it is here, all keys are visible to the main user. It was
simply a proof of concept that was hacked together quickly months ago ( I
only encrypt value, not key ), definitely not production quality. Unlike
creating an HDFS interconnect for at rest encryption, this approach
minimizes the raw data surface. That is, only the client actually uses the
secret key to decrypt the data. My other approach opened up the value and
keys at the iterator stack, meaning you could retrieve decrypted data at
the tablet servers from system memory.

I ripped this code out of a large project I have on one machine ( hence why
I have no project ). I haven't cleaned it up, but I made sure it compiles.
I tested the CryptoTest class. It works.

As I said earlier, a metakey is used to store the encrypted symmetric key.
this can be used to share encrypted data. Therefore, if you're building
a healthcare system ( for example ), and you want to share patient data
across doctor's offices, you could..and without duplicating the data.

I doubt the code will be helpful, but if it is, more power to you.

On Tue, Jul 31, 2012 at 10:04 AM, Edmon Begoli <eb...@gmail.com> wrote:

> Looking forward to see it.
>
> Encrypting keys or not could be an interesting design tradeoff, as
> key, if based on some natural fact, might be a good candidate for
> encryption too ...
>
> On Tue, Jul 31, 2012 at 7:49 AM, Marc Parisi <ma...@accumulo.net> wrote:
> > k. as I designed it, a group. I had a decrypting iterator and a client to
> > do the scan. The symmetric keys decrypted groups of key/value pairs (
> > though ideally we wouldn't encrypt keys, only values, to maintain
> sorting ).
> > multiple asymmetric keys can be used to decode one or more symmetric
> keys.
> >
> > my proof of concept was very simple, but could be extended. I'll have to
> > look further, tonight.
> >
> >
> >
> > On Tue, Jul 31, 2012 at 7:39 AM, Jim Klucar <kl...@gmail.com> wrote:
> >
> >> Post a link here to the list too please. I'm sure others might be
> >> interested. Does the key scheme allow a group of keys to decrypt the
> >> data or only a single key?
> >>
> >> Sent from my iPhone
> >>
> >> On Jul 31, 2012, at 7:37 AM, Marc Parisi <ma...@accumulo.net> wrote:
> >>
> >> > I'll look for the code on my laptops and try and post it to my
> personal
> >> > github, and E-mail you directly, if you like.
> >> >
> >> > On Tue, Jul 31, 2012 at 7:35 AM, Marc Parisi <ma...@accumulo.net>
> wrote:
> >> >
> >> >> I have code, which I can share, to
> >> >>   use a symmetric key to encrypt data in cells
> >> >>   use a sharable public key to encrypt/decrypt the symmetric keys, so
> >> >> that data can be shared.
> >> >>
> >> >>
> >> >> You can use the visibilities to ensure users don't get other users'
> >> data,
> >> >> if you like. Data is encrypted at rest, and with a client, in
> transit.
> >> >>
> >> >> On Sat, Jul 28, 2012 at 4:29 PM, Edmon Begoli <eb...@gmail.com>
> >> wrote:
> >> >>
> >> >>> You all might be aware of this, so please excuse the redundant
> >> >>> information:
> >> >>>
> >> >>> CryptDB
> >> >>> http://css.csail.mit.edu/cryptdb/
> >> >>>
> >> >>> CryptDB is a system that provides practical
> >> >>> and provable confidentiality in the face of these attacks for
> >> >>> applications backed by SQL databases. It works by executing SQL
> >> >>> queries
> >> >>> over encrypted data using a collection of efficient SQL-aware
> >> >>> encryption schemes. CryptDB can also chain encryption keys to user
> >> >>> passwords, so that a data item can be decrypted only by using the
> >> >>> password of one of the users with access to that data. As a result,
> >> >>> a database administrator never gets access to decrypted data, and
> even
> >> >>> if all servers are compromised, an adversary cannot decrypt
> >> >>> the data of any user who is not logged in
> >> >>>
> >> >>> CryptDB is MySQL based system, but I think that some of its
> mechanisms
> >> >>> could be relevant for key-value stores.
> >> >>> (In my work/research, I was looking for HIPAA compliant data store)
> >> >>>
> >> >>> Regards,
> >> >>> Edmon
> >> >>>
> >> >>
> >> >>
> >>
>

Re: CryptDB - FYI - it might be inspirational for Accumulo encryption architecture

[Edmon Begoli <eb...@gmail.com>]

Looking forward to see it.

Encrypting keys or not could be an interesting design tradeoff, as
key, if based on some natural fact, might be a good candidate for
encryption too ...

On Tue, Jul 31, 2012 at 7:49 AM, Marc Parisi <ma...@accumulo.net> wrote:
> k. as I designed it, a group. I had a decrypting iterator and a client to
> do the scan. The symmetric keys decrypted groups of key/value pairs (
> though ideally we wouldn't encrypt keys, only values, to maintain sorting ).
> multiple asymmetric keys can be used to decode one or more symmetric keys.
>
> my proof of concept was very simple, but could be extended. I'll have to
> look further, tonight.
>
>
>
> On Tue, Jul 31, 2012 at 7:39 AM, Jim Klucar <kl...@gmail.com> wrote:
>
>> Post a link here to the list too please. I'm sure others might be
>> interested. Does the key scheme allow a group of keys to decrypt the
>> data or only a single key?
>>
>> Sent from my iPhone
>>
>> On Jul 31, 2012, at 7:37 AM, Marc Parisi <ma...@accumulo.net> wrote:
>>
>> > I'll look for the code on my laptops and try and post it to my personal
>> > github, and E-mail you directly, if you like.
>> >
>> > On Tue, Jul 31, 2012 at 7:35 AM, Marc Parisi <ma...@accumulo.net> wrote:
>> >
>> >> I have code, which I can share, to
>> >>   use a symmetric key to encrypt data in cells
>> >>   use a sharable public key to encrypt/decrypt the symmetric keys, so
>> >> that data can be shared.
>> >>
>> >>
>> >> You can use the visibilities to ensure users don't get other users'
>> data,
>> >> if you like. Data is encrypted at rest, and with a client, in transit.
>> >>
>> >> On Sat, Jul 28, 2012 at 4:29 PM, Edmon Begoli <eb...@gmail.com>
>> wrote:
>> >>
>> >>> You all might be aware of this, so please excuse the redundant
>> >>> information:
>> >>>
>> >>> CryptDB
>> >>> http://css.csail.mit.edu/cryptdb/
>> >>>
>> >>> CryptDB is a system that provides practical
>> >>> and provable confidentiality in the face of these attacks for
>> >>> applications backed by SQL databases. It works by executing SQL
>> >>> queries
>> >>> over encrypted data using a collection of efficient SQL-aware
>> >>> encryption schemes. CryptDB can also chain encryption keys to user
>> >>> passwords, so that a data item can be decrypted only by using the
>> >>> password of one of the users with access to that data. As a result,
>> >>> a database administrator never gets access to decrypted data, and even
>> >>> if all servers are compromised, an adversary cannot decrypt
>> >>> the data of any user who is not logged in
>> >>>
>> >>> CryptDB is MySQL based system, but I think that some of its mechanisms
>> >>> could be relevant for key-value stores.
>> >>> (In my work/research, I was looking for HIPAA compliant data store)
>> >>>
>> >>> Regards,
>> >>> Edmon
>> >>>
>> >>
>> >>
>>

Re: CryptDB - FYI - it might be inspirational for Accumulo encryption architecture

[Marc Parisi <ma...@accumulo.net>]

k. as I designed it, a group. I had a decrypting iterator and a client to
do the scan. The symmetric keys decrypted groups of key/value pairs (
though ideally we wouldn't encrypt keys, only values, to maintain sorting ).
multiple asymmetric keys can be used to decode one or more symmetric keys.

my proof of concept was very simple, but could be extended. I'll have to
look further, tonight.



On Tue, Jul 31, 2012 at 7:39 AM, Jim Klucar <kl...@gmail.com> wrote:

> Post a link here to the list too please. I'm sure others might be
> interested. Does the key scheme allow a group of keys to decrypt the
> data or only a single key?
>
> Sent from my iPhone
>
> On Jul 31, 2012, at 7:37 AM, Marc Parisi <ma...@accumulo.net> wrote:
>
> > I'll look for the code on my laptops and try and post it to my personal
> > github, and E-mail you directly, if you like.
> >
> > On Tue, Jul 31, 2012 at 7:35 AM, Marc Parisi <ma...@accumulo.net> wrote:
> >
> >> I have code, which I can share, to
> >>   use a symmetric key to encrypt data in cells
> >>   use a sharable public key to encrypt/decrypt the symmetric keys, so
> >> that data can be shared.
> >>
> >>
> >> You can use the visibilities to ensure users don't get other users'
> data,
> >> if you like. Data is encrypted at rest, and with a client, in transit.
> >>
> >> On Sat, Jul 28, 2012 at 4:29 PM, Edmon Begoli <eb...@gmail.com>
> wrote:
> >>
> >>> You all might be aware of this, so please excuse the redundant
> >>> information:
> >>>
> >>> CryptDB
> >>> http://css.csail.mit.edu/cryptdb/
> >>>
> >>> CryptDB is a system that provides practical
> >>> and provable confidentiality in the face of these attacks for
> >>> applications backed by SQL databases. It works by executing SQL
> >>> queries
> >>> over encrypted data using a collection of efficient SQL-aware
> >>> encryption schemes. CryptDB can also chain encryption keys to user
> >>> passwords, so that a data item can be decrypted only by using the
> >>> password of one of the users with access to that data. As a result,
> >>> a database administrator never gets access to decrypted data, and even
> >>> if all servers are compromised, an adversary cannot decrypt
> >>> the data of any user who is not logged in
> >>>
> >>> CryptDB is MySQL based system, but I think that some of its mechanisms
> >>> could be relevant for key-value stores.
> >>> (In my work/research, I was looking for HIPAA compliant data store)
> >>>
> >>> Regards,
> >>> Edmon
> >>>
> >>
> >>
>

Re: CryptDB - FYI - it might be inspirational for Accumulo encryption architecture

[Jim Klucar <kl...@gmail.com>]

Post a link here to the list too please. I'm sure others might be
interested. Does the key scheme allow a group of keys to decrypt the
data or only a single key?

Sent from my iPhone

On Jul 31, 2012, at 7:37 AM, Marc Parisi <ma...@accumulo.net> wrote:

> I'll look for the code on my laptops and try and post it to my personal
> github, and E-mail you directly, if you like.
>
> On Tue, Jul 31, 2012 at 7:35 AM, Marc Parisi <ma...@accumulo.net> wrote:
>
>> I have code, which I can share, to
>>   use a symmetric key to encrypt data in cells
>>   use a sharable public key to encrypt/decrypt the symmetric keys, so
>> that data can be shared.
>>
>>
>> You can use the visibilities to ensure users don't get other users' data,
>> if you like. Data is encrypted at rest, and with a client, in transit.
>>
>> On Sat, Jul 28, 2012 at 4:29 PM, Edmon Begoli <eb...@gmail.com> wrote:
>>
>>> You all might be aware of this, so please excuse the redundant
>>> information:
>>>
>>> CryptDB
>>> http://css.csail.mit.edu/cryptdb/
>>>
>>> CryptDB is a system that provides practical
>>> and provable confidentiality in the face of these attacks for
>>> applications backed by SQL databases. It works by executing SQL
>>> queries
>>> over encrypted data using a collection of efficient SQL-aware
>>> encryption schemes. CryptDB can also chain encryption keys to user
>>> passwords, so that a data item can be decrypted only by using the
>>> password of one of the users with access to that data. As a result,
>>> a database administrator never gets access to decrypted data, and even
>>> if all servers are compromised, an adversary cannot decrypt
>>> the data of any user who is not logged in
>>>
>>> CryptDB is MySQL based system, but I think that some of its mechanisms
>>> could be relevant for key-value stores.
>>> (In my work/research, I was looking for HIPAA compliant data store)
>>>
>>> Regards,
>>> Edmon
>>>
>>
>>

Re: CryptDB - FYI - it might be inspirational for Accumulo encryption architecture

[Marc Parisi <ma...@accumulo.net>]

I'll look for the code on my laptops and try and post it to my personal
github, and E-mail you directly, if you like.

On Tue, Jul 31, 2012 at 7:35 AM, Marc Parisi <ma...@accumulo.net> wrote:

> I have code, which I can share, to
>    use a symmetric key to encrypt data in cells
>    use a sharable public key to encrypt/decrypt the symmetric keys, so
> that data can be shared.
>
>
> You can use the visibilities to ensure users don't get other users' data,
> if you like. Data is encrypted at rest, and with a client, in transit.
>
> On Sat, Jul 28, 2012 at 4:29 PM, Edmon Begoli <eb...@gmail.com> wrote:
>
>> You all might be aware of this, so please excuse the redundant
>> information:
>>
>> CryptDB
>> http://css.csail.mit.edu/cryptdb/
>>
>> CryptDB is a system that provides practical
>> and provable confidentiality in the face of these attacks for
>> applications backed by SQL databases. It works by executing SQL
>> queries
>> over encrypted data using a collection of efficient SQL-aware
>> encryption schemes. CryptDB can also chain encryption keys to user
>> passwords, so that a data item can be decrypted only by using the
>> password of one of the users with access to that data. As a result,
>> a database administrator never gets access to decrypted data, and even
>> if all servers are compromised, an adversary cannot decrypt
>> the data of any user who is not logged in
>>
>> CryptDB is MySQL based system, but I think that some of its mechanisms
>> could be relevant for key-value stores.
>> (In my work/research, I was looking for HIPAA compliant data store)
>>
>> Regards,
>> Edmon
>>
>
>

Re: CryptDB - FYI - it might be inspirational for Accumulo encryption architecture

[Marc Parisi <ma...@accumulo.net>]

I have code, which I can share, to
   use a symmetric key to encrypt data in cells
   use a sharable public key to encrypt/decrypt the symmetric keys, so that
data can be shared.


You can use the visibilities to ensure users don't get other users' data,
if you like. Data is encrypted at rest, and with a client, in transit.

On Sat, Jul 28, 2012 at 4:29 PM, Edmon Begoli <eb...@gmail.com> wrote:

> You all might be aware of this, so please excuse the redundant information:
>
> CryptDB
> http://css.csail.mit.edu/cryptdb/
>
> CryptDB is a system that provides practical
> and provable confidentiality in the face of these attacks for
> applications backed by SQL databases. It works by executing SQL
> queries
> over encrypted data using a collection of efficient SQL-aware
> encryption schemes. CryptDB can also chain encryption keys to user
> passwords, so that a data item can be decrypted only by using the
> password of one of the users with access to that data. As a result,
> a database administrator never gets access to decrypted data, and even
> if all servers are compromised, an adversary cannot decrypt
> the data of any user who is not logged in
>
> CryptDB is MySQL based system, but I think that some of its mechanisms
> could be relevant for key-value stores.
> (In my work/research, I was looking for HIPAA compliant data store)
>
> Regards,
> Edmon
>