# ASCII input to HMAC weaker than raw bytes?

In various cryptographic programs I've written (most have been toy problems, but this current one is not) I have taken a slothful approach to performing a message digest (hash) of numerical input. I have been casting the numbers to strings, concatenating them, and then performing the hash. (Actually, this is a keyed hash, or HMAC, as described in RFC_2104.)

Example:

# I desire to hash a single bit with a sequence number.
# bit is either 0 or 1
# sequence_number is some 64-bit number.
# key is some 32-bit number/value used to create an HMAC.
make_HMAC(key, str(bit) + str(sequence_number))

# make_HMAC works on longs as well, but would become ambiguous because:
# make_HMAC(key, 0 + sequence_number) == make_HMAC(key, 1 + (sequence_number - 1))


I've been avoiding ambiguity, but I worry that I've weakened the strength of my hashing functionality in a subtle way.

Does casting these values to a string cause the HMAC to become less secure in any way?

If it matters, I'm using python 2.7 and the pycrypto library.

-

In one sense, no, encoding should not have an impact on security of HMAC.

On the other hand, it could have an application dependent impact.

Consider the following. '26' and 26 have the same HMAC. Now, assume your code receives a message, M, and an HMAC, MAC, and then does something like this

if HMAC(M, private_key) == MAC:
if isinstance(M, basestring):