Here is my situation : we've got ID, named TIP, from remote and large databases. We want to store all the data, but laws prevents us to store the TIP directly, but rather anonymize them, for security reasons, as these TIP are, indeed, identifying a person and their personal confidential data.
However, as we reconstruct our own databases more or less mirrorring the remote databases, we get the TIP associated with variable data. To be more explicit : the only column that is the same accross the different remote databases is the TIP.
Hence, i've got a problem : i would like to hash the TIP (with argon2 as i heard it's the way to go nowadays), but since the TIP are very low entropy (a dozen of digits), i know i should salt them.
But what to use as salt ? Using a random value sounds good, but then i would have to maintain a table that associate a TIP with its salts, which make the whole hashing process useless as this database would exists along our own, and thus be vulnerable like the others to database theft.
I should also add that i have to maintain also a separate (logically and geographically) database that allow for resending some data (a very low amount compared to what we retrieve) to the original databases, hence there is necessarily a way to uncipher the hashed TIP, but this way would rather be awfully slow, and non-automatisable (that is, a Data Protection Officer will do it himself, verifying accordance to law row by row, because accessing these data depends of institutions strategies decisions, and of the goals and roles of the peoples asking for these lines).
We intuited of some ideas, but all feels like they are roll your own type.
hashed-peppered intermediary
Instead of storing a table associating TIP to its salt, instead store a hash of the TIP (without salt, just pepper) associated to its salt.
I fear that that solution only hide the problem ; instead of a table with TIP, we have a table with hashed but not salted TIP, which is better, but not secure.
Hashing with hash-not-salted as salt
Instead of storing a table, could we use the hash-not-salted of the password as its own salt ? Hence, we can, without any more information, get a high-entropy, configurable cost, UID from a single TIP. Is that theoretically acceptable ?
Another solution we didn't think of
Maybe there is a well-known, battle-hardened, proved solution that will meet our need ?
