# 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?

• 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. Jun 11 at 23:12
• 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. Jun 12 at 0:00
• 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. Jun 12 at 5:03