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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
