I'm thinking about trying to save some space (and readability) when referencing 2k and 4k public keys (millions of them) by storing the fingerprint in some places instead of the full public key.

The primary threat to the security of a fingerprint is a preimage attack, where an attacker constructs a key pair whose public key hashes to a fingerprint which matches the victim's fingerprint. The attacker could then present his public key in place of the victim's public key to masquerade as the victim.

A secondary threat to some systems is a collision attack, where an attacker constructs multiple key pairs which hash to his own fingerprint. This may allow an attacker to repudiate signatures he has created, or cause other confusion. - Wikipedia

With this in mind, I was wondering about using a larger hashing algorithm like SHA-256 to help prevent collisions or collision attacks.

SHA1 seems to be the existing standard, but is it still the way to go?

  • $\begingroup$ The known weaknesses in SHA-1 don't matter much since collisions aren't a big threat for fingerprints. So using it is okay. If you don't need compatibility with fingerprints computed by other software SHA-2 is probably a better idea. You can truncate it a bit if you want. $\endgroup$ Commented Jun 5, 2013 at 17:48
  • $\begingroup$ Assuming Wikipedia is up to date, the most efficient attack against SHA1 still costs $2.77M for a single hash. Even if someone mounts a collision attack against you, you can still ask them to sign or encrypt something to verify their identity. From what I understand, you will only be using fingerprints to index keys in your database? $\endgroup$
    – rath
    Commented Jun 6, 2013 at 1:07

1 Answer 1


I understand that in 2005 SHA-1 was found to have a security flaw and the now recommended standard for this kind of thing is SHA-2 (256 or 512).

This post may be of some use: https://stackoverflow.com/questions/3897434/password-security-sha1-sha256-or-sha512

  • $\begingroup$ I'm more interested in collisions, not password security from hashing. Besides, I would use bcrypt for passwords to increase the time needed to hash them. $\endgroup$
    – Xeoncross
    Commented Jun 5, 2013 at 17:32
  • $\begingroup$ I believe the chances of a SHA-1 collision is something like 10^48. Or thereabouts. $\endgroup$ Commented Jun 5, 2013 at 17:40
  • $\begingroup$ @JonnyWilson $2^{160} \approx 10^{48}$ is the cost of a pre-image attack against SHA-1. A generic collision attack costs $2^{80}$, and thanks to SHA-1's weaknesses a collision attack is even cheaper. $\endgroup$ Commented Jun 5, 2013 at 17:50
  • $\begingroup$ @Xeoncross The security weakness in SHA-1 is not limited to hashing passwords. They are directly related to an attacker being able to find a message m2 such that $H(m1) == H(m2) \vert| m1 != m2$, which is exactly the sort of issue that should concern you. It's still too difficult to generate collisions in practice, but the security properties of SHA-1 are only going to get weaker. When developing new software, choosing one of the SHA-2 algorithms is probably prudent. $\endgroup$ Commented Jun 6, 2013 at 0:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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