Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: pass (athena.apache.org: domain of davidj@gmail.com designates
 209.85.210.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4E9DF019.9060603@l3s.de>
References: <4E95C17C.5000008@l3s.de>
 <CAKc7CJQ89-7dpUumed2LC1SWb4iQz=sefJrfpEFJ5EWEOusTYA@mail.gmail.com>
 <4E95C6C6.2060304@l3s.de>
 <CA+nPnMx5wEYgg0nGCYFXhbVEnjWEJ_OKuWPmUcvKMW_oorzaOQ@mail.gmail.com>
 <4E969786.7040208@l3s.de>
 <CA+nPnMzAEtArcAMB-23G3mFCOk340w4gnDY2M10RaTYNSggayg@mail.gmail.com>
 <4E97186A.5010401@l3s.de>
 <CA+nPnMx8ZVBK7Qek_eeBuQcWy34Hm2sQ7uDkpPM0DnOmhfiz1A@mail.gmail.com>
 <4E974834.2030205@l3s.de>
 <CA+nPnMz8VLyJxdijiQsa_HgSB6ozsnjNtnEok8Wr5Wk4s3RnHA@mail.gmail.com>
 <CA+CP9O6nb0=U6LZQCQsceuvxrABugewgTfYfPcC_ONvR1U4eLg@mail.gmail.com>
 <4E9BF7C0.9090107@l3s.de>
 <CA+CP9O5U2ckDLHTHfawK3e06mo05L4++szhnrBBF+GrzmwAUPg@mail.gmail.com>
 <4E9DF019.9060603@l3s.de>
From: David Jeske <davidj@gmail.com>
Date: Thu, 20 Oct 2011 17:31:28 -0700
Message-ID: 
 <CA+CP9O7_5ceoPE+7-fcgByJPXqf8y1kFmiDY9qCAM5Wai7O8CQ@mail.gmail.com>
Subject: Re: Storing pre-sorted data
To: user@cassandra.apache.org
Content-Type: multipart/alternative; boundary=20cf303ea6a4d9327f04afc43268

--20cf303ea6a4d9327f04afc43268
Content-Type: text/plain; charset=ISO-8859-1

>
>
>  2) If a single key, would adding a file/block/record-level encryption to
>> Cassandra solve this problem? If not, why not? Is there something
>> special about your encryption methods?
>>
>
> There is nothing special about our encryption methods but will never be
> able to encrypt or decrypt data on our server as the keys will always remain
> on the clients. Therefore, we would not profit from built-in cassandra
> encryption support. However, this would probably be a good feature for many
> other users.


If I understand you correctly, you are saying that you will never have the
encryption key, but that some third-party will. Given this description, the
design space you are in has nothing to do with Cassandra-per-se. Cassandra,
like any sorted-order storage, will keep data in the order of a key that it
can read. A database can't keep data sorted in an order that it unknown to
it.

I get the idea you are trying to provide "encrypted database services" to
third-parties, and that you are trying to give them sorted-order retrieval.
This is a "hard problem". The only two options I see were detailed in my
previous explanation.

1) require the client/third-party expose some non-encrypted data, which can
be used for sorting. Leave it up to them how they can generate data useful
for sorting which does not compromise security. (previously described as
option a)

2) Use some bleeding-edge research order-preserving encryption algorithm.
(Also, don't compress the sort-key.) If the encrypted form sorts in the same
order as the unencrypted form, then any database can store the encrypted key
as if it was normal data and keep the data in proper sorted-order. (some
extra work would be required for composite keys) (previously described as
option c)

I hope that helps.. Good luck!

--20cf303ea6a4d9327f04afc43268
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class=3D"im=
"><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
2) If a single key, would adding a file/block/record-level encryption to<br=
>
Cassandra solve this problem? If not, why not? Is there something<br>
special about your encryption methods?<br>
</blockquote>
<br></div>
There is nothing special about our encryption methods but will never be abl=
e to encrypt or decrypt data on our server as the keys will always remain o=
n the clients. Therefore, we would not profit from built-in cassandra encry=
ption support. However, this would probably be a good feature for many othe=
r users.</blockquote>

<div><br></div><div>If I understand you correctly, you are saying that you =
will never have the encryption key, but that some third-party will.=A0Given=
 this description, the design space you are in has nothing to do with Cassa=
ndra-per-se. Cassandra, like any sorted-order storage, will keep data in th=
e order of a key that it can read. A database can&#39;t keep data sorted in=
 an order that it unknown to it.=A0</div>

<div><br></div><div>I get the idea you are trying to provide &quot;encrypte=
d database services&quot; to third-parties, and that you are trying to give=
 them sorted-order retrieval. This is a &quot;hard problem&quot;. The only =
two options I see were detailed in my previous explanation.=A0</div>

<div><br></div><div>1) require the client/third-party expose some non-encry=
pted data, which can be used for sorting. Leave it up to them how they can =
generate data useful for sorting which does not compromise security. (previ=
ously described as option a)</div>

<div><br></div><div>2) Use some bleeding-edge research order-preserving enc=
ryption algorithm. (Also, don&#39;t compress the sort-key.) If the encrypte=
d form sorts in the same order as the unencrypted form, then any database c=
an store the encrypted key as if it was normal data and keep the data in pr=
oper sorted-order. (some extra work would be required for composite keys) (=
previously described as option c)</div>

<div><br></div><div>I hope that helps.. Good luck!=A0</div><div><br></div><=
/div>

--20cf303ea6a4d9327f04afc43268--