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. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
