> > > 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.
-- Mailing list: https://launchpad.net/~dhis2-devs-core Post to : [email protected] Unsubscribe : https://launchpad.net/~dhis2-devs-core More help : https://help.launchpad.net/ListHelp
