how many iterations of SHA3 (keccak256) hashing would be required to provide reasonable protection for the following data structure?

Question

((A , B , C) , (D , E , F, G, H))

Where:

A is 0x0-0xF, (1 of 16)

B is 0x00-0xFF (1 of 256)

C is an 8 digit integer

D is a one of a list of one hundred words padded to 12 characters

E is a one of a list of one hundred words padded to 12 characters

F is a one of a list of one hundred words padded to 12 characters

G is a nine-digit numerical value, that could be one of 3 derived from (D,E,F) through research

H is an alphanumeric "secret" of a(hopefully but humans are lazy) secure nature

Where ABC are hashed to a 32-byte value, DEFGH to another, then both resulting values are concatenated and hashed together

These metrics are based an very pessimistic assumptions about the randomness of my inputs.

In my naive understanding that gives me 1.2289e20 permutations assuming that the "secret" can be derived from a 100 word rainbow table lol.

The objective is to make it impractical to derive hash-seed candidates in the foreseeable future.

my equally naive analysis is that at 1,000,000,000 hashes generated per second this would require a median time to match of about 1900 years per hash?

Answer 1

Since H is essentially a password, I would say... none.

Why? Because SHA-3 is not good for passwords, relative to alternatives, see my answer here why: Replacing the PRF in PBKDF2 with Keccak

Now, if you used a different hash function that is a different story, but you are also performing 3 hash steps, that require different security parameters. You want the outermost hash to be the most difficult to reverse, and you want the secret to be the most difficult to brute force.

Since A+B+C are small, your outer most hash must have a high iteration count. Since H is a secret, the final hash containing it must have a high iteration count. Therefore your inner hashes can be a single iteration as long as the outer one is many. You can probably also just use PBKDF2-SHA256 with H as the password, and ((A , B , C) , (D , E , F, G)) as the salt. As for the logic behind this, it is best to look at H as the seed for your final output. A through G is now a 58.5-bit number used to derive the output from a secret.

Relative to H, your iteration count should be enough to slow the hash function down to more than 1ms, so at LEAST a million based on your calculation. Since this is a single threaded process, if you have a highly threaded system running the hash, your concurrent hash rate can be high, or you can increase the iteration count.