# Is it safe to use fast/small hash for key identity?

I have to roll database access keys often, but it's important to know which key each system is using in order to avoid unavailability. I want the systems to report that without exposing the key itself, of course.

I'm using randomly-generated 512-bit keys, and from each key I'm planning to make a 32-bit hash. I only need to compare a handful of keys each time, so it's ok to have $$1 - \frac{1}{2^{32}}$$ of comparison confidence (which gives more than 99.99999%).

If the attacker sees the hash and knows the key size, he/she can filter out keys that produce a different hash. However, he/she will still have $$2^{480}$$ keys to brute-force access the database.

Does that make sense or is there a better solution? If this will work, which hash function should I use for the 32-bit hash? CRC/Checksum/something else?

• Any reason you don't list truncating a cryptographic hash function like SHA2 down to 32 bits as an option? I ask since you mention collision-resistance and preimage-resistance in your tags and crypotgraphic hash functions provide both. – puzzlepalace May 2 '16 at 18:22
• Thanks, there's no special reason. How truncating works? Just remove the unwanted bits? I added the tags to call attention of hashing experts. – fernacolo May 2 '16 at 18:26
• Yes truncation means take the first 32 bits of output from the hash function (or the last 32 bits, it doesn't really matter as long as you are consistent). In the case of SHA2 the output is 256 bits, in general most cryptographic hash functions output at least 128 bits. – puzzlepalace May 2 '16 at 18:39
• @puzzlepalace, with 32-bits of output you'd see a collision after $2^{16}$ outputs anyways (very likely) so why bother with a crypto hash? Beyond that the usual issue with pre-image resistance is to find a pre-image and not the pre-image which would require an insance amount of work anyways here (after all you can't get a 512-bit entropy value compressed down to 32-bit anyways). The only advantage of SHA-2+truncate would be extensibility for the point where the OP wants to expand from 32-bit away which is trivial with truncation. – SEJPM May 2 '16 at 19:37