0
$\begingroup$

I'm a web developer starting to dip into cryptography so please bare with me on this...

Let's say I have a collection of hashes that were generated from some common data i.e. changes to multiple records. Is there a way that I could generate a secondary hash from the main hash and compare it to the other hashes based on how the main hash was generated. For example...

plain text             | hash      | hint hash
----------------------------------------------
"USER:123:fName:Alice" | 92eb5ff.. | 3cd24
"USER:123:fName:alice!"| 1c77753.. | 3cd24
"USER:456:fName:Bob"   | fee6ae2.. | 7d28e
"USER:456:fName:bob!"  | 7775315.. | 7d28e
"USER:789:fName:Carl"  | fec3ad7.. | 75315

Notice how all hashes are unique but the hint hashes match up to the record IDs they are hashed from. So if I generated these hashes based on the plain text and some key i.e. genHash(plainText, keyText). If you only had the hashes, you could associate which hashes are related to each other by their hint hashes only. So if I only had the hashes, I could still find their associations with a couple getHintHash(hash) calls...

Table of hashes:

hash      
---------
92eb5ff.. 
1c77753..
fee6ae2..
7775315.. 
fec3ad7..

Table of hashes with hint hashes:

hash      | hint hash
----------------------
92eb5ff.. | 3cd24
1c77753.. | 3cd24
fee6ae2.. | 7d28e
7775315.. | 7d28e
fec3ad7.. | 75315

Now I have the relationships between the unique hashes without exposing the plain text that generated them. Is this possible? Remember, the hashing function got the plaintext and a key that the "hint hash" could be based off of...

genHash("USER:123:fName:Alice", "USER:123") -> 92eb5ff..
$\endgroup$
  • 2
    $\begingroup$ Can you just store 2 hashes, one hash is the hash of the full user id string ("plaintext" column in your table), and for the second "hint" hash hash just hash the relevant subsection of your input string (i.e. the user:id#)? You would need long enough user IDs though, or else the hash can be easily reversed via brute force. You might leave a description of the actual problem you are attempting to solve with this idea, because there might be a better or even standard way of solving the problem. $\endgroup$ – Ella Rose Sep 3 '16 at 1:12
  • 2
    $\begingroup$ Does "collection of hashes that were generated" mean that the generation method for these hashes can not be substituted with another one? Or on the other hand do you have freedom on that? If it can not be changed, what is known about said generation method? $\endgroup$ – fgrieu Sep 3 '16 at 7:05
2
$\begingroup$

Cryptographic hash functions are designed to have certain properties, which is collision resistance, preimage resistance and second preimage resistance. If those definitions are not clear, we could state informally:

If you only have hash values of some input data, then you can't do anything except check for equality. You can't compare the input data, you can't check if they have a common substring, and most importantly you can't get back the input from the hash. So imagine a hash function as a one-way street, where you can afterwards just check for equality. Any other structure is lost.

And this is the behavior, which is wanted from cryptographic hashes.

So if you consider your database, when you have access to the plain text, you could just use a hash function with only the user ID as input:

  • $h_1 = hash(FullPlaintext)$
  • $h_2 = hash(User ID)$
  • Save tuples $(h_1,h_2)$, e.g. in a table

If you want to add some keys to those inputs, you have to consider that using a different key means getting a different example, and there is no way to tell if just part of the input was equal or not. But with this table you could do your lookups. But it is impossible to get $h_2$ from $h_1$ or vice versa. In a cryptographic hash function, you simply can't go backwards.

$\endgroup$

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.