dhis2-devs-core team mailing list archive

[Lars Helge Øverland <larshelge@xxxxxxxxx>]

>
>
>  When it comes to encryption, do we then encrypt all attribute values?
>> Will be hard to know which of the dynamic attributes that are
>> privacy-related, e.g. name, address etc.
>>
>> Or do we include another property on the attribute to define whether it
>> should be encrypted or not?
>>
>
> Hm. Great point. The problem is that encryption must happen per-column,
> not per-row. So if we are to encrypt some attributes and not others, we
> need to split into two tables.
>
> I can now also see that Jasypt <http://www.jasypt.org/hibernate.html> (the
> lib we plan to use for encryption) is not as transparent as we hoped:
>
> "But encryption sets a limitation on your Hibernate usage: security
> standards establish that two different encryption operations on the same
> data should not return the same value (due to the use of a random salt).
> Because of this, none of the fields that are set to be encrypted when
> persisted can be a part of a WHERE clause in your search queries for the
> entity they belong to."
>
> So it seems we must think closer here.
>

So it seems that one can query on encrypted fields if one uses a fixed salt
generator, ie. a salt generator that returns a consistent salt based in the
input:

http://www.jasypt.org/api/jasypt/1.8/org/jasypt/salt/FixedStringSaltGenerator.html

I am sure this reduces the strength of the encryption, however this is a
trade-off since and we need to make it possible to search for persons on
attributes/values or tracker will be a bit useless. We need to investigate
this but for now lets assume that queries will be possible.

So I suggest we start on the mentioned model changes (fixed->dynamic
attributes) since this is something that we must do in any case and it
gives us some more time to sketch out the details.