Idea: how to install a self-signed public key

I'm trying to make the installation process of the self-signed public key (SSPK) more bulletproof and easier for users. Next sequence diagram shows the successful installation of the SSPK.

First: in order to reduce the chance of human error or laziness the administrator installing the self-signed public key (SSPK) must enter the hash of the public key. Simple comparison of two hashes (one received via phone and another one computed from received public key and displayed on the screen), as it is nowadays done by SSH and web browsers leaves room for MITM attack.

So, in step 6, the administrator enters the received hash (I would like to call it the authentication code of the public key) into his device and device compares the two hashes. If the hashes differ the SSPK is not installed.

Next sequence diagram shows the successful attack against this protocol. I assume that the communication channel between the user and administrator provides authenticity but not confidentiality.

The idea of the attack is, that attacker snoops the out of band communication channel that is used to transmit the hash of the SSPK and generates a new key pair, such that the hash of the new self-signed public key matches the hash of the self-signed public key generated by user. Now attacker can send it's own SSPK to administrator device and log into device on behalf of the user.

If we assume that the hash function used by the user is collision free, then this attack is infeasible. However the result of the known good hash functions is at least 160 bits. If we convert it to human readable form (base64), then it's at least 27 characters. This is too much. But I think that we can transmit only part of the hash and still be protected against the attack described above, if we enforce two rules:

1. administrator device checks that the SSPK is really self-signed.
2. the private key must be longer than some predetermined limit.

Those rules make the brute force attack very inefficient: attacker must sign each public key he generates, before he can compute the hash. (Disclaimer: it might be possible to generate weak keys of some special form that makes signing actually much faster. I don't know). Let's suppose the attacker can try 100 keys per second (performance of RSA signing with 1024 bit keys on modern PC). In a year he can probe 3153600000 keys. So, if we send just 32 bits from the hash then it takes 16 months to find the key with correct SSPK hash. With 48 bits (it's just eight characters when base64 encoded) the attacker needs 65536 times more computing power to achieve the same result.

PS: there is only one reason why the public key is signed: to make the attack harder and therefore to reduce the number of required bits. SSPK is not a certificate. You don't need a CA or PKI to use public key cryptography.