2
$\begingroup$

I have a use case where I need to build a unique identifier for my users with the email address and the "family member number". However, the two personal informations used to build the identifier must be hidden. I thought using a hash function for that but there is a risk of collision (the identifier is not guaranteed to be unique).

Should I still use a hashing function for that, or should I use some kind of bijective function with unknown reciprocal, if such kind of function exists?

$\endgroup$
1
$\begingroup$

First of all, there is no problem with using SHA256 or SHAKE128/256[1] those would have had $2^{128}$ collision resistance with a 50% probability by the birthday attack. If you really fear that switch to 512-bit versions. Take SHA512 or Shake256/512 both have $2^{256}$ collision resistance with a 50% probability by the birthday attack. Even if you ever hash $2^{80}$ uniform random 256-bit strings then the probability of the collision is $(2^{80})^2/2^{256}/2 = 2^{160 - 256-1} = 1/2^{97}$ and this is not going to happen, and the less the data you have, the more little probability you will get.

If you ever find a collision tell the world that you will be famous. Actually, I would go for the tiny, tiny chance to find a collision in SHA256 or SHAKE128. A simple query for checking the existence of the identifier would find out the collision. There is always such checking already since you might add the same user again.

For direct hashing with SHA-256, you do not need to worry about the collisions, you need to worry about the possible leak of information, and that totally depends on how the data are transmitted and/or stored.

It is possible to use a keyed hashes if you have some HSM to protect the key. The HMAC-X is proven to be PRF if the underlying hash function is PRF. The X stands for a hash function as HMAC-SHA256.

All of the above would solve your problem without any fear.

In short: A good cryptographing hashing is enough if there is no leakage problem. Even a collision resistance is not required at all. It may suffice to use a 128-bit PRF, if the secret key is safe to be used in your application.

$\endgroup$
  • $\begingroup$ Thanks to Squeamish Ossifrage for their valuable comments. $\endgroup$ – kelalaka Oct 28 '20 at 19:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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