3

I need a function that, given a salt integer and a value integer will return a small hash string. Calling the function with 1 and 56 might return "1AF3". Calling it with 2 and 56 might return "C2FA".

Background info: I have a web app (written in C# if that matters) that stores employee Id values as integers. Users need to be able to see a consistent representation of that Id, but no user should see the actual Id, or the same representation of that Id as seen by another user.

For example, suppose there is an Employee with the Id of 56.

When User 1 logs in, wherever he sees that employee, he sees "1AF3" or something. He might see this employee on different pages in the app, and its Id should always be 1AF3 so he knows it's the same guy.

When User 2 logs in, should he encounter that same employee, he would always see "C2FA", or something. Same goes for User 2: wherever he is in the system, he would see that one employee represented by that same string.

Should User 2 look over the shoulder of User 1 while User 1 is logged in, User 2 should not be able to recognize any of his employees on User 1's screen, because this hash should be irreversible.

Does this make sense?

One additional requirement is that since the users will be discussing these employees in email, on the phone, and in faxes, the hash would need to be of a minimum size and not contain non-alphanumeric characters. 10 characters or fewer would be ideal.

Maybe there is a way to "collapse" a SHA-256 result into fewer characters since the whole alphabet could be used? I have no idea.

Update: Another walk-through Thanks everyone for giving this a shot but it seems like I am doing a bad job explaining it or something.

Let's pretend you and me are both users of this system. You're Fred and I'm Chris. Your UserId is 2 and my UserId is 1. Let's also assume there are 5 Employees in the system. Employees are not users. You can think of them as products, or whatever you want. I'm just talking about 5 generic entities that you, Fred, and I, Chris, each deal with.

Fred, every time you log in, you need to be able to uniquely identify each employee. Every time I, Chris, log in, I also need to work with employees and I too will need to be able to identify them uniquely. But should I ever look over your shoulder while you are managing employees, I should not be able to figure out which ones you are managing.

So, while in the database, the employee IDs are 1, 2, 3, 4, and 5. You and I do not see them that way in our interface. I might see A, B, C, D, and E, and you might see F, G, H, I, and J. So while E and J both represent the same employee, I can't look at your screen while you are working with your Employee "J" and know that you are working with Employee 5, because for me, that employee is called Employee "E" for me.

So, Fred and Chris can each work with the same set of employees, but if they were to see each other's work, or discussion in an email, they would not be able to know what employees the other guy was talking about.

I was thinking I could achieve this "real-time user-dependent EmployeeID" by taking the real employee ID and hashing it using the user ID as the salt.

Since Fred and Chris each need to discuss employees over email and the telephone with their clients and customers, I'd like the IDs that they use in these discussions to be as simple as we can get them.

Improve this question

6 Answers 6

Reset to default
3

Conceptually, here is what you want:

You have a set of employee IDs which you can represent as element in a given space S. You also have some users, and you want each user to see a permutation of space S, which is specific to the user, and such that the details of that permutation cannot be guessed by any other user.

This calls for symmetric encryption. Namely, each employee ID is a numerical value (e.g. a 32-bit integer), and a user 'A' sees employee x as Ek(x), there k is a secret key which is specific to 'A' and that 'B' cannot guess. So you need two things:

  • a block cipher which can work with short values (e.g. 32-bit words);
  • a method which turns user ID into the user-specific key.

For the block cipher, the trouble is that short blocks are a security issue for the normal usage of a block cipher (i.e. to encrypt long messages). So all published, secure block ciphers use large blocks (64 bits or more). 64 bits can be represented over 11 characters by using uppercase and lowercase letters, and digits (6211 is somewhat greater than 264). If that's good enough for you, then use 3DES. If you want something smaller, you will have to design your own cipher, something which is not recommended at all. You may want to try KeeLoq: see this paper for pointers (KeeLoq is cryptographically "broken" but not too much, given your context). There is a generic method for building block ciphers with arbitrary block sizes, given a seekable stream cipher, but this is mostly theoretical (implementation requires waddling through high-precision floating point values, which can be done but is very slow).

For the user-specific key: you want something that the Web application can compute, but not users. This means that the Web application knows a secret key K; then, the user-specific encryption key can be the result of HMAC (with a good hash function, such as SHA-256) applied over the user ID, and using key K. You then truncate the HMAC output to the length you need for the user-specific key (for instance, 3DES needs a 24-byte key).

C# has TripleDES and HMAC/SHA-256 implementations (in System.Security.Cryptography namespace).

(There is no generally accepted secure standard for a block cipher with 32-bit blocks. This is still an open research area.)

Improve this answer
Sign up to request clarification or add additional context in comments.

5 Comments

Solid solution, but couldn't you just use the (unique) user ID as the HMAC key, run the HMAC over the real employee ID, and truncate the result for the fake employee ID?
Ok, I think I follow. Two questions: Did you mean 62^11 instead of 62^5? How do I represent the 64 bits with the 62-value alphanumeric set that you mentioned? Do I use cnicutar's method?
@indiv: if you use some other than a permutation (e.g. HMAC) then you may have collisions: two employee IDs which yield the same hashed value. To avoid collisions, you must use a larger output, and the output size is something which we want to optimize here. With 128-bit strings, HMAC would be fine.
@Chris: yes, it was 62^11, indeed (that's fixed now). Representing 64 bits with 62 alphanumeric characters means interpreting the 64 bits as an integer, and converting that integer to base 62 (just like conversion to decimal, with 62 instead of 10). This is not exactly what @cnicutar talks about; rather, load the 64 bits in a ulong, then divide repeatedly by 62; each division remainder yields a "digit" from 0 to 61, which you map to a letter-or-digit.
Cool. Going to give this a shot. Thanks for your detailed response.
1

There might be problems with this approach but you could do it like this:

  • Make an array holding all your symbols (say a 25 element array)
  • Hash your string using whatever hash function
  • Pick a number of octets out of the resulting hash (4 octets if you want 4 symbols in our resulting string) from predefined positions
  • For each octet compute index = octet % array_size. The index gives the position for each of your symbols

Again, I have almost zero experience with cryptography, hash functions and the like so you may want to take this with a grain of salt.

Improve this answer

1 Comment

This seems like a good generic way to shrink a hash into fewer characters when the set of possible values is larger (going from hex to the alphabet), which is what I want. But like you, I don't know much about cryptography.
0

There are many ways to "de-anonymize" information. It would help if you could be more specific about the context and what "assets" you are really trying to protect here, against who. See our faq.

E.g., might one user know the number of another user? They could probably find it out quickly if they discovered thru other means the correspondence between 1AF3 and C2FA.

But specifically for your narrower question, a good hash will already be well-mixed, so I'd think you could just truncate, e.g., a SHA-256 hash value. But Thomas will probably know the definitive answer there.

Improve this answer

4 Comments

I am trying to protect users from knowing the true integer IDs of the employees. Every user that logs in needs to see their own "version" of employee IDs. My thought was that when presenting Employee IDs, I would present to the user a hash of that employee ID using the logged-in user's own ID as the salt. Users and Employees are totally separate entities, if that helps. Truncating a SHA-256 sounds perfect, almost too easy!
@Chris - Ahh - getting clearer... You still haven't clarified (from the faq) more about the context. Is this just "it would be nice to make this all unclear to users"? Or is it "if a user identifies an employee, then there is a major financial consequence or someone gets fired or ....". How hard will users be trying to figure this all out - idle curiosity, or major incentive so they'll be persistent? And note that the context will often leak other info about employees - google de-anonymization....
I've practically written a book on this at this point. I don't mean to appear ungrateful, but if you're not picking up what I'm putting down right now, it's probably not going to happen.
@chris Heh - I'm not looking for appreciation. I'm just suggesting that this can be a surprisingly hard problem. If it isn't a big deal, then don't sweat it. If it is a big deal, then dig deeply into the advice folks have offered, and feel free to provide more details so we can provide further help for you and others in a similar situation.
0

Here are my thoughts getting to the point of it (I figure if you talked out your question, I'll talk out my answer. I'm guessing you'll find that helpful):

  • All hail Thomas, because he has clearly established his dominance.
  • 0-9, A-F is a representation of the data. You can make it A-Z, 0-9, exclude some uncommon letters, and represent six bits per character.
  • You can basically say that all hashes have collisions. If you approach saturation, you'll end up with two people who have the same hash. Hashes are also one-way. You would need a mapping that allows reversal. If you have a reverse mapping, why not fill it with random strings which don't collide?
  • You are obfuscating a limited set of data. With a large and secret salt, you can prevent reversal. That said, you're trading one ID for another. The ID is still unique and constant, so I wonder how this enhances security.
    • I have some clients where if I were to see something like this, I'd put money that the employee ID was a SSN. I hope you're not doing that.

Employee ID and Employee Alternate ID are what you are coming up with. Since they have to be reversible to you but not the public, you need to store that in a two way pairing and keep it secret. Since there's risk of collision with a hash and you have to have a reverse map anyway, the alternate id might as well be a random string. An ID should be arbitrary anyway, and I would really like to know the perceived security benefit of your approach with two ids for one employee; it makes me think of Mission Impossible and the NOC list.

Improve this answer

4 Comments

stackoverflow.com/users/254279 Thomas Pornin. I have a good understanding of cryptography. He's a cryptographer.
Why do I need a mapping that allows reversal? Reversibility is not a requirement. I'm not using SSN. I am using an integer for EmployeeId. The requirement is that each user that logs in sees the employee Ids represented by hashes that are constant only for that user. I tried to explain this with examples. I don't know how else to explain it. It's not just employee ID and alternate ID. It's employee ID and an on-the-fly hash of the employee ID with the logged-in user's own ID as the salt. Ever user sees their own "versions" of the IDs. Does this make sense?
I understand the technical requirement you've laid out, but not the logical motivation behind it. I guess I would alternately ask what the point of a consistent ID that can't be applied to anything would be. It seems like it is useless in presentation and existence. You can't look up a record by it.
It's a pretty damn weird requirement, I admit :). I tried to keep it simple with users, but it is actually User "groups" whose Ids I will be using to salt the hash. The users in these groups occasionally discuss the employees with each other but the users are not allowed to know the names of the employees. Now they have a way to refer to the employees in their discussions. Should a user form another user group overhear a discussion, the string wouldnt map to any user he knew about since his users all have different strings.
0

Just an idea for an approach based on the extra information you have added. The security on this idea is very very light and i'm would not recommend it if you think people are going to attempt to crack it, but it's worth throwing in the pot.

You could create a personal hash by bit-shifting the employee Id based on your own employee Id. Then by adding whatever extra obfuscation code you need to the resulting number, such as converting it to hex. E.g.

string hashedEmployeeId = (employeeIdToHash << myEmployeeId).ToString("X");

This will generate hashed employee Ids based on your own Id, but you may run into problems when the employee Ids get large (especially your own!)

Just to reiterate, this on it's own isn't really very secure but it might help you on your way.

Improve this answer

Comments

0

Using 4 characters you would have a total of: 36^4 = 1679616. You could permute all possibilities of employes togheter. If you calculate de square root you get 1296.

You could then generate an ordered table with all the possibilities in the first column and then randomly distribute ids from 1 to 1296 in to oder columns. You would get something like this:

key a b AAAA 386 67 AAAB 86 945 ...

With this solution you would have a lookup table scalable up to 1296 employes. However if you consider adding an extra character to your key you would get a lot more possibilities (36^5)^0.5=7776.

With this solution gessing a key would give you one chance on 1296 or 7776 to see information about an employe.

May be performance would be an issue, but I tink you can manage this using a cache or may be even keeping all the data loaded in memory and use a kind of tree map to find corresponding key for two given ids.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.