iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A public key hash is a short digest computed from a public key so that people can compare keys without reading the whole key. Protocols usually call it a public key fingerprint. There is no single universal recipe: the hash algorithm, the exact bytes that get hashed, and the output format are all defined by the specific protocol and key version, so a fingerprint from one system cannot be checked against a value produced by another.
What the term means
Public keys are often long encoded values, sometimes hundreds of characters or more. A fingerprint is a fixed-length summary of that key. It gives a person a shorter value to compare when deciding whether a key they were just presented matches the key they expected.
A fingerprint identifies a key only in the narrow sense that it is derived from the key’s bytes. It is not a name, a certificate, or proof of who controls a server or account. Those claims require a separate trust mechanism, such as a certificate chain, a previously verified key, or a directory the reader trusts.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Why keys are compared by hash instead of by full value
The SSH public key file format specification, RFC 4716 (November 2006), explains the motivation directly in Section 4: “Since public keys tend to be very large, it is difficult for a human to verify an entire host key.” A digest solves the readability problem, but it only works if both sides compute it the same way.
#1 Best Overall
Why the calculation changes from one system to another
Two implementations can use the same key and still produce different fingerprints if they hash different input bytes. A fingerprint is therefore defined by three things: which data is hashed and how that data is serialized or prefixed, which digest algorithm is applied, and how the result is printed. Change any one of these and the value changes.
The SSH transport specification, RFC 4253 (January 2006), describes how an SSH public key or certificate is encoded: a format identifier followed by key or certificate data. SSH fingerprints are defined on top of that encoding. OpenPGP, defined in RFC 9580, takes a different approach and hashes a packet header plus the public-key packet.
SSH fingerprints under RFC 4716
For the SSH public key file format in RFC 4716, the fingerprint is the MD5 digest of the public key data specified in RFC 4253. The result is 16 octets, shown in lowercase hexadecimal with colons between the bytes. A typical display looks like a sequence of pairs such as aa:bb:cc:... with sixteen pairs in total.
RFC 4716 states that MD5 is used for historical reasons and notes its weaknesses in collision resistance. That makes this format a specific historical SSH specification. It should not be treated as the fingerprint format of every SSH tool. In current OpenSSH releases, for example, ssh-keygen -l shows SHA-256 fingerprints by default; to see the MD5 colon form, you can run ssh-keygen -l -E md5 -f followed by the path to the public key file. Check the output of the tool you are actually using before comparing values.
OpenPGP fingerprints: version 4 and version 6
OpenPGP shows that the same concept can differ even inside one specification, because the fingerprint construction depends on the key version:
- Version 4 keys use the 160-bit SHA-1 hash of three inputs in order: the 0x99 octet, a two-octet packet length, and the public-key packet.
- Version 6 keys use the 256-bit SHA2-256 hash of the 0x9B octet, a four-octet packet length, and the public-key packet.
The version 6 construction therefore differs from version 4 in the prefix octet, the length field size, the digest algorithm, and the output length.
Rank #4
Side-by-side comparison
| Item | SSH, RFC 4716 | OpenPGP version 4, RFC 9580 | OpenPGP version 6, RFC 9580 |
|---|---|---|---|
| Hashed input | Public key data as specified in RFC 4253 | 0x99 octet, two-octet packet length, public-key packet | 0x9B octet, four-octet packet length, public-key packet |
| Digest algorithm | MD5 (historical; collision weaknesses noted in RFC 4716) | SHA-1 | SHA2-256 |
| Output size | 16 octets | 160 bits | 256 bits |
| Display format | Lowercase hexadecimal, colon-separated, as specified in RFC 4716 | Not stated in the cited specification | Not stated in the cited specification |
How to use a fingerprint safely
A fingerprint helps only when the expected value reaches you through a path you trust. Comparing a value sent by the same channel that delivered the key proves little. The usual workflow is:
- Identify the system and key version the value belongs to. An SSH host key and an OpenPGP key are not compared in the same way.
- Calculate or display the fingerprint in the format that system uses. Do not compare an MD5 value with a SHA-256 value, or a colon-separated hex string with a differently formatted one.
- Obtain the expected fingerprint from a source you trust separately from the key itself, such as an administrator who installed the server, a previously verified record, or an established trust mechanism.
- Compare the complete value, not just the first few characters.
SSH architecture guidance in RFC 4251 (January 2006) recommends making a best-effort check of host keys, storing a host key for later comparison, and offering a way to reject host keys that cannot be verified. Those three practices work together: verification at first contact, stored history for later visits, and a refusal option when verification is impossible.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.When a fingerprint does not match
A mismatch is a signal to investigate, not an instruction to accept the new value. Common reasons include a legitimate server reinstall or key rotation, a change in the software that computes the display format, or a configuration error. An attacker can also present a different key. Confirm the change through the trusted channel before updating any stored record.
- Check whether the mismatch came from a planned key change you can confirm with the system’s administrator.
- Recompute the fingerprint from the public key file yourself, using the same algorithm and format as the expected value.
- Do not replace a stored value simply because a new one was presented.
Key takeaways
- A public key hash, or fingerprint, is a digest of public key data that makes keys easier for people to compare.
- The calculation is defined per protocol and key version, so the input bytes, digest algorithm, and output format all matter.
- RFC 4716’s SSH method uses MD5 and is historical; OpenPGP version 4 and version 6 use different constructions with SHA-1 and SHA2-256.
- A fingerprint verifies a key only when the reference value comes from a trustworthy path.
Sources
- RFC 4716, “The Secure Shell (SSH) Public Key File Format,” November 2006 (informational).
- RFC 4251, “The Secure Shell (SSH) Protocol Architecture,” January 2006.
- RFC 4253, “The Secure Shell (SSH) Transport Layer Protocol,” January 2006.
- RFC 9580, “OpenPGP.”
The specifications describe the constructions and verification guidance covered above. The OpenSSH command example reflects current OpenSSH behavior and may differ in other SSH implementations.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
