> > > 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!
