Why x00 is usually avoided in salt?

Question

In .NET Framework, there is a cryptographic Random Number Generator (RNG) provider which enables to generate a cryptographically strong sequence of random bytes. This provider contain, among others, two methods:

• GetBytes which generates a sequence of random bytes, and

• GetNonZeroBytes which does the same thing, except that the generated sequence will contain only nonzero bytes.

In every case I've seen where a salt is generated (for example for PBKDF2), the code similar to this is used, calling always the GetNonZeroBytes method:

var salt = new byte[128];
using (var rng = new RNGCryptoServiceProvider())
{
    rng.GetNonZeroBytes(salt);
}

I'm not sure, but from what I've seen, I believe that zero bytes are avoided in other languages/frameworks too.

Why GetBytes is always avoided? What's bad in having x00 in a salt?

Is there a limitation in one of the popular hashing algorithms (SHA512, PBKDF2, etc.) which prevents using the salt containing x00, or the zero bytes are avoided only by fear to having interoperability issues or the issues with the storage of the salt in some third-party database?

Answer 1

This is not a limitation of the cryptographic functions, like SHA or PBKDF, since the zero byte isn't processed any differently.

Since the purpose of a salt is generally to travel alongside a human password, libraries that handle the password as a zero-terminated string might also handle the salt as such a string. Obviously, a 0x00 in the salt would terminate the salt per-maturely when it is processed as a string. If you're interested, you may want to view the code to see where the salts you saw generated actually get used and whether those APIs treat the salt as a string.

In general, there is no universal standard for how to format salt, so the way a salt is processed is left up to the designers of a specification. If you don't know what APIs a salt you generate will be plugged into, the safest strategy is to make the contents all non-zero so it will work with any API that evaluates the salt as a string.

Another (less likely) explanation: In general, there are some standards that require random values that be non-zero. For example, PKCS v1.5 encryption scheme (section 7.2.1 step "a") calls for 8 bytes of random padding of nonzero values. In this example the padding value is not a salt, but the existence of such requirements for random data in some specifications may lead a developer to cautiously always generate non-zero random data just to be safe.