0

I'm trying to come up with a good strategy for salting each row's column value in an SQL table with [semi-] independent salts for each cell. Ideally, I'd prefer a setup with only 1 secret salt per table, with the salt of each table-cell derived from (i.e. determined algorithmically) from that 1 secret salt.

The reason why I need a new salt per table-cell is that I need to advertise the hash of each column value without giving away its value. (I'll compute each cell's hash by concatenating the cell's value to its salt and then compute the hash of that byte sequence.)

A simple strategy I have in mind for generating the per-table-cell salt is to say generate a secret, secure 32-byte random byte sequence for table, call it R_32, and then for each cell compute the SHA-256 of R_32 concatenated with the cell's coordinates. In pseudo code:

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

where + here represents byte-string concatenation (not addition).

This way, I can both advertise a table-cell's hash, and if necessary, later prove the contents of that cell generated the hash (by exposing only that cell's salt and it contents).

I'm a mathy programmer with some working (application-level) knowledge of cryptographic principles, but not a cryptographer. So 2 general questions:

  1. Is the above salt(row,col) function secure? (I obviously think it should be, but there may be subtleties)

  2. I feel I can't be the first person tackling this problem of deriving multiple salts from a single secret salt. My searches come up naught however. Maybe they even wrote about it. If so, any pointers much appreciated.

Thank you

Babak Farhang
  • 79
  • 1
  • 8
  • One question is what exactly you want to achieve with this hash. Is it only for verification that the cell content is untampered, or do you need to extract the cell position from the hash, or maybe something wholly different? I suspect that "salt" is not the correct word for what you need. – martinstoeckli Jun 15 '21 at 09:47
  • I think *salt* is the right word in this context: I'm calculating hash of a cell with some salt added to it. After seeing no response here, I cross posted on the sister crypto, btw. https://crypto.stackexchange.com/questions/91525/does-my-sha-256-tablesalt-algo-give-away-the-seed-salt – Babak Farhang Jun 16 '21 at 20:35
  • The reason I asked is, when you don't need to refind the cell by seeing the hash, you could just use any password-hash function like Argon2, it adds a salt on its own and appends it to the resulting hash-value (a **salt** doesn't need to be secret). The idea you seem to have, should better be solved with a [HMAC](https://en.wikipedia.org/wiki/HMAC), it takes a secret **key** and a hash function to generate the calculated value. – martinstoeckli Jun 16 '21 at 21:14
  • Ah, forgot to link to what motivates this approach.. https://github.com/crums-io/skipledger The objective there is to compute and advertise the hash of any cell value in a way that doesn't give away the value until you choose to reveal it: when you do reveal it, you show both the salt and the value that together match the cell's previously advertised hash. Without salting, the cell's value is often deducible from its straight hash using so called rainbow attacks. So in this application, a cell's salt is kept secret--until such time when you choose to show the cell's value. – Babak Farhang Jun 17 '21 at 05:59

0 Answers0