If you mean simple salting (and not salting+stretching like sha512crypt), then performance scales directly with the keyspace of the salt.
The attack has to try all possible salts. If the salt space is small, or if many of the hashes have the same salt, attack efficiency increases accordingly. But at the benchmark level, the "hashes per second" performance is about the same - but the total number of hash attempts is multiplied by the keyspace of the salt, so your time to full exhaustion goes up accordingly.
Selected benchmarks for 6x 1080 and hashcat 4.1.0:
Notice that performance drops slightly if the salt is in front of the password, vs appended to it. This is because of certain performance optimizations in hashcat relative to the left-hand-side of the candidate password.
The attack has to try all possible salts. If the salt space is small, or if many of the hashes have the same salt, attack efficiency increases accordingly. But at the benchmark level, the "hashes per second" performance is about the same - but the total number of hash attempts is multiplied by the keyspace of the salt, so your time to full exhaustion goes up accordingly.
Selected benchmarks for 6x 1080 and hashcat 4.1.0:
Code:
Hashmode: 6500 - AIX {ssha512} (Iterations: 64) 33046.4 kH/s
Hashmode: 1720 - sha512($salt.$pass) 5642.0 MH/s
Hashmode: 1710 - sha512($pass.$salt) 6330.7 MH/s
Hashmode: 1711 - SSHA-512(Base64), LDAP {SSHA512} 6335.3 MH/s
Hashmode: 1700 - SHA-512 6344.3 MH/sNotice that performance drops slightly if the salt is in front of the password, vs appended to it. This is because of certain performance optimizations in hashcat relative to the left-hand-side of the candidate password.
~