Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Imagine a B2B service where two parties need to set up a two-way trust relationship: Alice will only accept requests from Bob, and Bob wants to know his requests are only going to Alice.

When setting up this relationship, Alice and Bob need to exchange their public keys. But when it comes to verification, is it enough to verify that the certificate thumbprint matches? Or, should Alice and Bob exchange the full public key?

A public key is quite long, and a thumbprint is short, so the thumbprint is more convenient. But since it is shorter, does that mean it has a higher chance of collision? How much safety is lost by only using the thumbprint to identify the caller rather than the full public key?

This page, for example, suggests that the thumbprint is fine for verifying. Can anyone confirm?

And if the thumbprint is enough, why do services like Github expect you to upload your full public key instead of just a thumbprint when establishing trust?

share|improve this question
Note that not all public keys need to be much larger than a hash. For example elliptic curve crypto with a security level of 128 bits can work with a 256 bit public key. – CodesInChaos May 28 '12 at 13:55
up vote 4 down vote accepted

A hash of the public key is enough, provided it's long enough(I'd recommend 160 bits), and the hash function is resistant against second pre-images.

I guess github wants full public keys because their SSH library expects that. There are also some situations where it's useful to have the full key available. For example you can offline encrypt a message to a certain public key, but not to a hash.

The decision hash vs. public key isn't a decision based on security, but on which one is more convenient for a particular use.

share|improve this answer
Thanks for the answer. Do you know of any links/resources to confirm that? – Paul Stovell May 26 '12 at 22:22
@paulstovell - I agree with codeinchaos. One thing to consider is that you're comparing two different implementations of asym crypto. SSH relies more on p2p trust (similar to PGP/GPG) while PKI relies on a CA hierarchy (or hierarchy of trust - refer to link referenced above). In the PKI model, since trust is hierarchical in, a thumbprint of cert is usually sufficient to assuming OCSP/CDP works (i.e. you can have a valid cert but it might be revoked). SSH is a bit different in that there isn't a hierarchy so a public key provides sufficient assurance. – bangdang May 27 '12 at 5:03

Exchanging a thumbprint is sufficient, as long as you later check that the public key matches the thumbprint that was exchanged.

Github wants you to upload your entire SSH public key for a number of reasons: (1) due to the way SSH configuration files are set up, the Github SSH server needs to know the entire public key (SSH configuration files expect an entire public key, not a thumbprint), (2) it is easier for users to upload their entire public key (that's just uploading their ~/.ssh/ file) than to upload a thumbprint (users would have to manually hash their public key and then upload the hash, which is less convenient). Basically, for SSH, there's no real need to introduce thumbprints in this setting, so no one bothers to do so -- though if they did so, that would be sufficient for security.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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