Is a 256 bit HMAC-SHA256 key compromised if the tail is used for identification? 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?

Example:

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


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.