Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
In Unix crypt using SHA-256 and SHA-512 the author, Ulrich Drepper, introduces the SALT string as the following (highlight by me):
For the SHA-based methods the SALT string can be a simple string of which up to 16 characters are used.
What is the rationale calling this string a simple string? What does it mean? What are the consequences? I'm especially interested in the edge-cases of providing a string of 16 NUL bytes for example.
The text means "simple" by opposition to what was used in the older traditional DES-based crypt() where the salt was a 12-bit value, represented as exactly two characters in a restricted set. Ulrich Drepper wants to say that his creation is less picky and can take as salt any sequence of up to 16 bytes.
Though the hashing function itself can work with any bytes (including zeros, which are not special in any way for a hash function), the C code shown in the text you link to uses a string-based API:
char *
sha256_crypt (const char *key, const char *salt)
i.e. the salt will stop just before the first byte of value zero, or just after the 16th byte, whichever comes first. Moreover, the value of the salt will be part of the produced output string, so the salt had better consist in printable ASCII characters and not include the '$' sign, since that's what is used as separator within that string.
A simple way to generate a "proper salt string" for this function is to generate a sequence of exactly 12 random bytes (taken from a good PRNG, i.e. /dev/urandom), and encode them with Base64. This will yield 16 random characters, in an alphabet containing letters (uppercase and lowercase), digits, '+' and '/' -- and none other, in particular no '$' and no troublesome control character. The salt will still have 96 bits of entropy, making salt reuse considerably improbable (so things will be fine).
$ makes no sense, too, because otherwise it wouldn't be properly recognized later on. So this does not require to encode as base64 (which is done on others AFAIK), but to just encode "base254" and exclude \NUL and $ from the alphabet, right?
/etc/passwd or /etc/shadow file which can have its own additional constraints (e.g. no ':'). There are three levels: the abstract function (which accepts any byte value), the sample implementation (which does not tolerate zeros and '$'), and "other users" who can be more picky. Sticking to Base64 should be safe for all three levels. The whole thing is not as well specified as it should.
In this context a simple string is any character array in C for example: char[]. The code is performing a strlen() so it is null terminated. A salt should be a cryptographic nonce.
strlen which - when I look that up for C - is documented to terminate strings at NUL byte. So isn't that conflicting to your answer? Am I missing something?
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0is a perfectly fine salt; however to be an effective salt it should only be used once (or else its not really salting the password and all hashes can be attacked in parallel).crypt()for SHA-256/512, it's cutted-off before the first NUL byte. AFAIK PHP devs have ported Dreppers code, so the perfectly fine salt you have does effectively not work. I'm trying to find out if it should work or not by the specs given.