# Client side encryption / hashing of “person ID's” with password?

What we're looking for

A solution where data is stored and retrieved (!) from a server using a person ID that can only be known at the client (form of anonymization). Furthermore, the client should be able to calculate the original person ID back from a data record.

Storing certificates on the client is not an option, asking the user for a password is.

My original idea

PBKDF2 + AES (CCM) on the client. However, because we need to be able to retrieve records later, I had to keep the IV (and salt) constant. For what I've read, this could be a problem (but I'm not sure, especially if the person ID is always smaller than the key?).

My alternative idea

PBKDF2 + AES (CCM) on the client, now with random IV. This can now only be used for calculating the person ID from a data record. For data retrieval we would add a separate column, containing a client-calculated hash of the person ID. To prevent against an attack that hashes all valid person ID's and works back from there, I was thinking to salt with the same user supplied password as we used for encryption (since this can be expected to never leave the client).

I could really use some thoughts on this challenge (and the two ideas described above).

• The person ID only needs to be recoverable on the client, the server should not even be able to. – Jochem Jul 27 '16 at 10:16
• I'm not sure if I understand your question, so if this comment is not what you expect: sorry and feel free to rephrase! My plan is to only encrypt the person ID, the rest of the record is readable. The server (and 'we') can use this for general, anonymized analysis, and for returning specific records to the client, who can then 'recover' (ie decrypt) the original person ID to go with the records. – Jochem Jul 27 '16 at 11:22
• Ok, I seem to have misunderstood the whole idea. Now I think I get it: 1) record is stored with "encrypted" person ID; 2) the client must somehow be able to request a record by person ID without divulging it to the server; 3) when the client has some record(s), they must be able to decrypt the person ID(s). Correct? – otus Jul 27 '16 at 11:34
• Yes, that is correct! – Jochem Jul 27 '16 at 11:36

This suggests that the client should encrypt the secret person ID using e.g. AES-SIV, which requires no IV. The encryption key can be derived from a password and a constant salt (per client, rather than per record) which does not need to be secret or random (but can be for some extra protection against the server).
(Note that AES SIV used without a nonce, like any deterministic encryption, leaks the equality of person IDs (by design), so they should all be unique for this to work.)