[aerogear-dev] Querying encrypted data

[Erik Jan de Wit]

> When you encrypt, there is always some randomness introduced with salt and intiailization vector (IV) techniques. Two same fields if encrypted with different salt and pepper will result in different encrypted data.


Thinking a bit more about this, we could create a hashed index to query on. Data in tables will unlikely be very big and if it is very big you will not query it so hashes will be ideal. Then we parse the query run it against the hashed index and then find the still encrypted data in the database then decrypt the result set. That way you can find data that exactly matches, so no like queries and also sort by is not possible in this approach. The sorting we could still perform in memory but have no idea how to solve the like query. What do you think?

Cheers,
	Erik Jan

> ++
> Corinne 
> On Oct 15, 2013, at 10:17 AM, Erik Jan de Wit <edewit at redhat.com> wrote:
> 
>> Don't know how feasible it is, but we could query the encrypted data without decrypting. We still have tables, columns and rows and with encrypted names and values. Then we could parse the sql statement and encrypt the names and values in it and then run it against the database. The returned result is then the only thing that needs to be decrypted. How does that sound? This approach will obviously give away that data in certain columns is the same, and maybe there is more downsides to this that I don't see.
>> 
>> Cheers,
>> 	Erik Jan 
>> 
>> On 14 Oct,2013, at 21:47 , Summers Pittman <supittma at redhat.com> wrote:
>> 
>>> One of the things that came up while discussing offline secure storage 
>>> on Android was how to query encrypted data.
>>> 
>>> The first ideas that I could think of were:
>>> 
>>> 1) Load encrypted files/data/databases into memory, decrypt them, query 
>>> them, return results and GC the decrypted data.
>>> 
>>> 2) magical phonetic encryption
>>> 
>>> 3) Include queryable decrypted metadata along with encrypted payloads.  
>>> The payloads will not be queryable and only be decrypted if metadata 
>>> matches the query.
>>> 
>>> #1 has some benefits (easy to implement across platforms, doesn't 
>>> require a lot of work) and some draw backs (large datasets would eat 
>>> into available memory, whole dataset would be vulnerable to a VM attack).
>>> 
>>> #2 is a placeholder for better ideas.
>>> 
>>> #3 is interesting because it is a middle of the road approach.  One of 
>>> the options for implementation I thought of would be to annotate fields 
>>> in the VO being stored as "privledged" and they would be the only ones 
>>> encrypted/decrypted when an object is stored or loaded.
>>> 
>>> wdyt?
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> 
>> 
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev