Using a truncated hash of a key seems to be a safe way to identify the key (i.e. key fingerprint), but what about truncating a key itself in the case of HMAC-SHA256?


$ key=`openssl rand 32 -base64`
    $ keyId=`echo $key | cut -c 40-43`
$ echo $key
$ echo $keyId

Is using $keyId as a way to identify the key secure? I recognize that the security strength will be reduced, but is it a negligible/acceptable amount? Is there something in the literature that addresses how disclosing the tail of a HMAC key impacts security?


This won't seriously impact the security of the key. HMAC is pretty resilient and changing the last part of the hash won't allow attacks on the a hash such as SHA-256.

Note that you only select 4 characters, of which the last one only encodes 4 bits (as it is at the end). That means you've got a check value the size of 2^22 encoded bits, i.e. a chance of 1 / 4194304 that you match a key that you didn't mean to match. If you generate a whole lot of keys you can certainly not use this to select one key from a set because of the birthday problem.

The security of HMAC is diminished with 22 bits as well, leaving you with 256 - 22 = 234 bits maximum security. Halve this for a usual setting of HMAC, so with a bit of handwaving, you're left with 117 bits.

Generally you take bytes from binary data before encoding to base 64. If you need base 64 you can separately encode the bytes afterwards.

Possible without significant reduction in quality: yes.

Advisable? Absolutely not, there doesn't seem any good reason to do this. Use a KBKDF (key based key derivation mechanism) instead to create a key fingerprint. You may use the HMAC using the normal key and an unlikely string for data for this.

  • $\begingroup$ That "normal hash" shouldn't necessarily be just the HMAC hash, since with a key longer than block size revealing parts of the hash is equivalent to revealing parts of the key. Probably better to use something like HMAC(k, 'fingerprint'). $\endgroup$ – otus Aug 21 '15 at 11:49
  • $\begingroup$ The question explicitly exposes part of the key already. The user is talking about using part of the key as KCV, before using it as input for HMAC, if I understood correctly. Yes, almost everything is more secure. $\endgroup$ – Maarten Bodewes Aug 21 '15 at 12:01
  • 1
    $\begingroup$ My point is that hash of the key isn't an improvement for keys longer than the block size. $\endgroup$ – otus Aug 21 '15 at 12:07
  • $\begingroup$ I'm sorry, I understand what you mean now, but I'm not sure if I understand the attack. Using a one way function such as a secure hash should not leak information about the message, even if it is a key. Yes, HMAC (or a KDF really) would be more secure, but I don't see how using a SHA-2 hash would significantly alter security (especially compared with leaking the key bits directly). $\endgroup$ – Maarten Bodewes Aug 21 '15 at 12:21
  • $\begingroup$ This wouldn't be used to identify a key from an unknown population of keys, but from a small set of keys on the order of tens of keys known to each party as legitimate keys.Maybe I'm $\endgroup$ – Onlyzuul Aug 21 '15 at 20:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.