On Wed, 5 Jan 2022, Dmitry Belyavskiy wrote:
> Dear colleagues,
>
> OpenSSH uses SHA1 without any alternate options for hostname hashing (looks
> like this is the last place where an alternate option for SHA1 is not
> available). SHA1 HMAC is considered safe enough for now, but it may change
> so it's definitely worth migrating to more safe algorithms (SHA2?).
>
> I'd like to discuss possible options of such migration.
I'd prefer to remove hostname hashing. It's a pointless obscurity
measure, and the most it can ever offer is protection against casual
shoulder-surfing disclosure[*]
I wish I never added it. I consider it the most stupid thing I've ever
done to OpenSSH :(
As far as what a concrete migration plan would look like, maybe something
like:
1) Add an ObscureKnownHostnames option that, instead of hashing, simply
base64-encodes the hostnames. This provides the same level of
protection as the current option. Recommend this instead of
HashKnownHosts in the manual.
2) (later) Add a deprecation warning to HashKnownHosts
3) (later still) Remove the HashKnownHosts option (or make it an alias
to ObscureKnownHostnames)
4) (later again) Warn when known_hosts contains a hashed hostname
5) (finally) rip out the hostname hashing code entirely.
-d
[*] Any real adversary will be able to reverse the hash via a dictionary
or brute-force, since the entropy of hostnames is so small.
This cannot be fixed using usual methods (e.g. using a deliberately-slow
KDF like bcrypt or scrypt instead of a hash) because ssh needs to
consider every name in known_hosts and any KDF slow enough to present
a problem for an attacker will be far too slow to be invoked for every
name in the file, every time the user runs ssh.