1

I'm generating 128 bit API keys. AFAIK 128 is totally secure for generated key. In the DB I want to store hashes, not the plain text (to be protected against DB leak), but what hashing algorithm should I use? MD5 and SHA-1 are not considered secure. SHA-256 produces bigger output than the key itself so it seems like it doesn't make sense to use a 128 bit key with SHA-256.

3

In theory, it should be safe to use MD5 here since it is only vulnerable to collision attacks, not the much more dangerous preimage attacks which would be required to forge an API key. However, it's certainly not a bad thing to avoid MD5 on principle, since it looks bad for auditors.

Assuming the value you are hashing is randomly generated and is not a human-provided and potentially weak password, then you can use SHA-512 and truncate the output. If you want to use a standard, then there is a SHA-512/t hash defined in FIPS 180-4 in section 5.3.6 which outputs a digest of t ≤ 512 bits. If a standard is not important to you, then it's fine to just truncate the output of the hash to 128 bits.

I specify SHA-512 rather than SHA-256 because, paradoxically, it's actually faster on 64-bit systems. If your system is not 64-bit, then you will probably have better performance with SHA-256.

3

but what hashing key should i use? md5 or sha1 are not considered secure. sha256 produces bigger output than the key itself so it seems like it doesn't make sense to use 128bit key with sha256

It's okay for the output hash to be longer than the input being protected. Sha1 and Md5 are both deprecated for certain applications, so probably best to avoid those options.

Since you are hashing 128 bit keys you may be fine just using one round of sha256. This is based on the understanding that you are hashing random 128-bit api keys and not passwords. The advice for hashing passwords will be very different.

  • i need it to be fast as the overhead of an api key should be minimal – piotrek May 10 at 17:35
  • I see. Actually, I just updated my answer. Since your input is 128 bit keys rather than passwords the threat of offline cracking is not as likely. You're hashing it server side tho? – hft May 10 at 17:37
  • 2
    Small pedantic correction: PBKDF2 is doing multiple rounds of a hashing algorithm like SHA256... bcrypt is similar, but it uses the blowfish cypher, rather than hashing algorithms. (Such details only matter if you're trying to pick which key stretching algorithm to use, though, and in OP's case, doesn't matter at all since they don't need to stretch their keys to resist offline cracking.) – Ghedipunk May 10 at 19:39
  • 2
    Everything between the first paragraph and the last two sentences is somewhere between misleading and just bad advice. For a securely-generated 128-bit random key, you should not use multiple rounds of hashing or anything like bcrypt; the entropy of the input is so high that brute-forcing it is already impossible (practically speaking). Adding cost is pure negative. In fact, from a security perspective, SHA1 would probably be OK if it weren't for the fact that it'll cause any competent static analysis tool to yell at you. – CBHacking May 10 at 20:31
  • You don't need a KDF if the key is a "generated key" and not a password... @CBHacking is correct. – forest May 11 at 1:51
0

You can and probably should use SHA-512 (or SHA-256 if you prefer) and just use the first 128 bits of the output. There is no reason to be afraid of just throwing away part of the output.

  • It does technically reduce the cryptographic strength (increased risk of collisions, etc.) but practically speaking it's fine, yeah. On the other hand, why bother? Just store the extra 16 bytes. Your database isn't going to care, and the I/O and compute difference is negligible. – CBHacking May 10 at 20:36
  • @CBHacking Sure the resistance is lower, but with 128 bit, it is very unlikely to be important. As for the DB, I assumed he cares about the space if he asks this question instead of just using the (overkill) sha-256 – Peter Harmann May 11 at 2:14

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.