3

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?

Improve this question
1
  • 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, 2012 at 13:55

2 Answers 2

Reset to default
4

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.

Improve this answer
2
  • Thanks for the answer. Do you know of any links/resources to confirm that?
    – Paul Stovell
    May 26, 2012 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, 2012 at 5:03
2

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/id_dsa.pub 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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .