Encoding salt as hex before hashing bad practice?

Question

I was reading a question about symmetric keys here and found the answer quite interesting. It mentions:

Be sure to pass in the raw bytes, and not, e.g., a hex-encoded string

Can someone elaborate on why this is bad? and also in the context of password hashing, is converting a salt to hex before sending it though the HMAC bad, and if so, why?

Answer 1

This does not talk about salt at all but about actual symmetric keys. Quoting the full paragraph:

Most programming environments provide some sort of "secure random" mechanism (a CSPRNG). You can use this to acquire a byte array of the appropriate length (e.g. 32 bytes for AES256), which can be used as a key. Be sure to pass in the raw bytes, and not, e.g., a hex-encoded string.

This means that if you're going to generate a 32 byte key (as shown in the paragraph), make sure these are 32 raw bytes and not 32 bytes of the hex encoded key.

The reason for this is simple:

• 32 raw bytes is 256^32 possible keys
• 32 bytes of hexadecimal data is 16^32 possible keys

If you need to pass the key around in hexadecimal representation, use the entire output which will be 64 bytes long.

As for salting, the strength of your salt depends on the size of it. It does not matter if it's raw or hexadecimal, it's the possible number of salts that matters.

Answer 2

Can someone elaborate on why this is bad?

Who said encoding salt before hashing was bad? When Tim McLean wrote:

Be sure to pass in the raw bytes, and not, e.g., a hex-encoded string.

he was specifically talking about generating a key for a symmetric cipher; he wasn't talking about generating an image to be hashed.

When you generate a salt for a hash, there is nothing wrong with using hex encoding.