Host names hashing

[Jochen Bern]

On 05.01.22 15:06, Blumenthal, Uri - 0553 - MITLL wrote:
> What are the cryptographic consequences of host name hah collision?

None, I would guess. Someone crafting a server name/IP that causes a 
hash collision with an existing hashed known_hosts entry is likely to be 
a nuisance to or a source of confusion of the user (ssh will complain 
about the existing entry for a different host keypair), not, per se, a 
failure of security.

The hashing is meant to obscure info about what host it matches, so the 
relevant failure mode is if the hash algo would become *reversible*.

One question about the real-world use cases, however: How many people 
are there hashing known_hosts entries *autogenerated by client use out 
of the very same account*? If I were to find that someone got ahold of 
the known_hosts file off my workplace machine, I'd be worried about 
disclosure of my *user keypairs*, while the info about the servers I 
access would probably be a lost cause, anyway (that info is available in 
cleartext in the config file(s), and/or the saved shell history).

A much more understandable use case would be if an organization 
distributes a centrally administered/collected known_hosts file to users 
but doesn't want marginally-trusted users to immediately see where to 
find the company LAN's crown jewels. However, in order to make a 
successful algo migration in *that* scenario, we'd have to address the 
possibility that users and the central repository could end up 
supporting *different* sets of algos for some length of time ...

Regards,
-- 
Jochen Bern
Systemingenieur

Binect GmbH
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3449 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20220105/ef690532/attachment-0001.p7s>