accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Klucar <>
Subject Re: CryptDB - FYI - it might be inspirational for Accumulo encryption architecture
Date Wed, 01 Aug 2012 03:08:36 GMT

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 <> wrote:

> The link to the code is:
> 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 <> 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 <> 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 <> 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 <> 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 <>
>> 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,
>>>>>> 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 <>
>>>> wrote:
>>>>>>> You all might be aware of this, so please excuse the redundant
>>>>>>> information:
>>>>>>> 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
>>>>>>> passwords, so that a data item can be decrypted only by using
>>>>>>> password of one of the users with access to that data. As a result,
>>>>>>> a database administrator never gets access to decrypted data,
>> 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
>>>>>>> Regards,
>>>>>>> Edmon

View raw message