Practically, the hash value of a server host key can be (relatively) long and thoroughly compare it with the record again and again can be annoying. For example, for a given md5 hash value:


What if I only check the first half of it, namely:


Would I still get 50% security compared with checking the whole string?

What if I check the first 25% and the last 25% of the fingerprint?

PS: Programs like WinSCP and PuTTY only show the fingerprint through a pop-up window and thus I cannot copy the fingerprint and use a comparison program to compare two values.

  • 2
    Btw., do not use MD5 anymore. And in case you don't know how to read 5e-18%, it means 0.000000000000000005%, ie. very very very much easier to fake than the full key. – deviantfan Aug 27 '17 at 5:12
  • @deviantfan: that's not a choice for PuTTY (and things using PuTTY code like WinSCP) which implements only the hex(MD5(blob)) fingerprint traditionally used for decades by OpenSSH; it does not (yet?) support the b64(SHA256(blob)) version added by OpenSSH 6.8 about 2 years ago. – dave_thompson_085 Aug 28 '17 at 16:44

If you check only the first half of the host key you reduce the checked bits from 128 bits to 64 bits. Since there are not 2 keys but 2^64 keys which share the first 64 bits the security is not reduced by a factor of 2 but by a factor of 2^64, i.e. you don't get 50% security but 5e-18% security.

Note that even the reduced check of 64 bit might still be sufficient depending on the kind of attacker you expect. But, since you usually only need to check the host key on the first connect to a new system or on the first connect from a new system it might be worth the effort to spend a few seconds more to check the key more thoroughly.


No, you should not check only part of the key.

PS: Programs like WinSCP and PuTTY only show the fingerprint through a pop-up window and thus I cannot copy the fingerprint and use a comparison program to compare two values.

WinSCP has Copy key fingerprints to clipboard command exactly for this reason.

enter image description here

WinSCP also has Paste key command, that allows you to verify the key by pasting the expected key or its fingerprint from the clipboard.

See Verifying the host key article in WinSCP documentation.

And in PuTTY, you can at least press Ctrl+C to copy a whole message to the clipboard. You can then extract the key.

  • Or you can use Putty's stdio/filterable variant plink to capture the fingerprint, and optionally to accept the key and store in the registry where putty (and pscp and psftp) will find it. – dave_thompson_085 Aug 28 '17 at 16:41

Though it is NOT, when you verify hashes with your eyes (and brain) manually, it sounds like a great optimization. After all, even minor changes in content should cause a completely different hash, right?

Unfortunately, that makes several assumptions that could be your undoing. Due to these assumptions, the reduced security is not a function of the reduced number of bits you're checking. But something else altogether, that is not easy to compute. But it is not likely a small impact.

For example:

  • If you assume that the adversary is only making small changes. Most likely untrue, unless you're looking at a loan document that is only hashed (not digitally signed) where merely adding a few zeros to the loan amount is good enough impact.
  • If you assume that the adversary won't attempt hash collisions, again it is likely untrue - coz the kind of people who tamper with documents usually have high stakes and it is usually worth their while to attempt. By reducing the bits by half, you are likely cutting down the effort of generating hash collisions from "100s of years" to "a few minutes/hours" (i.e., probability from ~0 to ~1) - not exactly a 50% reduction in security. This is how the first SHA1 collisions have been achieved, BTW - by reducing the effort needed (this arstechnica article talks about identical prefix attacks - in lay people terms - it means that if you know a good portion of the document in question, the effort is reduced significantly).

There are other issues too, but I believe this is enough reason to not go this route.

So I always use tools to do the check for me. e.g., Linux sha1sum and sha256sum not only generate the hashes (to verify manually) but given the 2nd input, they can verify and tell you if all is well.

  • -1 Your examples are both at least partially incorrect. Whether or not the chance is small or large is irrelevant to whether or not the resulting digest changes, and hash collisions are likewise irrelevant (you seem to be confusing collisions with preimage attacks, which is the more realistic issue here). – forest Jan 18 '18 at 17:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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