Some Questions about salts

Question

I am an amateur teaching myself, so please don't expect too much professional knowledge. I have some things that are not clear to me about salts.

1. For example I wondered if a "too strong" salt could weaken a crypto hash.

   If you got an hash algo and you take a password of only one digit and then you fill the rest of the string with a salt til the maximum length of the hash is reached; example: the hash has 128 bit, the pass has 4bit (one ascii char) and the salt has 124 bit and salt and pass are merged together; Would the extreamly strong salt weaken the hash? If the hash got iterated (rehashed) with the same salt lets say 100-200 times how much of the final result would be "corrupted" by the salt?

2. Why does a salt need to be long in file encryption?

   This question is not related to Databases with thousands of hashed passes for obvious reasons. I saw people suggestiong a min. slat of 128 bits (32 digits!)

   Let's say you have a 20 GB veracrypt container ore some stuff like that (does not matter as long as it is only one file). And you want to protect from rainbow tables and precomputation attacks, then why not use a 1 charakter long salt? I mean nobody will generate a RT for a single hash so 1 digit salt = problem solved right? (as long as there are not multiple files).

3. Why does a salt need to be true random?

   Would it not be enough if the salt is pseudo random? It is not even a secret value, so does it have to be random? If it was pseudo random like lets say time in milliseconds then why is that not safe enough? even if the attacker would know the pttern of how the salts where generated, he would not have any advantage right? Like abcd1, abcd2, abcd3, abcd4. Why would that knowledge be an advantage?

Answer 1

1. a salt cannot "weaken" a password in any way
2. long salts make pre-computation of rainbow tables completely infeasible, across all machines using that application worldwide. Basically, by choosing a random 16-byte salt you're basically ensuring that your password hash is unique worldwide no matter the password
3. Pseudo-random values are preferred to ensure global (or at least system-wide) uniqueness of the hash (as described in #2 above). These bytes should come from a CSPRNG ("true randomness" isn't required). Using predictable salts such as time stamps can allow an attacker to create rainbow tables for subsets of the passwords in use.

Finally, traditional salted hash constructions (such as SHA256(salt||password)) are insufficient for modern password storage. You should use a memory-hard, purpose-built password hashing function like Argon2 or scrypt. These also take salts as inputs, so the same logic applies as above.