Comment:apurtell:11/11/13 08:52:33 PM:

assigned

Comment:apurtell:11/11/13 08:52:34 PM:

Sounds interesting @jamestaylor . Let me take it. Any thoughts on how?

Comment:jamestaylor:11/11/13 08:52:34 PM:

mentioned

Comment:jamestaylor:11/12/13 04:44:24 AM:

@apurtell - I'm waiting for your next blog to answer that

Would it work if at DDL time, one or more properties were specified to define encryption? Properties can be defined both at the table level and the column family level, see [here](http://forcedotcom.github.io/phoenix/_create) for a few examples.

Any thoughts on how this might interact with -296? Worse-case, if a tenant wants the ability to do encryption, they'd have to have their own physical table. We might be able to have tenant-specific column families, but I think we'd hit a wall in scaling going that route.

Comment:apurtell:11/12/13 04:44:24 AM:

mentioned

Comment:apurtell:11/14/13 01:31:13 AM:

> Any thoughts on how this might interact with -296?

You mentioned HBASE-7544. This feature provides transparent server side encryption, which protects data after persistence from accidental exposure due to incorrect HDFS level permissions or improper storage volume handling. There is nothing specific a tenant will need to do to access their data even if all are backed by a single shared table. Surfacing this feature might not need more than properties support for CREATE and ALTER.

Where things can get interesting is if Phoenix wants to also or instead encrypt values in the driver to protect data during transmission or prevent leakage from one user to another. That would be a distinct capability. I filed HBASE-9578(https://issues.apache.org/jira/browse/HBASE-9578) to consider that for the HBase API, but for Phoenix it could and maybe should be handled in the JDBC driver, or possibly the HBase types library if we want to do clever type specific things in a place outside the scope of the Phoenix code base. For some background on that, see the [first comment](https://issues.apache.org/jira/browse/HBASE-9578?focusedCommentId=13771415&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel_comment-13771415) on HBASE-9578. We could consider how the design described in the CSAIL paper can be applied to Phoenix.

Comment:jamestaylor:11/14/13 06:36:17 AM:

My thought with encryption for multi-tenant tables was that different tenants might have different keys for their set of data. If the model is rather that the one "hoster" holds the one single key for the entire table, then I agree there's probably very little we'd need to do to take advantage of this feature.

Right now, the Phoenix driver is an embedded driver, so there's no additional transmission beyond the HBase client to HBase sever communication.

Comment:apurtell:11/14/13 05:12:18 PM:

I think table/column property support for toggling HBASE-7544 on CFs would be nice and would fully support that feature.

> Right now, the Phoenix driver is an embedded driver, so there's no additional transmission beyond the HBase client to HBase sever communication.

Right, I meant from the HBase client to server, but we can handle that already today by negotiating auth-conf level protection with SASL.

I think most who ask for client side encryption want the additional assurance against leakage of data from one user to an unauthorized one if access control fails or is set up incorrectly. If this becomes a goal of Phoenix, then I recommend looking at HBASE-9578 and skimming the paper mentioned there to get a sense of the potential issues.