HASSH fingerprint (SSH)
Compute the HASSH fingerprint from a raw SSH KEXINIT packet. Best-effort recollection of the published field composition (kex;encryption_c2s;mac_c2s;compression_c2s, MD5), NOT checked against the reference hassh tool's output (no network access to verify). The KEXINIT wire parsing itself is plain RFC 4253. A matching fingerprint means two handshakes announced the same algorithms, nothing about trust.
Runs on your device. The file is never uploaded.
HASSH fingerprint reads a raw SSH KEXINIT packet, prints every algorithm name list inside it, and MD5s four of them into a HASSH and a HASSHServer value. Packet framing follows RFC 4253, and a message type other than 20 stops the run. The four-field composition was never checked against the reference implementation, so both hashes print marked unverified.
Questions
What does it fingerprint?
An SSH KEXINIT packet. It parses the binary packet framing from RFC 4253, reads the ten algorithm name lists, and prints them all. Then it computes HASSH from the key exchange, client to server encryption, MAC and compression lists, and HASSHServer from the server to client equivalents, each as an MD5 of those four lists joined by semicolons.
Is the fingerprint value trustworthy?
Treat it with caution, and the tool says so in its own output. The KEXINIT parsing is plain RFC 4253 and reliable, but the exact four field composition used for the hash is the author best recollection of the published spec and was never checked against the reference hassh implementation, because there was no network access to verify it. The output lines are labelled unverified for that reason.
Can I still use the algorithm lists?
Yes, and that is the safer part of the output. Every name list is printed in full: key exchange, host key algorithms, both encryption directions, both MAC directions and both compression directions. That is straight RFC parsing and is useful for auditing what a client or server offers.
Why did it refuse my capture?
Two checks. If the SSH message type is not 20 it stops and names the type it found, because only KEXINIT is handled. If the packet length and padding length leave no room for a payload, it says so. Give it the KEXINIT packet bytes, starting at the four byte packet length.
Does a matching HASSH mean two clients are the same program?
No. It means they announced the same algorithms, which many builds of the same client share and which a configuration change can alter. It is a correlation signal about configuration, not an identity and not a trust judgement. Since the hash composition here is unverified, the printed algorithm lists are the sturdier thing to compare.