Even then, the email would need to be signed and verified to ensure the key wasn't modified. You wouldn't want an attacker replacing it with their own public key.
But you would want tab completion of the shared secret so all an attacker needs is to guess the first character?
Why not email the ssh public key in plaintext and verify the md5sum, sha1sum, fingerprint, and / or first and last X characters of the key itself over the phone?
... or... Why not just put the public key on a web server with SSL and a free cert and speak the URL, then scp the payload file over? Or go ahead and get the free S/MIME cert from Comodo for your email since you can sign without the other end sending a signed email first and attach the payload file itself or an ssh public key and then scp? Or use Pidgin or a similar client with the OTR plugin on any XMPP server and send the payload file in the first place? Or issue SSL keys from your own local CA and communicate the fingerprint orally? Or send the public ssh key plaintext and only allow ssh through the firewall from the IP of your friend?
... or ... allow ssh via password rather than key for a small timeframe and communicate a password out of band rather than a shared secret for this thing?
... or ... put your ssh public key on a well-known account of yours like GitHub, Facebook, HN, etc and let your friend install it from there?
Very true, I'd personally never use the tab completion since the secrets are short enough, and I will probably raise an issue on the project to have that be optional.
And for the rest, they're still a hassle compared to just having your hackerspace friend install magic-wormhole so you can toy around with the nonsense he has on his Raspberry Pi.
Your last point, however, I think will be the key to the future (no pun intended). I'm hoping asymmetric crypto based communication will become easy, ubiquitous, and the default. Cheers to Keybase!
