The idea is to authenticate the TLS peer by verification of the SHA-1 hash of his public key (aka SKI). So Alice meets Bob in person and they exchange SKIs of their public keys. When later they establish TLS connection, each of them verifies the certificate of the other by calculating the SHA-1 of the public key in the cert and comparing it to the SHA-1 received earlier in person.

Looks safe to me except the known SHA-1 collision. But I am not sure if collision is really a risk here, because simply finding another sequence of bytes, which results in the same SHA-1 is not enough. This sequence of bytes must also be a valid public key and the corresponding private key must also be found.

So does the SHA-1 collision risk really adds risk to my use case?

  • $\begingroup$ @MaartenBodewes: the publickey field is SubjectPublicKeyInfo, commonly abbreviated SPKI. SKI is the common abbreviation for the extension SubjectKeyIdentifier (RFC5280 and it is indeed usually SHA1 of the publickey (only the BITSTRING part, not the whole SPKI structure) $\endgroup$ Commented Apr 18 at 1:17
  • $\begingroup$ Yeah, that was me not being sharp. The SKI is something different from an SPKI and I should know better. $\endgroup$
    – Maarten Bodewes
    Commented Apr 18 at 19:59

1 Answer 1


SHA-1 fingerprinting of the certificate (rather than the public key within it) is commonplace. It can be used to indicate the trustworthiness of the entire certificate but only if we assume that the original was not created by an untrustworthy party and if enough bytes of the SHA-1 hash are communicated.

I've used this once to validate a cert where the CA itself was found not to be trustworthy. I called a known good number and verified the fingerprint that way, and indicated that they could do this as well. The private key and leaf (server) certificate were known to be good after all.

However, if no trust anchor has been established you might as well simply communicate the certificate itself securely and then pin said certificate. This fingerprinting trick is only required if there is no way to securely communicate the certificate-to-be-pinned. Remember that you need to trust all the information in the cert, not just the public key!

  • $\begingroup$ The fingerprinting is required exactly because the sha-1 (all bytes) needs to be communicated in person. And it is required to trust the public key, not the full certificate, so that the certificate may be updated (using the same key pair) without affecting the trust. $\endgroup$
    – Alex
    Commented Apr 18 at 6:13
  • $\begingroup$ So what's the next step? Are you going to trust all the information within the next certificate that you receive? In principle you do have enough info to verify & validate it as that certificate will be signed as well, but I'd make sure you write down what you are expecting and what you are going to validate. $\endgroup$
    – Maarten Bodewes
    Commented Apr 18 at 20:02
  • $\begingroup$ Certificate and signature do not matter. The goal is to have an encrypted communication channel with a verified peer. My question is if verifying sha-1 of the public key instead of the public key directly adds risk. $\endgroup$
    – Alex
    Commented Apr 19 at 5:52
  • $\begingroup$ Well, no, but if you think that just having a trusted public key is all that there is to it then you might be mistaken. Time changes, server names can change etc. If you ask if you can trust X because you have received $x$ or $H(x)$ in a trusted way, then sure, $H(x)$ is secure. If there is no way that an attacker can influence $x$ then SHA-1 may suffice, but in this case I'd rather go for SHA-256 if just because of the higher protection against collisions. 80 bit << 128 bit after all. $\endgroup$
    – Maarten Bodewes
    Commented Apr 19 at 12:44

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.