What are the cryptographic consequences of host name hah collision? My point is - the only reason to consider replacing the algorithm here would be to avoid varying around another hash that is not usable cryptographically. Regards, Uri> On Jan 5, 2022, at 07:05, Dmitry Belyavskiy <dbelyavs at redhat.com> 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. > > Many thanks! > -- > Dmitry Belyavskiy > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev-------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5819 bytes Desc: not available URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20220105/e98e35b8/attachment-0001.p7s>
Dear Uri, Not sure we are trying to protect from collisions and not from host name's disclosure. On Wed, Jan 5, 2022 at 3:09 PM Blumenthal, Uri - 0553 - MITLL < uri at ll.mit.edu> wrote:> What are the cryptographic consequences of host name hah collision? > > My point is - the only reason to consider replacing the algorithm here > would be to avoid varying around another hash that is not usable > cryptographically. > > Regards, > Uri > > > On Jan 5, 2022, at 07:05, Dmitry Belyavskiy <dbelyavs at redhat.com> 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. > > > > Many thanks! > > -- > > Dmitry Belyavskiy > > _______________________________________________ > > openssh-unix-dev mailing list > > openssh-unix-dev at mindrot.org > > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >-- Dmitry Belyavskiy
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>