2
$\begingroup$

I am in an environment where I have unique IDs for a list of resources. I am trying to design a system that takes that ID as an input parameter and produces a consistent output for a given resource. I am trying to obfuscate which ID led to a given output, but both the input IDs and the output will be public information. There can be as few as 2 resources (and thus only 2 possible input IDs).

I am also trying to avoid having to store any additional information for each resource.

Would combining the input ID with a large (256 bit) secret salt value then running it through a hash function be sufficient? Would it be safe to use the same salt for all inputs?

Optimally, It would also be convenient if I could figure out which resource created which output given only the salt, but that wouldn't work with my proposed solution. Is there some other way to approach this problem that would have that property?

Improve this question
$\endgroup$

1 Answer 1

Reset to default
1
$\begingroup$

You are right thinking that using a large secret salt, such as a 256 bits value generated randomly (with a good CPRNG) should be fine.

Notice that we usually say that a salt can be known from the attack, which is not the case in your design, so you are not using a salt, but a key. Keyed-hash function are a thing (see BLAKE2, for example), but you can generally construct a keyed-hash function out of any hash function by simply hashing the concatenation of your key and your message with the said hash function.

In this latter case, which correspond to your design, the preimage resistance of the hash function would prevent the attacker from finding the "salted/keyed Resource ID" without knowing the key.

Using more than one key, like for example, one for each resource, would simply strengthen the system against potential leaks that might occur. Since then, if a key leaks, the rest of the non-leaked keys would still prevent an attacker from finding the image of a given Resource ID (or finding the preimage of a given hash by bruteforcing the possible Resource IDs, if those are known/in a small range).

Notice that the system you mention:

a system that takes that ID as an input parameter and produces a consistent output for a given resource

is somehow similar to a pseudo-random generator, where the key would be the resource ID. Using a keyed-hash function as you propose (as long as the key has enough entropy) is a way to construct such PRG, but there are some hiccups if you let the adversary possibly control your entropy pool... I'm looking for example at the "Hash_DRBG"...

Now another way around your problem, since you've got a key already, might be to simply encrypt the resource ID with a symmetric (AES, e.g.) and that key you called "salt"... (As long as that key is generated with a good entropy, using a CPRGN, you're safe.)

Plus you'd get the two-wayness you wanted, as you could simply decrypt the resulting value using the key to obtain the initial resource ID out of it.

Improve this answer
$\endgroup$
2
  • $\begingroup$ I wouldn't suggest using $H(k\|m)$ as we have HMAC. $\endgroup$
    – cypherfox
    Mar 23, 2018 at 0:19
  • 1
    $\begingroup$ My organization uses a similar scheme to produce stable unique identifiers in an analytics application where there are many sources and we want to prevent collisions while preserving privacy (one-wayness). Essentially we do CONVERT(uniqueidentifier,HMAC(secret_key,source_system_identifier|input)) $\endgroup$
    – rmalayter
    Mar 25, 2018 at 14:36

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.