Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
Received-SPF: softfail (nike.apache.org: transitioning domain of
 marc@accumulo.net does not designate 209.85.214.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <-2815292072066478180@unknownmsgid>
References: 
 <CAGj+Ysfsi0nu2gPViW4JNJKP8hYTvDgD24Y=1twhvNo9gv9F5w@mail.gmail.com>
	<CALwRz8M8cGm4Zpp0fncpAT=zGD7hiJ_ogA1HRPdzu4C0T995=A@mail.gmail.com>
	<CALwRz8Nj8CQE57Q9-9mDAPz7jcvOghgYOA1YeObZ5Y0a=xSLgA@mail.gmail.com>
	<-8697122106434958553@unknownmsgid>
	<CALwRz8NUeUGh==A-ab0+fRbdV+2yRTejSzk6o_mN5jj1jUGnUg@mail.gmail.com>
	<CAGj+YseX2SQ7s5AeGVVyc6Lw1-MGb8ww=+RDmsvO=BL5t_KYPg@mail.gmail.com>
	<CALwRz8MawBvkZiR8m6JUFfZpn7RN6ztVDuDhOQRcOR3GFabPXw@mail.gmail.com>
	<-2815292072066478180@unknownmsgid>
Date: Wed, 1 Aug 2012 08:00:31 -0400
Message-ID: 
 <CALwRz8MkuNBvCspcvKu8P2zz4rCRSFVrnJw9xKYf+AibkeMd+Q@mail.gmail.com>
Subject: Re: CryptDB - FYI - it might be inspirational for Accumulo encryption
 architecture
From: Marc Parisi <marc@accumulo.net>
To: dev@accumulo.apache.org
Content-Type: multipart/alternative; boundary=14dae9399071af2fe504c6330a2e

--14dae9399071af2fe504c6330a2e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 <klucar@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 <marc@accumulo.net> wrote:
>
> > The link to the code is:  https://github.com/phrocker/OhCryptorMyCrypto=
r
> >
> > 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. Unlik=
e
> > 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 a=
nd
> > keys at the iterator stack, meaning you could retrieve decrypted data a=
t
> > 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 <ebegoli@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 <marc@accumulo.net> wrote=
:
> >>> k. as I designed it, a group. I had a decrypting iterator and a clien=
t
> 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 <klucar@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 <marc@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 <marc@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 <ebegoli@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 con=EF=AC=81dentiality 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 ef=EF=AC=81cient SQL-aw=
are
> >>>>>>> encryption schemes. CryptDB can also chain encryption keys to use=
r
> >>>>>>> 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 resul=
t,
> >>>>>>> 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 stor=
e)
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Edmon
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>
>

--14dae9399071af2fe504c6330a2e--