I am using hash for authenticating the signature of the message. since the hash will be part of a url that is used for QR code, I would like to keep the hash as short as possible in order to generate a less complicated qr code which is easy to scan.

Now I am using md5 hmac to compute the hash which already generates a shorter one(32) than SHA256. But it isn't short enough and I am thinking of truncating the hash to get a even shorter one. say length of 16.

I would like to get your opinion on how is this method, does it make the hash easily cracked practically? or if there is better method?


  • Just a curious question: why can't you use a URL shortening service?
    – mmtauqir
    Commented Oct 14, 2014 at 1:43
  • QR code is not pregenerated so can't rely on the network availability. besides, shortening services are usually just incremental digits with base62 thus make them guessable and get to the real url.
    – perlwle
    Commented Oct 14, 2014 at 4:43
  • @perlwle A shortening service will usually be a little more cunning with its address space: The internal counter is never shown - or even doesn't exist (pure hashing); being run through a cryptographic hash to produce the public shortened URL. Perhaps then passed through Base58Check encoding to remove lookalike characters. Still, secret URLs shouldn't go through a public URL shortening service. Commented Oct 14, 2014 at 6:15

1 Answer 1


Truncating a well designed cryptographic hash digest should not result any security weaknesses other than a reduction in the collision space. As these hash algorithms have a key design requirement of being uniformly distributed across the hash space.

All other things equal, using a more modern hash algorithm (SHA) and truncating it is safer than using an older one (MD5).

  • Amusingly, for specific scenarios, it can be useful to truncate a cryptographic hash to a single byte - boy did the old school techs have difficulty wrapping their heads around that one. (Scenario being fuzzy matching of masked data) Commented Oct 14, 2014 at 2:47
  • a reduction in the collision space means it will be easier to find a collision, right? is it a real threat with brutal force search?
    – perlwle
    Commented Oct 14, 2014 at 5:56
  • 1
    @perlwle Say you want 2^16 instead of 2^256. This is a phenomenal drop in collision space size. At 2^16 or 2^32 it will be trivially easy to produce another semantically valid message with the same hash. Whilst QR codes are less responsive at longer sizes, anything less than 128 bits is too low for practical protection. The problem is that if you are using the QR code for a URL, you have to store the hash component less efficiently. A 128 bit digest in Base64 will add about 22 characters to your URL length. Commented Oct 14, 2014 at 6:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .