1
$\begingroup$

The Setup

I have a table of values for which I need to compute a salted hash for each table-cell value. Furthermore, I need the salt for each table cell to be unique and unpredictable. (I can explain what motivates this need later, but for now I don't want to distract from the problem statement.)

Now I don't want to add an extra column per existing column in a table just to store this unique, per-cell salt. So a simple strategy I have in mind is to first generate a secret, secure random 32-byte sequence for the entire table, call it R_32, and then for any given cell compute its salt as the SHA-256 of R_32 concatenated with the cell's row/column coordinates. In pseudo code this look like

tableSalt(row, col) = SHA_256( R_32 + row + col )

where + here is taken to mean byte-string concatenation, not addition. (The row/column coordinates are represented as 8-byte values each.)

Question

In my application it's critical that the secret seed hash R_32 above not be reverse-engineerable, no matter how many different cell-salts from the same table are known. Is the tableSalt procedure above secure in this respect?

$\endgroup$
3
  • $\begingroup$ I would use HMAC in this case to compute the salt and then use the salt as the key for a second HMAC to compute your salted hash. That will definitely be secure, and it uses more standard techniques that are going to be easier to audit. $\endgroup$
    – bk2204
    Commented Jun 11, 2021 at 23:12
  • $\begingroup$ My concern actually lies with any known weaknesses in SHA-256 (deviations from an ideal cryptographic hash function) when used with those fixed-width, low-entropy, 16-byte appendages to the seed above. It's that, that worries me. $\endgroup$ Commented Jun 12, 2021 at 0:00
  • $\begingroup$ It's probably ok as is, but HMAC is better, it will ensure sufficient mixing happens after adding the corrdinates, makes it ublikely the different salts will be related in a problematic manner. Also SHA3 is betterr in this regard. $\endgroup$
    – Meir Maor
    Commented Jun 12, 2021 at 5:03

1 Answer 1

0
$\begingroup$

Is it secure? Yes, as in this basic setup is used elsewhere and I'm unaware of any practical attacks. However SHA256 isn't the best choice. It's basic structure doesn't mix in the suffix as well as we might want. An HMAC structure or simply use SHA3 with a sponge structure would be better but even as written I don't believe the salts will be related in an exploitable fashion.

$\endgroup$
4
  • $\begingroup$ Thank you for your answer. I don't have enough karma points to mark your answer up. (Kinda strange, given it's my question and I was allowed to post it :) What's this "sponge-structure" you mention? Also, for the purpose of "mixing", is there much advantage in nesting the computation, as in Hash(Hash(content + row) + column)) ? $\endgroup$ Commented Jun 12, 2021 at 16:04
  • $\begingroup$ You can mark as approved. with a check even if you can't upvote. The nesting would mean apply a full hash after adding the low entropy part hash(hash(master seed+row+column)). this is particularly useful for merkel damgard constructs. But SHA3 it probably isn't needed it is: en.m.wikipedia.org/wiki/Sponge_function $\endgroup$
    – Meir Maor
    Commented Jun 12, 2021 at 16:27
  • $\begingroup$ Thanks very much for the link and the pointer about the ability to mark a closing answer. Re hash(hash(master seed+row+column)) instead of hash(hash(master_seed + row) + column) Was that a typo? Cuz I always thought the hash of a hash is no more secure than the original hash. $\endgroup$ Commented Jun 12, 2021 at 17:10
  • $\begingroup$ It'a not equivalent because it gets the high entropy seed mixed in more thoroughly. but what I wrote wad in fact not "correct"/best it should be like hmac. hash(seed + hash(seed+location)). But really since I can't actually attack even your original formulation these improvements may not be necessary. $\endgroup$
    – Meir Maor
    Commented Jun 12, 2021 at 19:53

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