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).

  • $\begingroup$ The person ID only needs to be recoverable on the client, the server should not even be able to. $\endgroup$
    – Jochem
    Jul 27, 2016 at 10:16
  • 1
    $\begingroup$ 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. $\endgroup$
    – Jochem
    Jul 27, 2016 at 11:22
  • $\begingroup$ 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? $\endgroup$
    – otus
    Jul 27, 2016 at 11:34
  • $\begingroup$ Yes, that is correct! $\endgroup$
    – Jochem
    Jul 27, 2016 at 11:36

1 Answer 1


Because of the requirement that the secret be decryptable, it has to be encrypted, rather than simply hashed. Because of the requirement that a record be retrievable by the secret, it should be encrypted deterministically, so it can be reproduced. Finally, no keys or salts can be stored by the client, complicating the matter.

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).

Possible key derivation functions include e.g. PBKDF2, bcrypt, scrypt or argon2. I would prefer the later ones, but any of them are acceptable if the password is good.

(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.)

  • $\begingroup$ an alternative to AES-SIV would be AES-GCM-SIV (if available, maybe in the future)... $\endgroup$
    – SEJPM
    Jul 27, 2016 at 11:53
  • 1
    $\begingroup$ @SEJPM, yes and some CAESAR candidates would also work. (AEZ, HS1-SIV, maybe others?) $\endgroup$
    – otus
    Jul 27, 2016 at 12:03
  • $\begingroup$ AES-SIV looks like a good candidate, I'll give that a go. Thank you otus! $\endgroup$
    – Jochem
    Jul 28, 2016 at 7:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.