Join Log in
Score:6
A Tea Kettle avatar Crypto

Encoding salt as hex before hashing bad practice?

in flag
A Tea Kettle

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?

2380
0 + 0
Patrick Favre avatar
us flag
Patrick Favre
The main theme here is that when you do encoding (of what kind ever, be it hex, base64), be sure to decoded before use and NOT use the ASCII byte representation of the encoding string. Cryptographic primitives are often optimized for specific lengths of keys or salts, so if you pass incorrect lengths, they often get hashed, which may increase the risk of collision
1
Reply
Score:17
Marc avatar Crypto
in flag
Marc

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.

0 + 0
Maarten Bodewes avatar
in flag
Maarten Bodewes
Strings may also be harder to destroy, they may even get "internalized", i.e. kept during the lifetime of the machine.
0
Reply
A Tea Kettle avatar
in flag
A Tea Kettle
Thanks for the great explanation!
0
Reply
Ben avatar
tr flag
Ben
I don't understand how 32 raw bytes is different than 32 bytes. Based on your explanation, one hex character is stored in a byte, but that's not normal. There should be two hexadecimal digits per byte which would equate to 8 bits and a total of 256 possible values.
0
Reply
Marc avatar
in flag
Marc
Two hexadecimal digits can represent one byte. But if you have a string of this hexadecimal representation, a single byte of said string will be only one character. This is a common mistake people make: taking the first 32 bytes of a hexadecimal representation of raw data, not realizing they are dropping half of it.
3
Reply
Patrick Favre avatar
us flag
Patrick Favre
@marc great answer, however I agree that the description of 32 hex bytes is confusing: why not "32 characters (which needs 32 byte) of hexadecimal data is `16^32` possible keys"
1
Reply
Score:3
poncho avatar Crypto
my flag
poncho

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.

0 + 0
us flag
erickson
It is bad if it creates confusion about the data to be hashed. Cryptographic hashes operate on bytes, not characters, so text has to be encoded to bytes. Of course, unless you are using EBCDIC, there isn't likely to be any ambiguity when encoding hexadecimal digits. But if one implementation sees the text as hex-encoded bytes and decodes them, while another sees only the text and encodes it, they won't yield the same hash.
1
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.